* [PATCH v2 4/4] ARM: dts: imx6dl-riotboard: fix OTG regulator polarity
From: Alexander Kurz @ 2018-05-29 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529062021.3154-1-akurz@blala.de>
USB OTG power is switched on when the GPIO is pulled low.
Signed-off-by: Alexander Kurz <akurz@blala.de>
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
index a6851bfebbdb..89b06e20480d 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -70,8 +70,7 @@
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
- gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
- enable-active-high;
+ gpio = <&gpio3 22 GPIO_ACTIVE_LOW>;
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Eugen Hristev @ 2018-05-29 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3cc1894-2d7d-93b6-a9de-ed9ca4564ae9@axentia.se>
On 28.05.2018 13:10, Peter Rosin wrote:
> On 2018-05-28 00:11, Peter Rosin wrote:
>> On 2018-05-27 11:18, Peter Rosin wrote:
>>> On 2018-05-25 16:51, Tudor Ambarus wrote:
>>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>>>> (7th slave).
>>>
>>> Exactly how do I accomplish that?
>>>
>>> I can see how I can move the LCD between slave DDR port 2 and 3 by
>>> selecting LCDC DMA master 8 or 9 (but according to the above it should
>>> not matter). The big question is how I control what slave the NAND flash
>>> is going to use? I find nothing in the datasheet, and the code is also
>>> non-transparent enough for me to figure it out by myself without
>>> throwing out this question first...
>> [...]
>> and the output is
>>
>> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
>>
>> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
>> or how to find out. I guess IF2 is not in use since that does not allow any
>> DDR2 port as slave...
Hello Peter,
Thank you for all the information, I will chip in to help a little bit.
The Master/channel is described in the device tree. The channel has a
controller, a mem/periph interface and a periph ID, plus a FIFO
configuration.
The dma chan number reported in the dmesg is just software. Here is an
example from DT:
dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(1)>,
<&dma0 2 AT91_DMA_CFG_PER_ID(2)>;
you can match this with the help from
Documentation/devicetree/bindings/dma/atmel-dma.txt:
1. A phandle pointing to the DMA controller.
2. The memory interface (16 most significant bits), the peripheral
interface
(16 less significant bits).
3. Parameters for the at91 DMA configuration register which are device
dependent:
- bit 7-0: peripheral identifier for the hardware handshaking
interface. The
identifier can be different for tx and rx.
- bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
So , what was Tudor asking for, is your DT for the ebi node (if you are
using ebi), or, your NFC SRAM (Nand Flash Controller SRAM) DMA
devicetree chunk, so, we can figure out which type of DMA are you using.
Normally, the ebi should be connected to both DMA0 and DMA1 on those
interfaces specified in DT. Which ones you want to use, depends on your
setup (and contention on the bus/accesses, like in your case, the HLCDC)
Thats why we have multiple choices, to pick the right one for each case.
In our vanilla DT sama5d3.dtsi we do not have DMA described for ebi
interface.
Eugen
>> [...]
^ permalink raw reply
* [PATCH 0/2] Add Mediatek X20 Development Board support
From: Matthias Brugger @ 2018-05-29 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529045258.1415-1-manivannan.sadhasivam@linaro.org>
Hi Manivannan,
it's nice to see that someone at Linaro cares about upstreaming the 96 board.
>From what I can see, your patches add the very same support to the board as
does the mt6797 evaluation board. Do you have plans to upstream more drivers for
the board? Do you have a roadmap or something?
I'm asking becuase I don't want to have just another dead devicetree in the
kernel which does nothing but provides a boot to rootfs. Especially as this can
be achieved on the same board with the EVB dts.
Regards,
Matthias
On 29/05/18 06:52, Manivannan Sadhasivam wrote:
> Add devicetree support for Mediatek X20 Development Board by Archermind.
> This board is based on the Deca-Core MT6797 SoC from Mediatek and is
> one of the 96Boards Consumer Edition platform.
>
> With this devicetree change, board can boot into initramfs.
>
> More information about this board can be found in 96Boards product page:
> https://www.96boards.org/product/mediatek-x20/
>
> Manivannan Sadhasivam (2):
> dt-bindings: Add vendor prefix for ArcherMind
> arm64: dts: Add Mediatek X20 Development Board support
>
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> 3 files changed, 35 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>
^ permalink raw reply
* [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
From: Geert Uytterhoeven @ 2018-05-29 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8736yb5jez.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On Tue, May 29, 2018 at 3:44 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>> > +&hdmi0_con {
>> > + remote-endpoint = <&rcar_dw_hdmi0_out>;
>> > +};
>>
>> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
>> Can we do that now (with stubs?), or does this have to wait until r8a77965 has
>> received HDMI sound support?
>
> HDMI sound doesn't use hdmi0_con.
> You can do it now, thanks
Thanks, so hdmi0_con can be moved now.
But HDMI sound does use hdmi0/ports/port at 2. right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.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
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: r8a77965: Add Watchdog Timer controller node using RCLK Watchdog Timer
From: Yoshihiro Kaneko @ 2018-05-29 7:01 UTC (permalink / raw)
To: linux-arm-kernel
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Add a device node for the Watchdog Timer (WDT) controller on the Renesas
R-Car M3-N (R8A77965) SoC.
Based on a similar patch of the R8A7796 device tree
by Geert Uytterhoeven <geert+renesas@glider.be>.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This patch is based on the devel branch of Simon Horman's renesas tree.
v2 [Yoshihiro Kaneko]
- add tags
* As suggested by Geert Uytterhoeven
- fix the summary prefix of the subject
- fix the notation of the name of SoC
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 486aeca..fb7100f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -139,8 +139,13 @@
ranges;
wdt0: watchdog at e6020000 {
+ compatible = "renesas,r8a77965-wdt",
+ "renesas,rcar-gen3-wdt";
reg = <0 0xe6020000 0 0x0c>;
- /* placeholder */
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
+ resets = <&cpg 402>;
+ status = "disabled";
};
gpio0: gpio at e6050000 {
--
1.9.1
^ permalink raw reply related
* [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Javier Martinez Canillas @ 2018-05-29 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528191327.23772-1-krzk@kernel.org>
On Mon, May 28, 2018 at 9:13 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> From: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings, make development of new platforms easier and allow to make
> cleanup of the existing code and device tree files, lets mark some
> Samsung Exynos SoC platform bindings as unstable. This means that
> bindings can may change at any time and users should use the dtb file
> compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
Javier
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-29 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19d68279-072e-7646-6fdd-8649578229ea@microchip.com>
On 2018-05-29 08:30, Eugen Hristev wrote:
>
>
> On 28.05.2018 13:10, Peter Rosin wrote:
>> On 2018-05-28 00:11, Peter Rosin wrote:
>>> On 2018-05-27 11:18, Peter Rosin wrote:
>>>> On 2018-05-25 16:51, Tudor Ambarus wrote:
>>>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>>>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>>>>> (7th slave).
>>>>
>>>> Exactly how do I accomplish that?
>>>>
>>>> I can see how I can move the LCD between slave DDR port 2 and 3 by
>>>> selecting LCDC DMA master 8 or 9 (but according to the above it should
>>>> not matter). The big question is how I control what slave the NAND flash
>>>> is going to use? I find nothing in the datasheet, and the code is also
>>>> non-transparent enough for me to figure it out by myself without
>>>> throwing out this question first...
>
> >> [...]
>
>>> and the output is
>>>
>>> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
>>>
>>> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
>>> or how to find out. I guess IF2 is not in use since that does not allow any
>>> DDR2 port as slave...
>
> Hello Peter,
>
> Thank you for all the information, I will chip in to help a little bit.
> The Master/channel is described in the device tree. The channel has a
> controller, a mem/periph interface and a periph ID, plus a FIFO
> configuration.
>
> The dma chan number reported in the dmesg is just software.
Got that, that was why I added the various additional traces in that
horrid patch in the mail you are responding to :-)
> Here is an
> example from DT:
> dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(1)>,
> <&dma0 2 AT91_DMA_CFG_PER_ID(2)>;
>
> you can match this with the help from
> Documentation/devicetree/bindings/dma/atmel-dma.txt:
>
> 1. A phandle pointing to the DMA controller.
>
> 2. The memory interface (16 most significant bits), the peripheral
> interface
> (16 less significant bits).
>
> 3. Parameters for the at91 DMA configuration register which are device
>
> dependent:
>
> - bit 7-0: peripheral identifier for the hardware handshaking
> interface. The
> identifier can be different for tx and rx.
>
> - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
>
>
> So , what was Tudor asking for, is your DT for the ebi node (if you are
> using ebi), or, your NFC SRAM (Nand Flash Controller SRAM) DMA
> devicetree chunk, so, we can figure out which type of DMA are you using.
>
> Normally, the ebi should be connected to both DMA0 and DMA1 on those
> interfaces specified in DT. Which ones you want to use, depends on your
> setup (and contention on the bus/accesses, like in your case, the HLCDC)
>
> Thats why we have multiple choices, to pick the right one for each case.
> In our vanilla DT sama5d3.dtsi we do not have DMA described for ebi
> interface.
Ahh, *that* NAND DMA configuration. Of course, how silly of me...
This is a setup based on the at91-linea.dtsi "CPU" board. That dtsi should
have the relevant NAND/DMA info. Also, at91-nattis-2-natte-2.dts describes
the older HW (with a 1024x768 panel) that is also affected, if you want a
full device tree to look at.
Looks like I didn't make a selection, quoting from at91-linea.dtsi:
&ebi {
pinctrl-0 = <&pinctrl_ebi_nand_addr>;
pinctrl-names = "default";
status = "okay";
};
&nand_controller {
status = "okay";
nand: nand at 3 {
reg = <0x3 0x0 0x2>;
atmel,rb = <0>;
nand-bus-width = <8>;
nand-ecc-mode = "hw";
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
nand-on-flash-bbt;
label = "atmel_nand";
};
};
The reason is probably because the sama5d3xek device-trees didn't at the
time of "fork". Does anybody have any suggestion for some extra properties
to try in the above nodes?
Further, I forgot that I had actually upstreamed linea support for
at91bootstrap, so relevant NAND timings etc can be found in lpddr1_init()
in
at91bootstrap/contrib/board/axentia/sama5d3_linea/sama5d3_linea.c
Cheers,
Peter
^ permalink raw reply
* [patch v22 1/4] drivers: jtag: Add JTAG core driver
From: Greg KH @ 2018-05-29 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM5PR0501MB24490173AD50A2E478DFCF35B16E0@AM5PR0501MB2449.eurprd05.prod.outlook.com>
On Mon, May 28, 2018 at 03:59:46PM +0000, Oleksandr Shamray wrote:
> > > + const struct jtag_ops *ops;
> > > + int id;
> > > + bool opened;
> >
> > You shouldn't care about this, but ok...
>
> Jtag HW not support to using with multiple requests from different users. So we prohibit this.
Ok, but then that's a userspace problem, not your driver's problem.
Serial ports can't handle multiple requests in a sane way either, and so
it's a userspace bug if they do that. It's not up to the kernel to try
to prevent it, and really, you are not preventing this from happening at
all, you are only keeping more than one open() call from happening. You
aren't serializing the device access at all.
So you are giving yourself a false sense of "We are protecting the
device" here. Just drop the whole "only one open() call" logic
entirely. It will make your kernel code simpler and you aren't giving
yourself false-hope that you really prevented userspace from doing
something stupid :)
> > > + case JTAG_IOCRUNTEST:
> > > + if (copy_from_user(&idle, (const void __user *)arg,
> > > + sizeof(struct jtag_run_test_idle)))
> > > + return -EFAULT;
> > > +
> > > + if (idle.endstate > JTAG_STATE_PAUSEDR)
> > > + return -EINVAL;
> >
> > No validation that idle contains sane values? Don't make every jtag driver
> > have to do this type of validation please.
> >
>
> I have partially validation of idle structure (if (idle.endstate > JTAG_STATE_PAUSEDR)).
> But I will add more validation.
Go to the nearest whiteboard and write this at the top:
ALL INPUT IS EVIL
Don't erase it. You have to validate all the things, otherwise
something bad will happen, I guarantee it. Wait until the syzbot gets
ahold of this layer if you don't believe me :)
> > > +static int jtag_open(struct inode *inode, struct file *file) {
> > > + struct jtag *jtag = container_of(file->private_data, struct jtag,
> > > +miscdev);
> > > +
> > > + if (mutex_lock_interruptible(&jtag->open_lock))
> > > + return -ERESTARTSYS;
> >
> > Why restart? Just grab the lock, you don't want to have to do restartable
> > logic in userspace, right?
>
> Will change like:
>
> ret = mutex_lock_interruptible(&jtag->open_lock);
> if (ret)
> return ret;
No, what's wrong with a simple:
mutex_lock();
?
You are only holding it for a very short time, people can wait, there is
no rush here or "fast path" happening.
Anyway, this whole lock should just go away entirely, due to the lack of
needing to track open() calls. But in the future, keep locks simple, no
need to add complexity when it is not warranted.
> > > + if (jtag->opened) {
> > > + mutex_unlock(&jtag->open_lock);
> > > + return -EBUSY;
> >
> > Why do you care about only 1 userspace open call? What does that buy you?
> > Userspace can always pass around that file descriptor and use it in multiple
> > places, so you are not really "protecting" yourself from anything.
> >
>
> Accessing to JTAG HW from multiple processes will make confusion in the work of the JTAG protocol.
> And I want to prohibit this.
See my previous comments for why your attempt at protecting open() does
not prevent this from happening. Hint, you forgot about dup(3) :(
thanks,
greg k-h
^ permalink raw reply
* [RESEND PATCH] dmaengine: pxa: add a default requestor policy
From: Vinod @ 2018-05-29 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526095418.22960-1-robert.jarzmik@free.fr>
On 26-05-18, 11:54, Robert Jarzmik wrote:
> @@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan *dchan)
> dma_pool_destroy(chan->desc_pool);
> chan->desc_pool = NULL;
>
> + chan->drcmr = (u32)-1;
why not use U32_MAX for this?
--
~Vinod
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Eugen Hristev @ 2018-05-29 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ae5fc1d-9f02-9742-f801-2252389294eb@axentia.se>
On 29.05.2018 10:10, Peter Rosin wrote:
> On 2018-05-29 08:30, Eugen Hristev wrote:
>>
>>
>> On 28.05.2018 13:10, Peter Rosin wrote:
>>> On 2018-05-28 00:11, Peter Rosin wrote:
>>>> On 2018-05-27 11:18, Peter Rosin wrote:
>>>>> On 2018-05-25 16:51, Tudor Ambarus wrote:
>>>>>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>>>>>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>>>>>> (7th slave).
>>>>>
>>>>> Exactly how do I accomplish that?
>>>>>
>>>>> I can see how I can move the LCD between slave DDR port 2 and 3 by
>>>>> selecting LCDC DMA master 8 or 9 (but according to the above it should
>>>>> not matter). The big question is how I control what slave the NAND flash
>>>>> is going to use? I find nothing in the datasheet, and the code is also
>>>>> non-transparent enough for me to figure it out by myself without
>>>>> throwing out this question first...
>>
>> >> [...]
>>
>>>> and the output is
>>>>
>>>> atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
>>>>
>>>> So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
>>>> or how to find out. I guess IF2 is not in use since that does not allow any
>>>> DDR2 port as slave...
>>
>> Hello Peter,
>>
>> Thank you for all the information, I will chip in to help a little bit.
>> The Master/channel is described in the device tree. The channel has a
>> controller, a mem/periph interface and a periph ID, plus a FIFO
>> configuration.
>>
>> The dma chan number reported in the dmesg is just software.
>
> Got that, that was why I added the various additional traces in that
> horrid patch in the mail you are responding to :-)
>
>> Here is an
>> example from DT:
>> dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(1)>,
>> <&dma0 2 AT91_DMA_CFG_PER_ID(2)>;
>>
>> you can match this with the help from
>> Documentation/devicetree/bindings/dma/atmel-dma.txt:
>>
>> 1. A phandle pointing to the DMA controller.
>>
>> 2. The memory interface (16 most significant bits), the peripheral
>> interface
>> (16 less significant bits).
>>
>> 3. Parameters for the at91 DMA configuration register which are device
>>
>> dependent:
>>
>> - bit 7-0: peripheral identifier for the hardware handshaking
>> interface. The
>> identifier can be different for tx and rx.
>>
>> - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
>>
>>
>> So , what was Tudor asking for, is your DT for the ebi node (if you are
>> using ebi), or, your NFC SRAM (Nand Flash Controller SRAM) DMA
>> devicetree chunk, so, we can figure out which type of DMA are you using.
>>
>> Normally, the ebi should be connected to both DMA0 and DMA1 on those
>> interfaces specified in DT. Which ones you want to use, depends on your
>> setup (and contention on the bus/accesses, like in your case, the HLCDC)
>>
>> Thats why we have multiple choices, to pick the right one for each case.
>> In our vanilla DT sama5d3.dtsi we do not have DMA described for ebi
>> interface.
>
> Ahh, *that* NAND DMA configuration. Of course, how silly of me...
>
> This is a setup based on the at91-linea.dtsi "CPU" board. That dtsi should
> have the relevant NAND/DMA info. Also, at91-nattis-2-natte-2.dts describes
> the older HW (with a 1024x768 panel) that is also affected, if you want a
> full device tree to look at.
>
> Looks like I didn't make a selection, quoting from at91-linea.dtsi:
Ok, so try to force the nand to use DDR port 1 : use DMAC0 or DMAC1 on
the interfaces corresponding just to DDR port 1, and see if helps (while
leaving HLCDC on both masters - DDR port 2 and 3).
One more thing: what are the actual nand commands which you use when you
get the glitches? read/write/erase ... ?
What happens if you try to minimize the nand access? you also said at
some point that only *some* nand accesses cause glitches.
Another thing : even if the LCD displays a still image, the DMA still
feeds data to the LCD right ?
>
> &ebi {
> pinctrl-0 = <&pinctrl_ebi_nand_addr>;
> pinctrl-names = "default";
> status = "okay";
> };
>
> &nand_controller {
> status = "okay";
>
> nand: nand at 3 {
> reg = <0x3 0x0 0x2>;
> atmel,rb = <0>;
> nand-bus-width = <8>;
> nand-ecc-mode = "hw";
> nand-ecc-strength = <4>;
> nand-ecc-step-size = <512>;
> nand-on-flash-bbt;
> label = "atmel_nand";
> };
> };
>
> The reason is probably because the sama5d3xek device-trees didn't at the
> time of "fork". Does anybody have any suggestion for some extra properties
> to try in the above nodes?
>
> Further, I forgot that I had actually upstreamed linea support for
> at91bootstrap, so relevant NAND timings etc can be found in lpddr1_init()
> in
>
> at91bootstrap/contrib/board/axentia/sama5d3_linea/sama5d3_linea.c
>
> Cheers,
> Peter
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 0/2] Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-05-29 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06dbc5ef-5bba-f3e0-1b57-3eaeab26ed68@gmail.com>
Hi Matthias,
On Tue, May 29, 2018 at 08:38:27AM +0200, Matthias Brugger wrote:
> Hi Manivannan,
>
> it's nice to see that someone at Linaro cares about upstreaming the 96 board.
> From what I can see, your patches add the very same support to the board as
> does the mt6797 evaluation board. Do you have plans to upstream more drivers for
> the board? Do you have a roadmap or something?
>
> I'm asking becuase I don't want to have just another dead devicetree in the
> kernel which does nothing but provides a boot to rootfs. Especially as this can
> be achieved on the same board with the EVB dts.
>
I can understand your concern here. I do have plans to add more drivers
in the future for this board but I can't give you any roadmap for that
since it mostly falls under the spare time work and I have been doing a
similar kind of work for the Bubblegum-96 board in parallel.
At most I can guarentee that this board's functionality will be added
gradually in upcoming days.
Thanks,
Mani
> Regards,
> Matthias
>
> On 29/05/18 06:52, Manivannan Sadhasivam wrote:
> > Add devicetree support for Mediatek X20 Development Board by Archermind.
> > This board is based on the Deca-Core MT6797 SoC from Mediatek and is
> > one of the 96Boards Consumer Edition platform.
> >
> > With this devicetree change, board can boot into initramfs.
> >
> > More information about this board can be found in 96Boards product page:
> > https://www.96boards.org/product/mediatek-x20/
> >
> > Manivannan Sadhasivam (2):
> > dt-bindings: Add vendor prefix for ArcherMind
> > arm64: dts: Add Mediatek X20 Development Board support
> >
> > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> > 3 files changed, 35 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> >
^ permalink raw reply
* [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Lee Jones @ 2018-05-29 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8d8b0f05-7f04-e718-7a45-148af38a03d4@st.com>
On Mon, 28 May 2018, Amelie DELAUNAY wrote:
> On 05/24/2018 09:13 AM, Linus Walleij wrote:
> > On Fri, May 18, 2018 at 9:29 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> >> On 05/17/2018 08:36 AM, Lee Jones wrote:
> >>> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
> >>>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
> >>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> >>>>>
> >>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
> >>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
> >>>>>> child drivers into a single PINCTRL/GPIO driver because of the following
> >>>>>> reasons:
> >>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
> >>>>>> not used on any of the boards using an stmfx and supported by Linux, so
> >>>>>> no way to test these functions, and no need to maintain them while they
> >>>>>> are not being used.
> >>>>>> - But, in the case a new board will use more than GPIO function on
> >>>>>> stmfx, the actual implementation allow to easily extract common init
> >>>>>> part of stmfx and put it in an MFD driver.
> >>>>>>
> >>>>>> So I could remove gpio sub-node and put its contents in stmfx node and
> >>>>>> keep single PINCTRL/GPIO driver for the time being.
> >>>>>> Please advise,
> >>>>>
> >>>>> I would normally advice to use the right modeling from the start, create
> >>>>> the MFD driver and spawn the devices from there. It is confusing
> >>>>> if the layout of the driver(s) doesn't really match the layout of the
> >>>>> hardware.
> >>>>>
> >>>>> I understand that it is a pain to write new MFD drivers to get your
> >>>>> things going and it would be "nice to get this working really quick
> >>>>> now" but in my experience it is better to do it right from the start.
> >>>>>
> >>>>
> >>>> Hi Linus,
> >>>>
> >>>> Thanks for your advice. I understand the point.
> >>>> So, the right modeling would be to:
> >>>> - create an MFD driver with the common init part of stmfx
> >>>> - remove all common init part of stmfx-pinctrl driver and keep only all
> >>>> gpio/pinctrl functions.
> >>>>
> >>>> I will not develop the other stmfx functions (IDD measurement driver and
> >>>> TouchScreen controller driver) because, as explained ealier, they are
> >>>> not used on any of the boards using an stmfx and supported by Linux, so
> >>>> no way to test these functions, and no need to maintain them while they
> >>>> are not being used.
> >>>>
> >>>> Lee, are you OK with that ?
> >>>
> >>> I missed a lot of this conversation I think, but from what I've read,
> >>> it sounds fine.
> >>>
> >>
> >> I summarize the situation:
> >> - I still don't have an official datasheet for STMFX device which could
> >> justify the use of an MFD driver;
> >> - the MFD driver will contain the STMFX chip initialization stuff such
> >> as regmap initialization (regmap structure will be shared with the
> >> child), chip initialization, global interrupt management;
> >> - there will be only one child (GPIO/PINCTRL node) for the time being.
> >
> > But there will be more devices in it. And they will invariably be put
> > to use later, and there will be new versions of the chip as well, and
> > then you will be happy about doing the MFD core, which makes it
> > easy to add new variants with different subdevices.
> >
> >> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
> >> it still sound fine after this summary ? :)
> >
> > No I think it should use an MFD core.
> >
> > Mainly because of device tree concerns.
> >
> > The main reason is that the device tree bindings will be different if
> > you add an MFD core later, the GPIO and pinctrl driver will
> > move to a child node, making old device trees incompatible.
> >
> > We could have a single driver in GPIO+pin control if it is a child
> > of an MFD node in the device tree, but it doesn't make much
> > sense as the I2C device need to be probing to the MFD core.
> >
>
> I agree with you Linus, and that's why all STMFX chip initialization
> stuff was decorrelated in pinctrl-stmfx. This shows that this stuff
> needs to be in an MFD core.
>
> But as there is only one child for now (due to the reasons mentioned
> earlier), it can suggest that it is not a Multi-Function Device.
>
> I'm not able to target when IDD or TS functions will be required on a
> Linux product, but it still makes sense to consider that these functions
> will be used on a Linux product.
>
> So, I think MFD core + GPIO/pinctrl driver is the right modeling, but I
> wanted to be sure that this is okay for everyone. I don't want to spend
> time on something that will not be accepted due to its modeling.
It's fine. Go ahead.
Thanks for seeing this through to a reasonable conclusion.
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Alexandre Torgue @ 2018-05-29 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529155257.5ae48830@canb.auug.org.au>
Hi Stephen
On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the irqchip tree got a conflict in:
>
> arch/arm/boot/dts/stm32mp157c.dtsi
>
> between commit:
>
> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
>
> from the arm-soc tree and commit:
>
> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
>
> from the irqchip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Thanks for the fix (I will reorder nodes in a future patch). My opinion
is that all STM32 DT patches should come through my STM32 tree. It is my
role to fix this kind of conflicts. I thought it was a common rule
(driver patches go to sub-system maintainer tree and DT to the Machine
maintainer). For incoming next-series which contain DT+driver patches I
will indicate clearly that I take DT patch. I'm right ?
Regards
Alex
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Marc Zyngier @ 2018-05-29 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bedc0b7-21f9-1e15-a11c-3de06e81b5ba@st.com>
On 29/05/18 08:41, Alexandre Torgue wrote:
> Hi Stephen
>
> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the irqchip tree got a conflict in:
>>
>> arch/arm/boot/dts/stm32mp157c.dtsi
>>
>> between commit:
>>
>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
>>
>> from the arm-soc tree and commit:
>>
>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
>>
>> from the irqchip tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>
> Thanks for the fix (I will reorder nodes in a future patch). My opinion
> is that all STM32 DT patches should come through my STM32 tree. It is my
> role to fix this kind of conflicts. I thought it was a common rule
> (driver patches go to sub-system maintainer tree and DT to the Machine
> maintainer). For incoming next-series which contain DT+driver patches I
> will indicate clearly that I take DT patch. I'm right ?
Happy to oblige. Can you make sure you sync up with Ludovic and define
what you want to do?
In the meantime, I'm dropping the series altogether.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-29 8:02 UTC (permalink / raw)
To: linux-arm-kernel
Correct MIPI/PCIe/USB_HSIC's PGC offset based on
design RTL, the value on Reference Manual are incorrect.
The correct offset should be as below:
0x800 ~ 0x83F: PGC for core0 of A7 platform;
0x840 ~ 0x87F: PGC for core1 of A7 platform;
0x880 ~ 0x8BF: PGC for SCU of A7 platform;
0xA00 ~ 0xA3F: PGC for fastmix/megamix;
0xC00 ~ 0xC3F: PGC for MIPI PHY;
0xC40 ~ 0xC7F: PGC for PCIe_PHY;
0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/soc/imx/gpcv2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index afc7ecc..132c946 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -40,9 +40,9 @@
#define GPC_M4_PU_PDN_FLG 0x1bc
-#define PGC_MIPI 4
-#define PGC_PCIE 5
-#define PGC_USB_HSIC 8
+#define PGC_MIPI 16
+#define PGC_PCIE 17
+#define PGC_USB_HSIC 20
#define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
#define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
From: Kuninori Morimoto @ 2018-05-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWPFOjT9qk0Z4+-nSTumjhN_Q6Ntwh3__CgBCobquX8Rg@mail.gmail.com>
Hi Geert
> > HDMI sound doesn't use hdmi0_con.
> > You can do it now, thanks
>
> Thanks, so hdmi0_con can be moved now.
>
> But HDMI sound does use hdmi0/ports/port at 2. right?
Yes
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Alexandre Torgue @ 2018-05-29 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c306fbd9-21d9-5345-e820-52bc23d1b7c7@arm.com>
Hi Marc
On 05/29/2018 09:47 AM, Marc Zyngier wrote:
> On 29/05/18 08:41, Alexandre Torgue wrote:
>> Hi Stephen
>>
>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>
>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>
>>> between commit:
>>>
>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
>>>
>>> from the arm-soc tree and commit:
>>>
>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
>>>
>>> from the irqchip tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary. This
>>> is now fixed as far as linux-next is concerned, but any non trivial
>>> conflicts should be mentioned to your upstream maintainer when your tree
>>> is submitted for merging. You may also want to consider cooperating
>>> with the maintainer of the conflicting tree to minimise any particularly
>>> complex conflicts.
>>>
>>
>> Thanks for the fix (I will reorder nodes in a future patch). My opinion
>> is that all STM32 DT patches should come through my STM32 tree. It is my
>> role to fix this kind of conflicts. I thought it was a common rule
>> (driver patches go to sub-system maintainer tree and DT to the Machine
>> maintainer). For incoming next-series which contain DT+driver patches I
>> will indicate clearly that I take DT patch. I'm right ?
> Happy to oblige. Can you make sure you sync up with Ludovic and define
> what you want to do?
Sorry I don't understand your reply. I just say that for series
containing DT patches + drivers patches, to my point of view it is more
safe that driver patches are taken by sub-system maintainer (you in this
case) and that I take DT patches in my tree.
>
> In the meantime, I'm dropping the series altogether.
>
Why? We could keep it as Stephen fixed the merge issue.
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2 0/6] Driver for at91 usart in spi mode
From: Lee Jones @ 2018-05-29 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504154714.5109-1-radu.pirea@microchip.com>
On Fri, 04 May 2018, Radu Pirea wrote:
> Hello,
>
> This is the second version of driver. I added a mfd driver which by
> default probes atmel_serial driver and if in dt is specified to probe
> the spi driver, then the spi-at91-usart driver will be probed. The
> compatible for atmel_serial is now the compatible for at91-usart mfd
> driver and compatilbe for atmel_serial driver was changed in order to
> keep the bindings for serial as they are.
>
> Changes in v1:
> - added spi-at91-usart driver
>
> Changes in v2:
> - added at91-usart mfd driver
> - modified spi-at91-usart driver to work as mfd driver child
> - modified atmel_serial driver to work as mfd driver child
>
> Radu Pirea (6):
> MAINTAINERS: add at91 usart mfd driver
> mfd: at91-usart: added mfd driver for usart
> MAINTAINERS: add at91 usart spi driver
> dt-bindings: add binding for at91-usart in spi mode
> spi: at91-usart: add driver for at91-usart as spi
> tty/serial: atmel: changed the driver to work under at91-usart mfd
>
> .../bindings/spi/microchip,at91-usart-spi.txt | 28 +
> MAINTAINERS | 14 +
> drivers/mfd/Kconfig | 10 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/at91-usart.c | 81 +++
> drivers/spi/Kconfig | 9 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-at91-usart.c | 545 ++++++++++++++++++
> drivers/tty/serial/Kconfig | 1 +
> drivers/tty/serial/atmel_serial.c | 29 +-
> include/dt-bindings/mfd/at91-usart.h | 17 +
> 11 files changed, 722 insertions(+), 14 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> create mode 100644 drivers/mfd/at91-usart.c
> create mode 100644 drivers/spi/spi-at91-usart.c
> create mode 100644 include/dt-bindings/mfd/at91-usart.h
Applied, thanks.
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 0/6] Driver for at91 usart in spi mode
From: Lee Jones @ 2018-05-29 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529083303.GF4790@dell>
On Tue, 29 May 2018, Lee Jones wrote:
> On Fri, 04 May 2018, Radu Pirea wrote:
>
> > Hello,
> >
> > This is the second version of driver. I added a mfd driver which by
> > default probes atmel_serial driver and if in dt is specified to probe
> > the spi driver, then the spi-at91-usart driver will be probed. The
> > compatible for atmel_serial is now the compatible for at91-usart mfd
> > driver and compatilbe for atmel_serial driver was changed in order to
> > keep the bindings for serial as they are.
> >
> > Changes in v1:
> > - added spi-at91-usart driver
> >
> > Changes in v2:
> > - added at91-usart mfd driver
> > - modified spi-at91-usart driver to work as mfd driver child
> > - modified atmel_serial driver to work as mfd driver child
> >
> > Radu Pirea (6):
> > MAINTAINERS: add at91 usart mfd driver
> > mfd: at91-usart: added mfd driver for usart
> > MAINTAINERS: add at91 usart spi driver
> > dt-bindings: add binding for at91-usart in spi mode
> > spi: at91-usart: add driver for at91-usart as spi
> > tty/serial: atmel: changed the driver to work under at91-usart mfd
> >
> > .../bindings/spi/microchip,at91-usart-spi.txt | 28 +
> > MAINTAINERS | 14 +
> > drivers/mfd/Kconfig | 10 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/at91-usart.c | 81 +++
> > drivers/spi/Kconfig | 9 +
> > drivers/spi/Makefile | 1 +
> > drivers/spi/spi-at91-usart.c | 545 ++++++++++++++++++
> > drivers/tty/serial/Kconfig | 1 +
> > drivers/tty/serial/atmel_serial.c | 29 +-
> > include/dt-bindings/mfd/at91-usart.h | 17 +
> > 11 files changed, 722 insertions(+), 14 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> > create mode 100644 drivers/mfd/at91-usart.c
> > create mode 100644 drivers/spi/spi-at91-usart.c
> > create mode 100644 include/dt-bindings/mfd/at91-usart.h
>
> Applied, thanks.
Whoops! Ignore this, wrong patch!
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Marc Zyngier @ 2018-05-29 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b01f3226-5bb8-071a-e825-73bec913ffa8@st.com>
On 29/05/18 09:16, Alexandre Torgue wrote:
> Hi Marc
>
> On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>> On 29/05/18 08:41, Alexandre Torgue wrote:
>>> Hi Stephen
>>>
>>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>>
>>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>>
>>>> between commit:
>>>>
>>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
>>>>
>>>> from the arm-soc tree and commit:
>>>>
>>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
>>>>
>>>> from the irqchip tree.
>>>>
>>>> I fixed it up (see below) and can carry the fix as necessary. This
>>>> is now fixed as far as linux-next is concerned, but any non trivial
>>>> conflicts should be mentioned to your upstream maintainer when your tree
>>>> is submitted for merging. You may also want to consider cooperating
>>>> with the maintainer of the conflicting tree to minimise any particularly
>>>> complex conflicts.
>>>>
>>>
>>> Thanks for the fix (I will reorder nodes in a future patch). My opinion
>>> is that all STM32 DT patches should come through my STM32 tree. It is my
>>> role to fix this kind of conflicts. I thought it was a common rule
>>> (driver patches go to sub-system maintainer tree and DT to the Machine
>>> maintainer). For incoming next-series which contain DT+driver patches I
>>> will indicate clearly that I take DT patch. I'm right ?
>> Happy to oblige. Can you make sure you sync up with Ludovic and define
>> what you want to do?
>
> Sorry I don't understand your reply. I just say that for series
> containing DT patches + drivers patches, to my point of view it is more
> safe that driver patches are taken by sub-system maintainer (you in this
> case) and that I take DT patches in my tree.
And I'm happy to let you deal with these patches. I'm just asking you
sync with Ludovic to split the series on whichever boundary you wish to
enforce.
>> In the meantime, I'm dropping the series altogether.
>>
> Why? We could keep it as Stephen fixed the merge issue.
Well, you seem to have a strong opinion about who deals with what. I'll
let Ludovic repost what you and him decide should go via the irqchip tree.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] PM / runtime: Drop usage count for suppliers at device link removal
From: Rafael J. Wysocki @ 2018-05-29 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gGLvKS6yDuBokJzm2gAhM=VMSaz5frvWq=eRPkAD-z6g@mail.gmail.com>
On Sunday, May 27, 2018 12:18:05 PM CEST Rafael J. Wysocki wrote:
> On Thu, May 24, 2018 at 10:33 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > In the case consumer device is runtime resumed, while the link to the
> > supplier is removed, the earlier call to pm_runtime_get_sync() made from
> > rpm_get_suppliers() does not get properly balanced with a corresponding
> > call to pm_runtime_put(). This leads to that suppliers remains to be
> > runtime resumed forever, while they don't need to.
> >
> > Let's fix the behaviour by calling rpm_put_suppliers() when dropping a
> > device link. Not that, since rpm_put_suppliers() checks the
> > link->rpm_active flag, we can correctly avoid to call pm_runtime_put() in
> > cases when we shouldn't.
> >
> > Reported-by: Todor Tomov <todor.tomov@linaro.org>
> > Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> >
> > Rafael, I am not sure if this is safe from locking point of view. The device
> > link write lock has been taken when pm_runtime_drop_link() is called, hence I
> > assume calling rpm_put_suppliers() should be fine!? If not, can you please
> > advise how to change?
>
> Holding the lock should be sufficient for the list to be stable, so
> AFAICS it is OK.
So the patch has been applied, thanks!
^ permalink raw reply
* [PATCH v2 4/5] clk: renesas: r8a7795: add ccree clock bindings
From: Geert Uytterhoeven @ 2018-05-29 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-5-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 4:19 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, queueing in clk-renesas-for-v4.19, with "bindings" dropped from the
one-line summary.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.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
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Alexandre Torgue @ 2018-05-29 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d647302-0be8-555b-8063-06b0d2d72772@arm.com>
On 05/29/2018 10:39 AM, Marc Zyngier wrote:
> On 29/05/18 09:16, Alexandre Torgue wrote:
>> Hi Marc
>>
>> On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>>> On 29/05/18 08:41, Alexandre Torgue wrote:
>>>> Hi Stephen
>>>>
>>>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>>>
>>>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>>>
>>>>> between commit:
>>>>>
>>>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
>>>>>
>>>>> from the arm-soc tree and commit:
>>>>>
>>>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
>>>>>
>>>>> from the irqchip tree.
>>>>>
>>>>> I fixed it up (see below) and can carry the fix as necessary. This
>>>>> is now fixed as far as linux-next is concerned, but any non trivial
>>>>> conflicts should be mentioned to your upstream maintainer when your tree
>>>>> is submitted for merging. You may also want to consider cooperating
>>>>> with the maintainer of the conflicting tree to minimise any particularly
>>>>> complex conflicts.
>>>>>
>>>>
>>>> Thanks for the fix (I will reorder nodes in a future patch). My opinion
>>>> is that all STM32 DT patches should come through my STM32 tree. It is my
>>>> role to fix this kind of conflicts. I thought it was a common rule
>>>> (driver patches go to sub-system maintainer tree and DT to the Machine
>>>> maintainer). For incoming next-series which contain DT+driver patches I
>>>> will indicate clearly that I take DT patch. I'm right ?
>>> Happy to oblige. Can you make sure you sync up with Ludovic and define
>>> what you want to do?
>>
>> Sorry I don't understand your reply. I just say that for series
>> containing DT patches + drivers patches, to my point of view it is more
>> safe that driver patches are taken by sub-system maintainer (you in this
>> case) and that I take DT patches in my tree.
> And I'm happy to let you deal with these patches. I'm just asking you
> sync with Ludovic to split the series on whichever boundary you wish to
> enforce.
ok
>
>>> In the meantime, I'm dropping the series altogether.
>>>
>> Why? We could keep it as Stephen fixed the merge issue.
> Well, you seem to have a strong opinion about who deals with what. I'll
> let Ludovic repost what you and him decide should go via the irqchip tree.
It's not a "strong" opinion just my point of view and maybe not the good
one. I thought that's the way of working was like I explained. If you
prefer 2 series (one for driver patches and another one for DT patches)
I will be happy with that.
Ludovic, what is your opinion ?
Regards
Alexandre
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: r8a77965: Add Watchdog Timer controller node using RCLK Watchdog Timer
From: Simon Horman @ 2018-05-29 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527577262-8754-1-git-send-email-ykaneko0929@gmail.com>
On Tue, May 29, 2018 at 04:01:02PM +0900, Yoshihiro Kaneko wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> Add a device node for the Watchdog Timer (WDT) controller on the Renesas
> R-Car M3-N (R8A77965) SoC.
>
> Based on a similar patch of the R8A7796 device tree
> by Geert Uytterhoeven <geert+renesas@glider.be>.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH] PM / runtime: Fixup reference counting of device link suppliers at probe
From: Rafael J. Wysocki @ 2018-05-29 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFphMCQ_S5aBVToGUL=Rvd0cBQ4O3Top3AYPdM79Ak_LzA@mail.gmail.com>
On Friday, May 18, 2018 11:07:02 AM CEST Ulf Hansson wrote:
> On 18 May 2018 at 10:58, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Fri, May 18, 2018 at 10:48 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> In the driver core, before it invokes really_probe() it runtime resumes the
> >> suppliers for the device via calling pm_runtime_get_suppliers(), which also
> >> increases the runtime PM usage count for each of the available supplier.
> >>
> >> This makes sense, as to be able to allow the consumer device to be probed
> >> by its driver. However, if the driver decides to add a new supplier link
> >> during ->probe(), hence updating the list of suppliers,
> >
> > Do any of the existing drivers do that?
>
> Yes.
>
> At least these, but possibly even more...
>
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> drivers/gpu/drm/tegra/dc.c
> drivers/gpu/ipu-v3/ipu-prg.c
> drivers/pci/dwc/pci-dra7xx.c
>
> >
> >> the following call to pm_runtime_put_suppliers(), invoked after really_probe()
> >> in the driver core, we get into trouble.
Patch applied, thanks!
^ 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