* Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-19 8:02 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King, linux-i2c,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <CAOAejn2LobTMfvsvmW8cCiToFHuM6n26s5QPLLXxLzb-WKkhQw@mail.gmail.com>
Hello Cedric,
On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > Hello Cedric,
> >
> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
> >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
> >> >
> >> > * programmed with 0x9.
> >> > (1000 ns / 125 ns = 8)
> >> >
> >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
> >> >> + *
> >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
> >> >
> >> > as above s/03h/0x3/;
> >>
> >> ok
> >>
> >> > s/.(/. (/;
> >> ok
> >>
> >> > s/+ 1//;
> >> This formula is use to understand how we find the result 0x3
> >> So, 0x3 => 300 ns / 125ns = 2 + 1
> >
> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
> > irritating at best.
>
> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)
>
> >> > [...]
> >> > If DUTY = 1: (to reach 400 kHz)
> >> >
> >> > Strange.
> >> >
> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
> >> >
> >> > the manual reads:
> >> >
> >> > The minimum allowed value is 0x04, except in FAST DUTY mode
> >> > where the minimum allowed value is 0x01
> >> >
> >> > You don't check for that, right?
> >>
> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
> >> as described in the comment.
> >> So I don't need to check that again as it is already done by checking
> >> parent frequency.
> >
> > That would then go into a comment.
>
> Is it really needed ?
> Adding some comments to explain implementation choices or hardware
> way of working is clearly useful.
> But for this kind of thing, I am really surprised...
TL;DR: It's not needed, but it probably helps.
Consider someone sees a breakage in your driver in five years. By then
you either have other interests or at least forgot 95 % of the thoughts
you had when implementing the driver.
So when I see:
val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
ccr |= STM32F4_I2C_CCR_CCR(val);
writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
after seeing that the bus freq is wrong the obvious thoughts are:
- Does this use the right algorithm?
- Does this calculation result in values that are usable by the
hardware?
That you thought about this today doesn't mean it's still right in five
years. During that time a new hardware variant is available with a
higher parent freq. Or there is a new errata available for the SoC.
So to help answer the questions above it helps if you add today the
formulas from the manual and a quick reason for why val fits into the
respective bits in the CCR register. That comment might be wrong until
then, too, but that only means you should make it easy to verify.
Something like:
/*
* Function bla_blub made sure that parent_rate is not higher
* than 23 * pi MHz. As a result val is at most 13.2 bits wide
* and so fits into the CCR bits.
*/
This gives you in five years time the opportunity to quickly check
bla_blub if this is still true, add a printk for parent_rate to check
this, or quickly identify the bug in the code or the mismatch to the
manual.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 1/2] ARM64: dts: meson-gxm: Add R-Box Pro
From: Neil Armstrong @ 2017-01-19 8:10 UTC (permalink / raw)
To: Kevin Hilman, Andreas Färber
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
linux-kernel, Rob Herring, Carlo Caione, linux-amlogic,
linux-arm-kernel
In-Reply-To: <m237ggypfc.fsf@baylibre.com>
Hi Andreas, Kevin,
On 01/18/2017 11:27 PM, Kevin Hilman wrote:
> Andreas Färber <afaerber@suse.de> writes:
>
>> Am 17.01.2017 um 04:06 schrieb Andreas Färber:
>>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>>> index 0d7bfbf7d922..66bc809a5eae 100644
>>> --- a/arch/arm64/boot/dts/amlogic/Makefile
>>> +++ b/arch/arm64/boot/dts/amlogic/Makefile
>>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
>>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>>
>> What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1?
>> Should it be renamed to include -s912 for consistency?
It followed the GXL logic... until I posted the nexbox-a1 without !
Since the q20x and p23x boards are the same, it was to enforce the fact that
the S912 was on the q200 and q201 boards.
> Oops, I think it should be renamed for consistency.
>
> I believe there's only one chip in the GXM family (S912) so it might be
> that we could either drop the -s912 from the q20x boards or, add it to
> the nexbox.
I believe this aswell AFAIK.
>
> I lean towards dropping the -s912 since there's a single chip in GXM.
> (FWIW, GXL has more than one chip in the family so we added the chip
> there.)
>
>>> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
>>
>> Should this new board use meson-gxm-s912-?
>
> No. Unless Neil or you thing otherwise, I think we should send a patch
> to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;)
Ok, will do.
>
> Kevin
Neil
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-19 8:12 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel, Peter Senna Tschudin, Rob Herring, Mark Rutland,
Daniel Vetter, Peter Senna Tschudin, Takashi Iwai, Yakir Yang,
Jiri Slaby, Martyn Welch, Ian Campbell, Russell King,
Javier Martinez Canillas, Thierry Reding, Guenter Roeck,
martin.donnelly, devicetree@vger.kernel.org, Pawel Moll,
Mauro Carvalho Chehab, enric.balletb
In-Reply-To: <2088084.GDlN6tZSQv@avalon>
On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> Hi Peter,
>
> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> > >> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> > >>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> > >>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > >>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > >>>>>> display bridge.
> > >>>>>>
> > >>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> > >>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> > >>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> > >>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > >>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > >>>>>> Cc: Rob Herring <robh@kernel.org>
> > >>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > >>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> > >>>>>> ---
> > >>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6,
> > >>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> > >>>>>> removed it from the commit message.
> > >>>>>>
[...]
> > >>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++++
> > >>>>>
> > >>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> > >>>>
> > >>>> b850v3 is the name of the product, this is why the proposed name.
> > >>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> > >>>
> > >>> Humm, b850v3 is the board name? This node should be the name of the
> > >>> bridge chip.
> > >>
> > >> From the cover letter:
> > >>
> > >> -- // --
> > >> There are two physical bridges on the video signal pipeline: a
> > >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> > >> firmware made it complicated for this binding to comprise two device
> > >> tree nodes, as the design goal is to configure both bridges based on
> > >> the LVDS signal, which leave the driver powerless to control the video
> > >> processing pipeline. The two bridges behaves as a single bridge, and
> > >> the driver is only needed for telling the host about EDID / HPD, and
> > >> for giving the host powers to ack interrupts. The video signal pipeline
> > >> is as follows:
> > >> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> > >> output
> > >> -- // --
> > >
> > > You forgot to prefix your patch series with [HACK] ;-)
> > >
> > > How about fixing the issues that make the two DT nodes solution difficult
> > > ? What are they ?
> >
> > The Firmware and the hardware design. Both bridges, with stock firmware,
> > are fully capable of providig EDID information and handling interrupts.
> > But on this specific design, with this specific firmware, I need to read
> > EDID from one bridge, and handle interrupts on the other.
>
> Which firmware are you talking about ? Firmware running on the bridges, or
> somewhere else ?
Each bridge has it's own external flash containing a binary firmware.
The goal of the firmware is to configure the output end based on the
input end. This is part of what makes handling EDID and HPD challenging.
>
> > Back when I was starting the development I could not come up with a proper
> > way to split EDID and interrupts between two bridges in a way that would
> > result in a fully functional connector. Did I miss something?
>
> You didn't, we did :-) I've been telling for quite some time now that we must
> decouple bridges from connectors, and this is another example of why we have
> such a need. Bridges should expose additional functions needed to implement
> connector operations, and the connector should be instantiated by the display
> driver with the help of bridge operations. You could then create a connector
> that relies on one bridge to read the EDID and on the other bridge to handle
> HPD.
Ah thanks. So for now the single DT node approach is acceptable, right?
The problem is that even if the driver is getting better on each
iteration, the single DT node for two chips issue comes back often and I
believe is _the_ issue preventing the driver from getting upstream. V1
was sent ~ 8 months ago...
Can I have some blessing on the single DT node approach for now? I'm one
of the 3 proposed maintainers for the driver, and I'm willing to
maintain the driver on the long run, as is the same with the other two
proposed maintainers. So when the time to split the node in two comes,
we will be around, and willing to do it ourselves.
Thank you!
Peter
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Neil Armstrong @ 2017-01-19 8:12 UTC (permalink / raw)
To: Kevin Hilman
Cc: carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m2mveox9mm.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/18/2017 11:53 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
>
>> Adds support for the WeTek Hub and Play2 boards.
>> The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
>> traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
>>
>> Both are based on the p200 Reference Design and out-of-tree support is
>> based on OpenELEC kernel at [1].
>>
>> [1] https://github.com/wetek-enigma/linux-amlogic
>>
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>
> Did you get the GPIO/button info from the LibreELEC tree or did you find
> some schematics someplace? If you found any schematics, it would be
> nice to have links in the DTS files.
>
> Kevin
>
It was in the dts of the LibreELEC tree, I found no schematics so far.
I can respin a v2 with a link to the LibreELEC dts files.
Neil
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-19 8:14 UTC (permalink / raw)
To: Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Thomas Petazzoni, Marek Vasut, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Guochun Mao,
Richard Weinberger, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Matthias Brugger, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Cyrille Pitchen, Brian Norris, David Woodhouse
In-Reply-To: <CAL_Jsq+EyHtC7THLCJcwgtVtVESMOdmi3T3bBxgOqJt6BCtCHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Wed, 18 Jan 2017 20:51:08 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
> <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Hello,
> >
> > On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
> >
> >> > > Rob, Mark, any opinion?
> >> >
> >>
> >> Sigh, is how to do compatibles really not yet understood?
> >
> > Well, it seems like not everyone necessarily understands what is the
> > best strategy to adopt (me included).
> >
> >> > I agree that a clarification would be good. There are really two
> >> > options:
> >> >
> >> > 1. Have two compatible strings in the DT, the one that matches the
> >> > exact SoC where the IP is found (first compatible string) and the
> >> > one that matches some other SoC where the same IP is found (second
> >> > compatible string). Originally, Linux only supports the second
> >> > compatible string in its device driver, but if it happens that a
> >> > difference is found between two IPs that we thought were the same,
> >> > we can add support for the first compatible string in the driver,
> >> > with a slightly different behavior.
> >>
> >> This. And no wildcards in the compatible string.
> >
> > OK. So it means that today we do something like:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and support only baz,foo-00 in the driver. If tomorrow we discover
> > that there is in fact a difference between the two IP blocks, we can
> > add support for baz,foo-12 in the driver, and handle the differences.
> >
> > But then, the DT still contains:
> >
> > compatible = "baz,foo-12", "baz,foo-00";
> >
> > and therefore pretends that the IP block is compatible with
> > "baz,foo-00" which is in fact *not* the case. It was a mistake to
> > consider it as compatible. So we keep living with a DT that has
> > incorrect information.
>
> I wouldn't say it's a mistake necessarily. The old compatible would
> probably work to some extent. I'd assume it was tested to some level.
> Or it could be other changes exposing a difference.
One last question and I'm done: is something like that acceptable?
compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
This can happen when someone adds support for an unsupported feature
on a brand new SoC, and then someone else use the same driver for an
older SoC embedding the same IP but still wants to add a new compatible
just in case these 2 IPs appear to be slightly different.
Here the order of compat strings is no longer following a clear rule
like 'most-specific compatible first' or 'newest IP/SoC version first',
it's completely dependent on the order these IPs were supported in the
OS (Linux). I'm perfectly fine with that BTW, just want to make sure
this is authorized.
Regards,
Boris
--
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 V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-19 8:17 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: dri-devel, Peter Senna Tschudin, Rob Herring, Mark Rutland,
Daniel Vetter, Peter Senna Tschudin, Takashi Iwai, Yakir Yang,
Jiri Slaby, Martyn Welch, Ian Campbell, Russell King,
Javier Martinez Canillas, Thierry Reding, Guenter Roeck,
martin.donnelly, devicetree@vger.kernel.org, Pawel Moll,
Mauro Carvalho Chehab, enric.balletb
In-Reply-To: <20170119081214.GA29457@collabora.com>
Hi Peter,
On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >>>> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> >>>>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >>>>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> >>>>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin
wrote:
> >>>>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >>>>>>>> display bridge.
> >>>>>>>>
> >>>>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> >>>>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> >>>>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >>>>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >>>>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >>>>>>>> ---
> >>>>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6,
> >>>>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> >>>>>>>> removed it from the commit message.
>
> [...]
>
> >>>>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++
> >>>>>>>
> >>>>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >>>>>>
> >>>>>> b850v3 is the name of the product, this is why the proposed name.
> >>>>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> >>>>>
> >>>>> Humm, b850v3 is the board name? This node should be the name of the
> >>>>> bridge chip.
> >>>>
> >>>> From the cover letter:
> >>>>
> >>>> -- // --
> >>>> There are two physical bridges on the video signal pipeline: a
> >>>> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> >>>> firmware made it complicated for this binding to comprise two device
> >>>> tree nodes, as the design goal is to configure both bridges based on
> >>>> the LVDS signal, which leave the driver powerless to control the
> >>>> video processing pipeline. The two bridges behaves as a single bridge,
> >>>> and the driver is only needed for telling the host about EDID / HPD,
> >>>> and for giving the host powers to ack interrupts. The video signal
> >>>> pipeline
> >>>>
> >>>> is as follows:
> >>>> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >>>> output
> >>>>
> >>>> -- // --
> >>>
> >>> You forgot to prefix your patch series with [HACK] ;-)
> >>>
> >>> How about fixing the issues that make the two DT nodes solution
> >>> difficult ? What are they ?
> >>
> >> The Firmware and the hardware design. Both bridges, with stock firmware,
> >> are fully capable of providig EDID information and handling interrupts.
> >> But on this specific design, with this specific firmware, I need to read
> >> EDID from one bridge, and handle interrupts on the other.
> >
> > Which firmware are you talking about ? Firmware running on the bridges, or
> > somewhere else ?
>
> Each bridge has it's own external flash containing a binary firmware.
> The goal of the firmware is to configure the output end based on the
> input end. This is part of what makes handling EDID and HPD challenging.
>
> >> Back when I was starting the development I could not come up with a
> >> proper way to split EDID and interrupts between two bridges in a way
> >> that would result in a fully functional connector. Did I miss something?
> >
> > You didn't, we did :-) I've been telling for quite some time now that we
> > must decouple bridges from connectors, and this is another example of why
> > we have such a need. Bridges should expose additional functions needed to
> > implement connector operations, and the connector should be instantiated
> > by the display driver with the help of bridge operations. You could then
> > create a connector that relies on one bridge to read the EDID and on the
> > other bridge to handle HPD.
>
> Ah thanks. So for now the single DT node approach is acceptable, right?
> The problem is that even if the driver is getting better on each
> iteration, the single DT node for two chips issue comes back often and I
> believe is _the_ issue preventing the driver from getting upstream. V1
> was sent ~ 8 months ago...
>
> Can I have some blessing on the single DT node approach for now?
With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are
acceptable on the driver side, but you need two nodes in DT.
> I'm one of the 3 proposed maintainers for the driver, and I'm willing to
> maintain the driver on the long run, as is the same with the other two
> proposed maintainers. So when the time to split the node in two comes,
> we will be around, and willing to do it ourselves.
How about putting that team of 3 maintainers to work on fixing the problem in
the bridge API ? :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxm: Rename q200 and q201 DT files for consistency
From: Neil Armstrong @ 2017-01-19 8:21 UTC (permalink / raw)
To: khilman, carlo, afaerber
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In order to keep consistency naming with the Nexbox A1 DTS file, remove the
S912 SoC name in the GXM DT files.
Suggested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 4 ++--
.../boot/dts/amlogic/{meson-gxm-s912-q200.dts => meson-gxm-q200.dts} | 0
.../boot/dts/amlogic/{meson-gxm-s912-q201.dts => meson-gxm-q201.dts} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q200.dts => meson-gxm-q200.dts} (100%)
rename arch/arm64/boot/dts/amlogic/{meson-gxm-s912-q201.dts => meson-gxm-q201.dts} (100%)
Kevin, is this patch format correct for you to apply ?
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 0d7bfbf..1aca8e5 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -9,8 +9,8 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
similarity index 100%
rename from arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
rename to arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 2/5] fbdev: ssd1307fb: Remove reset-active-low from the DT binding document
From: Jyri Sarha @ 2017-01-19 8:24 UTC (permalink / raw)
To: Rob Herring
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ, tomi.valkeinen-l0cyMroinI0,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170118222804.ifqkkffot5n55gsk@rob-hp-laptop>
On 01/19/17 00:28, Rob Herring wrote:
> On Fri, Jan 13, 2017 at 12:35:46PM +0200, Jyri Sarha wrote:
>> Remove reset-active-low from the devicetree binding document. The actual
>> implementation has never been there in the driver code and there is no
>> reason to add it because the gpiod API supports gpio flags, including
>> GPIO_ACTIVE_LOW, directly trough its own devicetree binding.
>>
>> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/display/ssd1307fb.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> index eb31ed4..4aee67f 100644
>> --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
>> @@ -8,14 +8,14 @@ Required properties:
>> 0x3c or 0x3d
>> - pwm: Should contain the pwm to use according to the OF device tree PWM
>> specification [0]. Only required for the ssd1307.
>> - - reset-gpios: Should contain the GPIO used to reset the OLED display
>> + - reset-gpios: Should contain the GPIO used to reset the OLED display. See
>> + Documentation/devicetree/bindings/gpio/gpio.txt for details.
> You need to define the active state. Does the active state actually
> vary? Sounds like the compatible is not specific enough unless some
> boards have an inverter.
>
No, I am not aware of the active state ever varying. For some reason
someone specified the reset-active-low, but probably in the end it was
not needed after all because the implementation was not added.
The only reason I can think of why the reset gpio would need active low
flag is very weird board design or broken gpio driver.
Best regards,
Jyri
--
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 v5 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Peter Rosin @ 2017-01-19 8:27 UTC (permalink / raw)
To: Phil Reid, wsa, robh+dt, mark.rutland, linux-i2c, devicetree
In-Reply-To: <1484640029-22870-4-git-send-email-preid@electromag.com.au>
On 2017-01-17 09:00, Phil Reid wrote:
> Various muxes can aggregate multiple interrupts from each i2c bus.
> All of the muxes with interrupt support combine the active low irq lines
> using an internal 'and' function and generate a combined active low
> output. The muxes do provide the ability to read a control register to
> determine which irq is active. By making the mux an irq controller isr
> latency can potentially be reduced by reading the status register and
> then only calling the registered isr on that bus segment.
>
> As there is no irq masking on the mux irq are disabled until irq_unmask is
> called at least once.
>
> Signed-off-by: Phil Reid <preid@electromag.com.au>
Acked-by: Peter Rosin <peda@axentia.se>
Cheers,
peda
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 141 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 139 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index bbf088e..f55da88 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -41,14 +41,20 @@
> #include <linux/i2c.h>
> #include <linux/i2c-mux.h>
> #include <linux/i2c/pca954x.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/of_irq.h>
> #include <linux/pm.h>
> #include <linux/slab.h>
> +#include <linux/spinlock.h>
>
> #define PCA954X_MAX_NCHANS 8
>
> +#define PCA954X_IRQ_OFFSET 4
> +
> enum pca_type {
> pca_9540,
> pca_9542,
> @@ -63,6 +69,7 @@ enum pca_type {
> struct chip_desc {
> u8 nchans;
> u8 enable; /* used for muxes only */
> + u8 has_irq;
> enum muxtype {
> pca954x_ismux = 0,
> pca954x_isswi
> @@ -75,6 +82,10 @@ struct pca954x {
> u8 last_chan; /* last register value */
> u8 deselect;
> struct i2c_client *client;
> +
> + struct irq_domain *irq;
> + unsigned int irq_mask;
> + spinlock_t lock;
> };
>
> /* Provide specs for the PCA954x types we know about */
> @@ -87,19 +98,23 @@ struct pca954x {
> [pca_9542] = {
> .nchans = 2,
> .enable = 0x4,
> + .has_irq = 1,
> .muxtype = pca954x_ismux,
> },
> [pca_9543] = {
> .nchans = 2,
> + .has_irq = 1,
> .muxtype = pca954x_isswi,
> },
> [pca_9544] = {
> .nchans = 4,
> .enable = 0x4,
> + .has_irq = 1,
> .muxtype = pca954x_ismux,
> },
> [pca_9545] = {
> .nchans = 4,
> + .has_irq = 1,
> .muxtype = pca954x_isswi,
> },
> [pca_9547] = {
> @@ -222,6 +237,114 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
> return pca954x_reg_write(muxc->parent, client, data->last_chan);
> }
>
> +static irqreturn_t pca954x_irq_handler(int irq, void *dev_id)
> +{
> + struct pca954x *data = dev_id;
> + unsigned int child_irq;
> + int ret, i, handled;
> +
> + ret = i2c_smbus_read_byte(data->client);
> + if (ret < 0)
> + return IRQ_NONE;
> +
> + for (i = 0; i < data->chip->nchans; i++) {
> + if (ret & BIT(PCA954X_IRQ_OFFSET + i)) {
> + child_irq = irq_linear_revmap(data->irq, i);
> + handle_nested_irq(child_irq);
> + handled++;
> + }
> + }
> + return handled ? IRQ_HANDLED : IRQ_NONE;
> +}
> +
> +static void pca954x_irq_mask(struct irq_data *idata)
> +{
> + struct pca954x *data = irq_data_get_irq_chip_data(idata);
> + unsigned int pos = idata->hwirq;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&data->lock, flags);
> +
> + data->irq_mask &= ~BIT(pos);
> + if (!data->irq_mask)
> + disable_irq(data->client->irq);
> +
> + spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static void pca954x_irq_unmask(struct irq_data *idata)
> +{
> + struct pca954x *data = irq_data_get_irq_chip_data(idata);
> + unsigned int pos = idata->hwirq;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&data->lock, flags);
> +
> + if (!data->irq_mask)
> + enable_irq(data->client->irq);
> + data->irq_mask |= BIT(pos);
> +
> + spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static int pca954x_irq_set_type(struct irq_data *idata, unsigned int type)
> +{
> + if ((type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_LOW)
> + return -EINVAL;
> + return 0;
> +}
> +
> +static struct irq_chip pca954x_irq_chip = {
> + .name = "i2c-mux-pca954x",
> + .irq_mask = pca954x_irq_mask,
> + .irq_unmask = pca954x_irq_unmask,
> + .irq_set_type = pca954x_irq_set_type,
> +};
> +
> +static int pca954x_irq_setup(struct i2c_mux_core *muxc)
> +{
> + struct pca954x *data = i2c_mux_priv(muxc);
> + struct i2c_client *client = data->client;
> + int c, err, irq;
> +
> + if (!data->chip->has_irq || client->irq <= 0)
> + return 0;
> +
> + spin_lock_init(&data->lock);
> +
> + data->irq = irq_domain_add_linear(client->dev.of_node,
> + data->chip->nchans,
> + &irq_domain_simple_ops, data);
> + if (!data->irq)
> + return -ENODEV;
> +
> + for (c = 0; c < data->chip->nchans; c++) {
> + irq = irq_create_mapping(data->irq, c);
> + irq_set_chip_data(irq, data);
> + irq_set_chip_and_handler(irq, &pca954x_irq_chip,
> + handle_simple_irq);
> + }
> +
> + err = devm_request_threaded_irq(&client->dev, data->client->irq, NULL,
> + pca954x_irq_handler,
> + IRQF_ONESHOT | IRQF_SHARED,
> + "pca954x", data);
> + if (err)
> + goto err_req_irq;
> +
> + disable_irq(data->client->irq);
> +
> + return 0;
> +err_req_irq:
> + for (c = 0; c < data->chip->nchans; c++) {
> + irq = irq_find_mapping(data->irq, c);
> + irq_dispose_mapping(irq);
> + }
> + irq_domain_remove(data->irq);
> +
> + return err;
> +}
> +
> /*
> * I2C init/probing/exit functions
> */
> @@ -286,6 +409,10 @@ static int pca954x_probe(struct i2c_client *client,
> idle_disconnect_dt = of_node &&
> of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
>
> + ret = pca954x_irq_setup(muxc);
> + if (ret)
> + goto fail_del_adapters;
> +
> /* Now create an adapter for each channel */
> for (num = 0; num < data->chip->nchans; num++) {
> bool idle_disconnect_pd = false;
> @@ -311,7 +438,7 @@ static int pca954x_probe(struct i2c_client *client,
> dev_err(&client->dev,
> "failed to register multiplexed adapter"
> " %d as bus %d\n", num, force);
> - goto virt_reg_failed;
> + goto fail_del_adapters;
> }
> }
>
> @@ -322,7 +449,7 @@ static int pca954x_probe(struct i2c_client *client,
>
> return 0;
>
> -virt_reg_failed:
> +fail_del_adapters:
> i2c_mux_del_adapters(muxc);
> return ret;
> }
> @@ -330,6 +457,16 @@ static int pca954x_probe(struct i2c_client *client,
> static int pca954x_remove(struct i2c_client *client)
> {
> struct i2c_mux_core *muxc = i2c_get_clientdata(client);
> + struct pca954x *data = i2c_mux_priv(muxc);
> + int c, irq;
> +
> + if (data->irq) {
> + for (c = 0; c < data->chip->nchans; c++) {
> + irq = irq_find_mapping(data->irq, c);
> + irq_dispose_mapping(irq);
> + }
> + irq_domain_remove(data->irq);
> + }
>
> i2c_mux_del_adapters(muxc);
> return 0;
>
^ permalink raw reply
* Re: [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-19 8:29 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170119080258.fovhfy2v6rrtgwgp-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
ok fine
2017-01-19 9:02 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Wed, Jan 18, 2017 at 09:55:39PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-18 19:42 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> > Hello Cedric,
>> >
>> > On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
>> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>> >> >
>> >> > * programmed with 0x9.
>> >> > (1000 ns / 125 ns = 8)
>> >> >
>> >> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> >> >> + *
>> >> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> >> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>> >> >
>> >> > as above s/03h/0x3/;
>> >>
>> >> ok
>> >>
>> >> > s/.(/. (/;
>> >> ok
>> >>
>> >> > s/+ 1//;
>> >> This formula is use to understand how we find the result 0x3
>> >> So, 0x3 => 300 ns / 125ns = 2 + 1
>> >
>> > Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
>> > irritating at best.
>>
>> Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)
>>
>> >> > [...]
>> >> > If DUTY = 1: (to reach 400 kHz)
>> >> >
>> >> > Strange.
>> >> >
>> >> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
>> >> >
>> >> > the manual reads:
>> >> >
>> >> > The minimum allowed value is 0x04, except in FAST DUTY mode
>> >> > where the minimum allowed value is 0x01
>> >> >
>> >> > You don't check for that, right?
>> >>
>> >> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
>> >> as described in the comment.
>> >> So I don't need to check that again as it is already done by checking
>> >> parent frequency.
>> >
>> > That would then go into a comment.
>>
>> Is it really needed ?
>> Adding some comments to explain implementation choices or hardware
>> way of working is clearly useful.
>> But for this kind of thing, I am really surprised...
>
> TL;DR: It's not needed, but it probably helps.
>
> Consider someone sees a breakage in your driver in five years. By then
> you either have other interests or at least forgot 95 % of the thoughts
> you had when implementing the driver.
>
> So when I see:
>
> val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
> ccr |= STM32F4_I2C_CCR_CCR(val);
> writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
>
> after seeing that the bus freq is wrong the obvious thoughts are:
>
> - Does this use the right algorithm?
> - Does this calculation result in values that are usable by the
> hardware?
>
> That you thought about this today doesn't mean it's still right in five
> years. During that time a new hardware variant is available with a
> higher parent freq. Or there is a new errata available for the SoC.
>
> So to help answer the questions above it helps if you add today the
> formulas from the manual and a quick reason for why val fits into the
> respective bits in the CCR register. That comment might be wrong until
> then, too, but that only means you should make it easy to verify.
> Something like:
>
> /*
> * Function bla_blub made sure that parent_rate is not higher
> * than 23 * pi MHz. As a result val is at most 13.2 bits wide
> * and so fits into the CCR bits.
> */
>
> This gives you in five years time the opportunity to quickly check
> bla_blub if this is still true, add a printk for parent_rate to check
> this, or quickly identify the bug in the code or the mismatch to the
> manual.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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 v8 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2017-01-19 8:43 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: robh+dt, mark.rutland, alexandre.torgue, devicetree, linux-kernel,
thierry.reding, linux-pwm, jic23, knaack.h, lars, pmeerw,
linux-iio, linux-arm-kernel, fabrice.gasnier, gerald.baeza,
arnaud.pouliquen, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1484749251-14445-1-git-send-email-benjamin.gaignard@st.com>
On Wed, 18 Jan 2017, Benjamin Gaignard wrote:
> version 8:
> - rebase on v4.10-rc4
> - fix comments done by Thierry on PWM
> - reword "reg" parameter description
> - change kernel kernel in IIO ABI documentation
>
> version 7:
> - rebase on v4.10-rc2
> - remove iio_device code from driver and keep only the trigger part
>
> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
>
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
>
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
>
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
>
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
> - pwm channels, complementary output, counter size, break input
> - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>
> The following patches enable PWM and IIO Timer features for STM32 platforms.
>
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver
> on the top of them to be able to share the registers.
>
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to
> describe the differences between hardware blocks
>
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
>
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
>
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>
> The matrix of possible connections between blocks is quite complex so we use
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
>
> At run time IIO timer hardware blocks can configure (through "master_mode"
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
>
> Benjamin Gaignard (8):
> MFD: add bindings for STM32 Timers driver
> MFD: add STM32 Timers driver
> PWM: add pwm-stm32 DT bindings
> PWM: add PWM driver for STM32 plaftorm
> IIO: add bindings for STM32 timer trigger driver
> IIO: add STM32 timer trigger driver
> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++
> .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++
> arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> drivers/iio/trigger/Kconfig | 9 +
> drivers/iio/trigger/Makefile | 1 +
> drivers/iio/trigger/stm32-timer-trigger.c | 342 ++++++++++++++++++
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 +++++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 398 +++++++++++++++++++++
> include/linux/iio/timer/stm32-timer-trigger.h | 62 ++++
> include/linux/mfd/stm32-timers.h | 71 ++++
> 17 files changed, 1422 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 drivers/pwm/pwm-stm32.c
> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> create mode 100644 include/linux/mfd/stm32-timers.h
Let me know when you have all your Acks.
I would be happy to take this through the MFD tree.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2017-01-19 9:01 UTC (permalink / raw)
To: Dave Young
Cc: Mark Rutland, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
james.morse-5wv7dgnIgG8, geoff-wEGCiKHe2LqWVfeAwA7xHQ,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170117082629.GA7012-0VdLhd/A9Pl+NNSt+8eSiB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
On Tue, Jan 17, 2017 at 04:26:29PM +0800, Dave Young wrote:
> On 01/16/17 at 05:25pm, AKASHI Takahiro wrote:
> > On Fri, Jan 13, 2017 at 11:17:56AM +0000, Mark Rutland wrote:
> > > On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> > > > On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:
> > > > > On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> > > > > > +linux,crashkernel-base
> > > > > > +linux,crashkernel-size
> > > > > > +----------------------
> > > > > > +
> > > > > > +These properties (currently used on PowerPC and arm64) indicates
> > > > > > +the base address and the size, respectively, of the reserved memory
> > > > > > +range for crash dump kernel.
> > > > >
> > > > > From this description, it's not clear to me what the (expected)
> > > > > consumers of this property are, nor what is expected to provide it.
> > > > >
> > > > > In previous rounds of review, I had assumed that this was used to
> > > > > describe a preference to the first kernel as to what region of memory
> > > > > should be used for a subsequent kdump kernel. Looking around, I'm not
> > > > > sure if I was correct in that assessment.
> > > > >
> > > > > I see that arch/powerpc seems to consume this property to configure
> > > > > crashk_res, but it also rewrites it based on crashk_res, presumably for
> > > > > the benefit of userspace. It's not clear to me how on powerpc the kdump
> > > > > kernel knows its memory range -- is more DT modification done in the
> > > > > kernel and/or userspace?
> > > >
> > > > I don't believe that powerpc will rewrite the property any way.
> > > > As far as I know from *the source code*, powerpc kernel retrieves
> > > > the memory range for crash dump kernel from a kernel command line, i.e.
> > > > crashkernel=, and then exposes it through DT to userspace (assuming
> > > > kexec-tools).
> > >
> > > The rewriting I describe is in export_crashk_values() in
> > > arch/powerpc/kernel/machine_kexec.c, where the code deletes existing the
> > > properties, and adds new ones, to the DT exposed to userspace.
> > >
> > > So I think we're just quibbling over the definition of "rewrite".
> >
> > Gotcha
> >
> > > > > arm64 we should either ensure that /proc/iomem is consistently usable
> > > > > (and have userspace consistently use it), or we should expose a new file
> > > > > specifically to expose this information.
> > > >
> > > > The thing that I had in my mind when adding this property is that
> > > > /proc/iomem would be obsolete in the future, then we should have
> > > > an alternative in hand.
> > >
> > > Ok.
> > >
> > > My disagreement is with using the DT as a channel to convey information
> > > from the kernel to userspace.
> > >
> > > I'm more than happy for a new file or other mechanism to express this
> > > information. For example, we could add
> > > /sys/kernel/kexec_crash_{base,size} or similar.
> >
> > It may make sense because /sys/kernel/kexec_crash_size already exists,
> > so why not kexec_crash_base?
> > My concern, however, is that this kind of interface might prevent us from
> > allowing multiple regions to be reserved for crash dump kernel in the future.
> > (There is an assumption that we have only one region at least on arm64 though.)
>
> In x86 there could be two ranges, one for softiotlb under 4G and another
> for range over 4G, but kexec_crash_size only shows the size of
> over-4g-range.
>
> It is better to use /proc/iomem, most arches use /proc/iomem. Do you
> have any reason why it will be obsolete? At least for the time being it
> is fine.
I don't know.
I just think that I might have seen that someone said so somewhere
and that more _powerful_ (structured) tool could supersede it :)
-Takahiro AKASHI
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > >
> > > > > Further, I do not think we need this property. It makes more sense to me
> > > > > for the preference of a a region to be described to the *first* kernel
> > > > > using the command line consistently.
> > > > >
> > > > > So I think we should drop this property, and not use it on arm64. Please
> > > > > document this as powerpc only.
> > > >
> > > > OK, but if we drop the property from arm64 code, we have no reason
> > > > to leave its description in this patch.
> > > > (In fact, there are a few more (undocumented) properties that only ppc
> > > > uses for kdump.)
> > >
> > > I'm happy to drop it, then.
> > >
> > > > > > +linux,usable-memory-range
> > > > > > +-------------------------
> > > > > > +
> > > > > > +This property (currently used only on arm64) holds the memory range,
> > > > > > +the base address and the size, which can be used as system ram on
> > > > > > +the *current* kernel. Note that, if this property is present, any memory
> > > > > > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > > > > > +memory" in EFI memory map should be ignored.
> > > > >
> > > > > Could you please replace this with:
> > > > >
> > > > > This property (arm64 only) holds a base address and size, describing a
> > > > > limited region in which memory may be considered available for use by
> > > > > the kernel. Memory outside of this range is not available for use.
> > > > >
> > > > > This property describes a limitation: memory within this range is only
> > > > > valid when also described through another mechanism that the kernel
> > > > > would otherwise use to determine available memory (e.g. memory nodes
> > > > > or the EFI memory map). Valid memory may be sparse within the range.
> > > >
> > > > Sure.
> > >
> > > Cheers!
> > >
> > > Thanks,
> > > Mark.
> >
> > _______________________________________________
> > kexec mailing list
> > kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/kexec
--
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 v2 3/3] gpio: Support gpio nexus dt bindings
From: Linus Walleij @ 2017-01-19 9:02 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Frank Rowand, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Pantelis Antoniou, Mark Brown
In-Reply-To: <20170118005038.9216-4-stephen.boyd@linaro.org>
On Wed, Jan 18, 2017 at 1:50 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
>
> Now that we have nexus support in the OF core let's change the
> function call here that parses the phandle lists of gpios to use
> the nexus variant. This allows us to remap phandles and their
> arguments through any number of nexus nodes and end up with the
> actual gpio provider being used.
>
> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Provided that patches 1 & 2 go in reviewed and merged
by DT/device core people, they can merge this on top as well.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 3/8] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2017-01-19 9:04 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: mark.rutland, devicetree, lars, alexandre.torgue, linux-pwm,
linux-iio, arnaud.pouliquen, linux-kernel, robh+dt,
linux-arm-kernel, pmeerw, knaack.h, gerald.baeza, fabrice.gasnier,
lee.jones, linaro-kernel, jic23, Benjamin Gaignard
In-Reply-To: <1484749251-14445-4-git-send-email-benjamin.gaignard@st.com>
[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]
On Wed, Jan 18, 2017 at 03:20:46PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 8:
> - reword st,breakinput description.
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
One last nit: please use "dt-bindings: pwm:" as prefix for the patch
subject. So it would read something like this:
dt-bindings: pwm: Add STM32 bindings
or similar. That's the style that's been used for a while now. I'd have
fixed that up myself, but since Lee plans to take this through the MFD
tree I'd like to see that fixed up before it gets applied.
With the above:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 13/13] MIPS: jz4740: Remove custom GPIO code
From: Linus Walleij @ 2017-01-19 9:07 UTC (permalink / raw)
To: Paul Cercueil
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Ulf Hansson,
Boris Brezillon, Thierry Reding, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Linux MIPS,
linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, linux-p
In-Reply-To: <20170117231421.16310-14-paul@crapouillou.net>
On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil <paul@crapouillou.net> wrote:
> All the drivers for the various hardware elements of the jz4740 SoC have
> been modified to use the pinctrl framework for their pin configuration
> needs.
> As such, this platform code is now unused and can be deleted.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
I feel I might have come across as a bit harsh in the previous review of the
patches leading up to this one. In that case I'm sorry.
I can clearly see that the intent of the series is to remove this hopelessly
idiomatic code from the MIPS hurdle, and move these systems over
to standard frameworks.
In a way, if I look at the kernel as a whole, it would likely look better
after these patches were merged, than before. Even with the
shortcomings I painted out in the previous review comments.
A very complicated piece of messy code is cut from MIPS.
I think this is very valuable work and well worth persuing, so please
go ahead and work with the series, your effort is very much appreciated!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 4/8] PWM: add PWM driver for STM32 plaftorm
From: Thierry Reding @ 2017-01-19 9:08 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: mark.rutland, devicetree, lars, alexandre.torgue, linux-pwm,
linux-iio, arnaud.pouliquen, linux-kernel, robh+dt,
linux-arm-kernel, pmeerw, knaack.h, gerald.baeza, fabrice.gasnier,
lee.jones, linaro-kernel, jic23, Benjamin Gaignard
In-Reply-To: <1484749251-14445-5-git-send-email-benjamin.gaignard@st.com>
[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]
On Wed, Jan 18, 2017 at 03:20:47PM +0100, Benjamin Gaignard wrote:
> This driver adds support for PWM driver on STM32 platform.
> The SoC have multiple instances of the hardware IP and each
> of them could have small differences: number of channels,
> complementary output, auto reload register size...
>
> version 8:
> - fix comments done by Thierry on version 7
>
> version 6:
> - change st,breakinput parameter to make it usuable for stm32f7 too.
>
> version 4:
> - detect at probe time hardware capabilities
> - fix comments done on v2 and v3
> - use PWM atomic ops
>
> version 2:
> - only keep one comptatible
> - use DT parameters to discover hardware block configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 398 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 408 insertions(+)
> create mode 100644 drivers/pwm/pwm-stm32.c
Similar nit than for 3/8. The canonical prefix for PWM subsystem patches
is "pwm: ". One other thing that I had missed earlier...
> +MODULE_ALIAS("platform: stm32-pwm");
I don't think there should be a space after ':'.
With those two fixed:
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* ARM: i.MX7: Fix LPSR specific iomux pins
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Fabio Estevam, devicetree, Shawn Guo, kernel
The i.MX7 has two iomux controllers. the iomuxc and the iomuxc_lpsr.
Some pinmux settings in the board dts files are non functional because
they are attached to the wrong iomux controller. The following patches
fix this.
It's way too easy to fall into this trap again. Only a look into the
reference manual can reveal which pin belongs to which controller.
To make this clearer the last patch adds "LPSR" to the pin names
which belong to the LPSR controller.
Sascha
----------------------------------------------------------------
Sascha Hauer (4):
ARM: dts: imx7s-warp: Fix watchdog pinmux
ARM: dts: imx7d-sdp: Fix watchdog and pwm pinmux
ARM: dts: imx7d-cl-som: Fix OTG power pinctrl
ARM: dts: imx7: Add "LPSR" to LPSR iomux pin names
arch/arm/boot/dts/imx7-colibri.dtsi | 16 ++---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 14 ++--
arch/arm/boot/dts/imx7d-nitrogen7.dts | 14 ++--
arch/arm/boot/dts/imx7d-pinfunc.h | 110 ++++++++++++++++----------------
arch/arm/boot/dts/imx7d-sdb.dts | 26 ++++----
arch/arm/boot/dts/imx7s-warp.dts | 4 +-
6 files changed, 95 insertions(+), 89 deletions(-)
^ permalink raw reply
* [PATCH 1/4] ARM: dts: imx7s-warp: Fix watchdog pinmux
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Fabio Estevam, devicetree, Sascha Hauer, Shawn Guo, kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The watchdog pin is controlled by the iomuxc_lpsr, not the regular
iomux, so move it there.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7s-warp.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 0345267f3390..cbb5bc16e713 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -437,7 +437,9 @@
MX7D_PAD_SD3_RESET_B__SD3_RESET_B 0x1b
>;
};
+};
+&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx7d-sdp: Fix watchdog and pwm pinmux
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Fabio Estevam, devicetree, Sascha Hauer, Shawn Guo, kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The watchdog pin and the pwm output pin are controlled by the
iomuxc_lpsr, not the regular iomux, so move the pins there.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7d-sdb.dts | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 2f33c463cbce..84f35a6cbb30 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -502,12 +502,6 @@
>;
};
- pinctrl_pwm1: pwm1grp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
- >;
- };
-
pinctrl_tsc2046_pendown: tsc2046_pendown {
fsl,pins = <
MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x59
@@ -635,11 +629,19 @@
MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
>;
};
-
- pinctrl_wdog: wdoggrp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
- >;
- };
};
};
+
+&iomuxc_lpsr {
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
+ >;
+ };
+};
\ No newline at end of file
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx7d-cl-som: Fix OTG power pinctrl
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Shawn Guo, Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer
In-Reply-To: <20170119090924.19636-1-s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
GPIO01_IO05 is controlled by the LPSR iomux controller, so attach
the corresponding pin to this controller.
Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 58b09bf1ba2d..1135bc99b3e7 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -261,12 +261,6 @@
>;
};
- pinctrl_usbotg1: usbotg1grp {
- fsl,pins = <
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
- >;
- };
-
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX7D_PAD_SD3_CMD__SD3_CMD 0x59
@@ -283,3 +277,11 @@
>;
};
};
+
+&iomuxc_lpsr {
+ pinctrl_usbotg1: usbotg1grp {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
+ >;
+ };
+};
\ No newline at end of file
--
2.11.0
--
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 4/4] ARM: dts: imx7: Add "LPSR" to LPSR iomux pin names
From: Sascha Hauer @ 2017-01-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Fabio Estevam, devicetree, Sascha Hauer, Shawn Guo, kernel
In-Reply-To: <20170119090924.19636-1-s.hauer@pengutronix.de>
The i.MX7 has two iomux controllers. the iomuxc and the iomuxc_lpsr.
In a board dts we have to make sure that both controllers are supplied
with the correct pins. It's way too easy to do this wrong since only
a look into the reference manual can reveal which pins belong to which
controller. To make this clearer add "LPSR" to the pin names which
belong to the LPSR controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 16 ++---
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 2 +-
arch/arm/boot/dts/imx7d-nitrogen7.dts | 14 ++--
arch/arm/boot/dts/imx7d-pinfunc.h | 110 ++++++++++++++++----------------
arch/arm/boot/dts/imx7d-sdb.dts | 4 +-
arch/arm/boot/dts/imx7s-warp.dts | 2 +-
6 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index a9cc65725f19..a171545478be 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -596,29 +596,29 @@
pinctrl_gpio_lpsr: gpio1-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x59
- MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x59
- MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x59
+ MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x59
+ MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x59
+ MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x59
>;
};
pinctrl_i2c1: i2c1-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO05__I2C1_SDA 0x4000007f
- MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x4000007f
+ MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x4000007f
+ MX7D_PAD_LPSR_GPIO1_IO04__I2C1_SCL 0x4000007f
>;
};
pinctrl_cd_usdhc1: usdhc1-cd-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
+ MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
>;
};
pinctrl_uart1_ctrl2: uart1-ctrl2-grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x14 /* DSR */
- MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x14 /* RI */
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x14 /* DSR */
+ MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6 0x14 /* RI */
>;
};
};
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 1135bc99b3e7..ae45af1ad062 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -281,7 +281,7 @@
&iomuxc_lpsr {
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
+ MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
>;
};
};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index ce08f180f213..5d98e2b5d54b 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -712,33 +712,33 @@
pinctrl_hog_2: hoggrp-2 {
fsl,pins = <
- MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x7d
- MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO03__CCM_CLKO2 0x7d
>;
};
pinctrl_backlight_j9: backlightj9grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x7d
>;
};
pinctrl_pwm1: pwm1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x7d
>;
};
pinctrl_usbotg1: usbotg1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x7d
- MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x14
+ MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC 0x7d
+ MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14
>;
};
pinctrl_wdog1: wdog1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x75
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x75
>;
};
};
diff --git a/arch/arm/boot/dts/imx7d-pinfunc.h b/arch/arm/boot/dts/imx7d-pinfunc.h
index 7bc3c00e56c6..f6f7e78f8820 100644
--- a/arch/arm/boot/dts/imx7d-pinfunc.h
+++ b/arch/arm/boot/dts/imx7d-pinfunc.h
@@ -15,61 +15,61 @@
* <mux_reg conf_reg input_reg mux_mode input_val>
*/
-#define MX7D_PAD_GPIO1_IO00__GPIO1_IO0 0x0000 0x0030 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO00__PWM4_OUT 0x0000 0x0030 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_ANY 0x0000 0x0030 0x0000 0x2 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x0000 0x0030 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x0000 0x0030 0x0000 0x4 0x0
-#define MX7D_PAD_GPIO1_IO01__GPIO1_IO1 0x0004 0x0034 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x0004 0x0034 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 0x0034 0x0000 0x2 0x0
-#define MX7D_PAD_GPIO1_IO01__SAI1_MCLK 0x0004 0x0034 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO01__ANATOP_24M_OUT 0x0004 0x0034 0x0000 0x4 0x0
-#define MX7D_PAD_GPIO1_IO01__OBSERVE0_OUT 0x0004 0x0034 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO02__GPIO1_IO2 0x0008 0x0038 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO02__PWM2_OUT 0x0008 0x0038 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 0x0038 0x0564 0x2 0x3
-#define MX7D_PAD_GPIO1_IO02__SAI2_MCLK 0x0008 0x0038 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO02__CCM_CLKO1 0x0008 0x0038 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO02__OBSERVE1_OUT 0x0008 0x0038 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO02__USB_OTG1_ID 0x0008 0x0038 0x0734 0x7 0x3
-#define MX7D_PAD_GPIO1_IO03__GPIO1_IO3 0x000C 0x003C 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO03__PWM3_OUT 0x000C 0x003C 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C 0x003C 0x0570 0x2 0x3
-#define MX7D_PAD_GPIO1_IO03__SAI3_MCLK 0x000C 0x003C 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x000C 0x003C 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO03__OBSERVE2_OUT 0x000C 0x003C 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO03__USB_OTG2_ID 0x000C 0x003C 0x0730 0x7 0x3
-#define MX7D_PAD_GPIO1_IO04__GPIO1_IO4 0x0010 0x0040 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO04__USB_OTG1_OC 0x0010 0x0040 0x072C 0x1 0x1
-#define MX7D_PAD_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 0x0040 0x0594 0x2 0x1
-#define MX7D_PAD_GPIO1_IO04__UART5_DCE_CTS 0x0010 0x0040 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO04__UART5_DTE_RTS 0x0010 0x0040 0x0710 0x3 0x4
-#define MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x0010 0x0040 0x05D4 0x4 0x2
-#define MX7D_PAD_GPIO1_IO04__OBSERVE3_OUT 0x0010 0x0040 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO05__GPIO1_IO5 0x0014 0x0044 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR 0x0014 0x0044 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 0x0044 0x0598 0x2 0x1
-#define MX7D_PAD_GPIO1_IO05__UART5_DCE_RTS 0x0014 0x0044 0x0710 0x3 0x5
-#define MX7D_PAD_GPIO1_IO05__UART5_DTE_CTS 0x0014 0x0044 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO05__I2C1_SDA 0x0014 0x0044 0x05D8 0x4 0x2
-#define MX7D_PAD_GPIO1_IO05__OBSERVE4_OUT 0x0014 0x0044 0x0000 0x6 0x0
-#define MX7D_PAD_GPIO1_IO06__GPIO1_IO6 0x0018 0x0048 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO06__USB_OTG2_OC 0x0018 0x0048 0x0728 0x1 0x1
-#define MX7D_PAD_GPIO1_IO06__FLEXTIMER1_CH6 0x0018 0x0048 0x059C 0x2 0x1
-#define MX7D_PAD_GPIO1_IO06__UART5_DCE_RX 0x0018 0x0048 0x0714 0x3 0x4
-#define MX7D_PAD_GPIO1_IO06__UART5_DTE_TX 0x0018 0x0048 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO06__I2C2_SCL 0x0018 0x0048 0x05DC 0x4 0x2
-#define MX7D_PAD_GPIO1_IO06__CCM_WAIT 0x0018 0x0048 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO06__KPP_ROW4 0x0018 0x0048 0x0624 0x6 0x1
-#define MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x001C 0x004C 0x0000 0x0 0x0
-#define MX7D_PAD_GPIO1_IO07__USB_OTG2_PWR 0x001C 0x004C 0x0000 0x1 0x0
-#define MX7D_PAD_GPIO1_IO07__FLEXTIMER1_CH7 0x001C 0x004C 0x05A0 0x2 0x1
-#define MX7D_PAD_GPIO1_IO07__UART5_DCE_TX 0x001C 0x004C 0x0000 0x3 0x0
-#define MX7D_PAD_GPIO1_IO07__UART5_DTE_RX 0x001C 0x004C 0x0714 0x3 0x5
-#define MX7D_PAD_GPIO1_IO07__I2C2_SDA 0x001C 0x004C 0x05E0 0x4 0x2
-#define MX7D_PAD_GPIO1_IO07__CCM_STOP 0x001C 0x004C 0x0000 0x5 0x0
-#define MX7D_PAD_GPIO1_IO07__KPP_COL4 0x001C 0x004C 0x0604 0x6 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x0000 0x0030 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__PWM4_OUT 0x0000 0x0030 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_ANY 0x0000 0x0030 0x0000 0x2 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x0000 0x0030 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG__RST_B_DEB 0x0000 0x0030 0x0000 0x4 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__GPIO1_IO1 0x0004 0x0034 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x0004 0x0034 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__CCM_ENET_REF_CLK3 0x0004 0x0034 0x0000 0x2 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__SAI1_MCLK 0x0004 0x0034 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__ANATOP_24M_OUT 0x0004 0x0034 0x0000 0x4 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO01__OBSERVE0_OUT 0x0004 0x0034 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__GPIO1_IO2 0x0008 0x0038 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__PWM2_OUT 0x0008 0x0038 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__CCM_ENET_REF_CLK1 0x0008 0x0038 0x0564 0x2 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO02__SAI2_MCLK 0x0008 0x0038 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__CCM_CLKO1 0x0008 0x0038 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__OBSERVE1_OUT 0x0008 0x0038 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO02__USB_OTG1_ID 0x0008 0x0038 0x0734 0x7 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x000C 0x003C 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__PWM3_OUT 0x000C 0x003C 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__CCM_ENET_REF_CLK2 0x000C 0x003C 0x0570 0x2 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO03__SAI3_MCLK 0x000C 0x003C 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__CCM_CLKO2 0x000C 0x003C 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__OBSERVE2_OUT 0x000C 0x003C 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO03__USB_OTG2_ID 0x000C 0x003C 0x0730 0x7 0x3
+#define MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x0010 0x0040 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO04__USB_OTG1_OC 0x0010 0x0040 0x072C 0x1 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO04__FLEXTIMER1_CH4 0x0010 0x0040 0x0594 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO04__UART5_DCE_CTS 0x0010 0x0040 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO04__UART5_DTE_RTS 0x0010 0x0040 0x0710 0x3 0x4
+#define MX7D_PAD_LPSR_GPIO1_IO04__I2C1_SCL 0x0010 0x0040 0x05D4 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO04__OBSERVE3_OUT 0x0010 0x0040 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x0014 0x0044 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__USB_OTG1_PWR 0x0014 0x0044 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__FLEXTIMER1_CH5 0x0014 0x0044 0x0598 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO05__UART5_DCE_RTS 0x0014 0x0044 0x0710 0x3 0x5
+#define MX7D_PAD_LPSR_GPIO1_IO05__UART5_DTE_CTS 0x0014 0x0044 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO05__I2C1_SDA 0x0014 0x0044 0x05D8 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO05__OBSERVE4_OUT 0x0014 0x0044 0x0000 0x6 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6 0x0018 0x0048 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__USB_OTG2_OC 0x0018 0x0048 0x0728 0x1 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO06__FLEXTIMER1_CH6 0x0018 0x0048 0x059C 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO06__UART5_DCE_RX 0x0018 0x0048 0x0714 0x3 0x4
+#define MX7D_PAD_LPSR_GPIO1_IO06__UART5_DTE_TX 0x0018 0x0048 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL 0x0018 0x0048 0x05DC 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO06__CCM_WAIT 0x0018 0x0048 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO06__KPP_ROW4 0x0018 0x0048 0x0624 0x6 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7 0x001C 0x004C 0x0000 0x0 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__USB_OTG2_PWR 0x001C 0x004C 0x0000 0x1 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__FLEXTIMER1_CH7 0x001C 0x004C 0x05A0 0x2 0x1
+#define MX7D_PAD_LPSR_GPIO1_IO07__UART5_DCE_TX 0x001C 0x004C 0x0000 0x3 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__UART5_DTE_RX 0x001C 0x004C 0x0714 0x3 0x5
+#define MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA 0x001C 0x004C 0x05E0 0x4 0x2
+#define MX7D_PAD_LPSR_GPIO1_IO07__CCM_STOP 0x001C 0x004C 0x0000 0x5 0x0
+#define MX7D_PAD_LPSR_GPIO1_IO07__KPP_COL4 0x001C 0x004C 0x0604 0x6 0x1
#define MX7D_PAD_GPIO1_IO08__GPIO1_IO8 0x0014 0x026C 0x0000 0x0 0x0
#define MX7D_PAD_GPIO1_IO08__SD1_VSELECT 0x0014 0x026C 0x0000 0x1 0x0
#define MX7D_PAD_GPIO1_IO08__WDOG1_WDOG_B 0x0014 0x026C 0x0000 0x2 0x0
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 84f35a6cbb30..2afe48439948 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -635,13 +635,13 @@
&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x74
>;
};
pinctrl_pwm1: pwm1grp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO01__PWM1_OUT 0x110b0
+ MX7D_PAD_LPSR_GPIO1_IO01__PWM1_OUT 0x110b0
>;
};
};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index cbb5bc16e713..d5237fd0fa65 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -442,7 +442,7 @@
&iomuxc_lpsr {
pinctrl_wdog: wdoggrp {
fsl,pins = <
- MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+ MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B 0x74
>;
};
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 00/18] FSI device driver introduction
From: Greg KH @ 2017-01-19 9:11 UTC (permalink / raw)
To: Christopher Bostic
Cc: Rob Herring, Mark Rutland, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
Michael Turquette, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
Open List OF Flattened dev tree bindings,
Moderated list: ARM PORT, Joel Stanley, Jeremy Kerr,
Linux open list, Andrew Jeffery, Alistair Popple,
Benjamin Herrenschmidt, Chris Bostic
In-Reply-To: <CAA0LjjVAJiF8yF8prE22Uz18A+EWnNAPis+4LydGRK2BVp6NSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jan 17, 2017 at 04:00:41PM -0600, Christopher Bostic wrote:
> On Tue, Jan 17, 2017 at 1:42 AM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > On Mon, Jan 16, 2017 at 03:22:48PM -0600, christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> >
> > <snip>
> >
> > Only this, and patch 02/18 came through, did something get stuck on your
> > end?
> >
>
> Hi Greg,
>
> Yes had an issue with the server blocking send, investigating why.
It's still failing, I keep getting only the 00 email :(
--
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 V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-19 9:25 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel, Peter Senna Tschudin, Rob Herring, Mark Rutland,
Daniel Vetter, Peter Senna Tschudin, Takashi Iwai, Yakir Yang,
Jiri Slaby, Martyn Welch, Ian Campbell, Russell King,
Javier Martinez Canillas, Thierry Reding, Guenter Roeck,
martin.donnelly, devicetree@vger.kernel.org, Pawel Moll,
Mauro Carvalho Chehab, enric.balletb
In-Reply-To: <2338437.Vj2otdygnZ@avalon>
On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> Hi Peter,
>
> On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> > On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> > >>>> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > >>>>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> > >>>>>> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> > >>>>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin
> wrote:
> > >>>>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > >>>>>>>> display bridge.
> > >>>>>>>>
> > >>>>>>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> > >>>>>>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> > >>>>>>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> > >>>>>>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > >>>>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > >>>>>>>> Cc: Rob Herring <robh@kernel.org>
> > >>>>>>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > >>>>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> > >>>>>>>> ---
> > >>>>>>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6,
> > >>>>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> > >>>>>>>> removed it from the commit message.
> >
> > [...]
> >
> > >>>>>>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++
> > >>>>>>>
> > >>>>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> > >>>>>>
> > >>>>>> b850v3 is the name of the product, this is why the proposed name.
> > >>>>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> > >>>>>
> > >>>>> Humm, b850v3 is the board name? This node should be the name of the
> > >>>>> bridge chip.
> > >>>>
> > >>>> From the cover letter:
> > >>>>
> > >>>> -- // --
> > >>>> There are two physical bridges on the video signal pipeline: a
> > >>>> STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The hardware and
> > >>>> firmware made it complicated for this binding to comprise two device
> > >>>> tree nodes, as the design goal is to configure both bridges based on
> > >>>> the LVDS signal, which leave the driver powerless to control the
> > >>>> video processing pipeline. The two bridges behaves as a single bridge,
> > >>>> and the driver is only needed for telling the host about EDID / HPD,
> > >>>> and for giving the host powers to ack interrupts. The video signal
> > >>>> pipeline
> > >>>>
> > >>>> is as follows:
> > >>>> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> > >>>> output
> > >>>>
> > >>>> -- // --
> > >>>
> > >>> You forgot to prefix your patch series with [HACK] ;-)
> > >>>
> > >>> How about fixing the issues that make the two DT nodes solution
> > >>> difficult ? What are they ?
> > >>
> > >> The Firmware and the hardware design. Both bridges, with stock firmware,
> > >> are fully capable of providig EDID information and handling interrupts.
> > >> But on this specific design, with this specific firmware, I need to read
> > >> EDID from one bridge, and handle interrupts on the other.
> > >
> > > Which firmware are you talking about ? Firmware running on the bridges, or
> > > somewhere else ?
> >
> > Each bridge has it's own external flash containing a binary firmware.
> > The goal of the firmware is to configure the output end based on the
> > input end. This is part of what makes handling EDID and HPD challenging.
> >
> > >> Back when I was starting the development I could not come up with a
> > >> proper way to split EDID and interrupts between two bridges in a way
> > >> that would result in a fully functional connector. Did I miss something?
> > >
> > > You didn't, we did :-) I've been telling for quite some time now that we
> > > must decouple bridges from connectors, and this is another example of why
> > > we have such a need. Bridges should expose additional functions needed to
> > > implement connector operations, and the connector should be instantiated
> > > by the display driver with the help of bridge operations. You could then
> > > create a connector that relies on one bridge to read the EDID and on the
> > > other bridge to handle HPD.
> >
> > Ah thanks. So for now the single DT node approach is acceptable, right?
> > The problem is that even if the driver is getting better on each
> > iteration, the single DT node for two chips issue comes back often and I
> > believe is _the_ issue preventing the driver from getting upstream. V1
> > was sent ~ 8 months ago...
> >
> > Can I have some blessing on the single DT node approach for now?
>
> With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are
> acceptable on the driver side, but you need two nodes in DT.
So can I make two node DT "in the right way" and work around current
connectors vs. bridge limitations on the driver side? This seems to be
doable.
Then I could fix bridge API, with my own driver and update API clients
affected by the change...
>
> > I'm one of the 3 proposed maintainers for the driver, and I'm willing to
> > maintain the driver on the long run, as is the same with the other two
> > proposed maintainers. So when the time to split the node in two comes,
> > we will be around, and willing to do it ourselves.
>
> How about putting that team of 3 maintainers to work on fixing the problem in
> the bridge API ? :-)
Guess you would be a good lawyer! My point was not exactly that we could
work in parallel. Point was that there is redundancy in case one or two
of us loose interest. But nice try! :-)
Chances of having resources to fix bridge API and clients were better 6
months ago, but let me see what I can get. Last blocking issue was the
migration to atomic, now this. I'm going to need to answer what the next
blocking issue is going to be.
Actually in these ~8 months one bit of the required changes was
accepted: dc80d7038883, but this was generic and not related to our
specific use case.
Thanks!
Peter
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: mt8173: add reference clock for usb
From: Greg Kroah-Hartman @ 2017-01-19 9:37 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
Ian Campbell, linux-usb, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1484719707-12107-4-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jan 18, 2017 at 02:08:25PM +0800, Chunfeng Yun wrote:
> add 26M reference clock for ssusb and xhci nodes
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
This patch doesn't apply to my tree :(
^ permalink raw reply
* Re: [PATCH] of: Export __of_find_all_nodes()
From: Alexander Sverdlin @ 2017-01-19 9:43 UTC (permalink / raw)
To: Frank Rowand; +Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <587FDF1B.1060206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi!
On 18/01/17 22:33, Frank Rowand wrote:
>> This is necessary for for_each_of_allnodes() to work in the modules.
>>
>> Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> drivers/of/base.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 2eb4dea62b84..f576c33e0b84 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -270,6 +270,7 @@ struct device_node *__of_find_all_nodes(struct device_node *prev)
>> }
>> return np;
>> }
>> +EXPORT_SYMBOL_GPL(__of_find_all_nodes);
>>
>> /**
>> * of_find_all_nodes - Get next node in global list
>>
> Quoting Rob from the last request for this:
>
> "What driver needs this? This isn't really a function I'd expect drivers to use."
This one and the one from previous patch/mail are used in a module which reads DT overlays
from pluggable extension boards, eventually performs some sanity checks/corrections and
applies these overlays. This eventual corrections require low-level access to DT.
I cannot judge, how relevant this usecase is for the community, but I was driven by the fact,
that the functions which require the functions I export are defined statically in .h files
and therefore are exposed to the modules.
--
Best regards,
Alexander Sverdlin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox