* [GIT PULL] ARM: mvebu: arm for v4.18 (#1)
From: Olof Johansson @ 2018-05-25 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87603m1lq9.fsf@bootlin.com>
On Thu, May 17, 2018 at 02:59:42PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for arm for mvebu for v4.18.
>
> As I feared, there were (trivial) merge issues due to the defconfig
> update in linux-next. The best place to solve them is in your tree, so
> as soon as you will pull this, I will remove from my mvebu/for-next
> branch.
Hmm. Yeah, this is because you took upon yourself to run 'make savedefconfig'
for all platforms on this shared defconfig. This will of course conflict with
everything everywhere, and it doesn't seem like a good idea to do this way.
What you're really doing here is turning on one single option? Just do that.
We can run savedefconfig at the end of a merge window here instead of having
one of the platform maintainers do it.
So, feel free to send just the NAND patch, and I can fix it up when I apply it
if needed.
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/3] DaVinci SoC updates for v4.18
From: Olof Johansson @ 2018-05-25 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:43PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/soc
>
> for you to fetch changes up to ccfadbb759bed3cc40336e2c486e619e3bf8590b:
>
> Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc (2018-05-02 15:04:15 +0530)
>
> ----------------------------------------------------------------
> DaVinci SoC support updates for v4.18
>
> Mainly contains patches to move NAND chipselect to platform data
> (currently platform device id is being used). These patches have
> been acked by NAND maintainer and because of the driver dependency
> an immutable branch has been provided to Boris.
>
> The other patch is to remove an unnecessary postcore_initcall() on
> DM644x which is needed for common clock framework conversion.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 2/3] DaVinci device-tree updates for v4.18
From: Olof Johansson @ 2018-05-25 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-2-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:44PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/dt
>
> for you to fetch changes up to fe9d2a40d995dc1da042a4fcd7813239d063554d:
>
> ARM: dts: da850-evm: add WP and CD to MMC (2018-05-16 16:36:51 +0530)
>
> ----------------------------------------------------------------
> DaVinci device-tree updates for v4.18
>
> * DA850 EVM gains USB support, SD card write-protect, card detect
> and some clean-up
> * Support for gpio-ranges makes using gpios from DT much easier
> * Lego EV3 clean-up
>
> ----------------------------------------------------------------
> Adam Ford (3):
> ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1
> ARM: dts: da850-evm: use phandles to extend nodes
> ARM: dts: da850-evm: add WP and CD to MMC
>
> David Lechner (2):
> ARM: dts: da850: use gpio-ranges
> ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 3/3] DaVinci defconfig updates for v4.18
From: Olof Johansson @ 2018-05-25 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-3-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:45PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/defconfig
>
> for you to fetch changes up to e081c754ad4b8665364fcfb07b8bec5289f23dd8:
>
> ARM: davinci_all_defconfig: enable support for remoteproc drivers (2018-04-23 20:24:23 +0530)
>
> ----------------------------------------------------------------
> Enable DA8XX remoteproc driver support in davinci_all_defconfig
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries
From: Linus Walleij @ 2018-05-25 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25d1c303-71d7-8c38-880f-7bb0e133a876@suse.de>
On Fri, May 25, 2018 at 6:12 AM, Andreas F?rber <afaerber@suse.de> wrote:
> I fail to understand how splitting the MAINTAINERS section is going to
> help with the pinctrl conflict at hand?
OK let's keep it like it is then, one entry.
>The problem is that instead of
> refactoring my S500 pinctrl driver to his liking, Mani has submitted a
> competing S900 pinctrl driver that you went on to merge. The human
> aspect is that merging his driver took the credit away from me having
> written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
> The practical aspect is that I can't drop my pinctrl driver from my work
> branch until there is equivalent functionality in the merged driver. I
> am lacking the time to rewrite S500 pin definitions on top of Mani's
> myself at this time, and I haven't seen S500 patches from him yet.
I am sorry if you feel you are being treated unfairly.
I can't help to think about the old IT project motto "always
calculate to throw one version away". We are always going to
have a bit of collateral damage around out sometimes chaotic
and unstructured development process.
I haven't seen this S500 patch posted anywhere on the pin control
official mailing list. As subsystem maintainer I have a vast flow of
information already, actively polling around other subcommunities
is simply not possible for me.
I need to deal with what ends up on the list, I think it would have
been better if you simply posted your S500 driver at the time,
no matter the state. "Release early, release often" and discuss
design on the GPIO mailing list where I can see it, so I have some
idea what is going on here.
> Also I had been investing efforts in explaining the upstreaming process
> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
> CC and I have not seen any Reviewed-by or Acked-by from anyone at
> Actions on this and the preceding series. There are more chips than the
> one on Linaro's 96board, so I would prefer to assure that the design
> works for all. Thus I am very critical of you applying the patches
> without waiting for review by Actions.
It is not too late to take it out if there is some problem from their
side.
When I merge a driver it doesn't mean "definately approved, will
send to Torvalds", type of "seal of approval" it rather usually it
means "I want to test it in linux-next in due time for the merge
window".
I don't mind taking it out if there are problems, and I do not mind
even reverting it in the -rc phase if there are problems.
I don't mind having to revert patches like this or even rebasing
the tree if required.
However if they do not come back at all within some week or
two that is passivity and then it goes in.
> Other aspects are: The reason I wrote the pinctrl driver is that I
> experienced a UART TX issue on the Sparky board and was hoping a pinctrl
> driver might resolve that, but it didn't. So I still have a mix of
> boards where some are working and some are pretty unusable, without any
> clues on why.
Hm how typical :/
Getting to serial is paramount to getting anywhere with the
hacking. I see this becomes a bit of showstopper for your
development work here.
> That said, I don't object to having a separate MAINTAINERS section for
> the pinctrl driver(s) as long as I still get CC'ed on changes. We have
> wanted to add Mani as R for Actions overall, so that would probably mean
> adding me as R to an Actions pinctrl section, to avoid syncing the paths
> between two sections.
No problem we keep it to one entry.
> I had previously felt that it does not make sense
> to list Mani as co-maintainer (M) for Actions overall since he can't tag
> and submit from my repo. And for the record I have offered him to take
> over which he didn't want to. I still hope to find some more time to
> review and queue his SPS patches, a driver that I have designed and thus
> understand and am much happier about the incremental additions there.
OK nice!
> A further side note is that I had reached out about setting up an
> infradead mailing list linux-actions, but there was no response from
> David or anyone. Having an L on the section(s) would avoid messing with
> R and hand-maintained CC lists. Any help with that appreciated.
We can talk to kernel.org about setting up a list, that probably works
quicker.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL v2] arm64: defconfig: hisilicon config updates for v4.18
From: Olof Johansson @ 2018-05-25 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AFEB1E0.9030200@hisilicon.com>
On Fri, May 18, 2018 at 11:58:40AM +0100, Wei Xu wrote:
> Hi Olof, Hi Arnd,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-defconfig-for-4.18v2
>
> for you to fetch changes up to 9ab1c973324566baa314f8dd4e3827e4076a8675:
>
> arm64: defconfig: Enable HISILICON_LPC (2018-05-11 11:39:01 +0100)
>
> ----------------------------------------------------------------
> ARM64: hisilicon: defconfig updates for 4.18
>
> - Sync the arm64 defconfig with savedefconfig
> - Enable the support of ethernet, eMMC, Combo/INNO phy
> and PCIe for Hi3798CV200
> - Enable the LPC for hip06 and hip07
>
> ----------------------------------------------------------------
> John Garry (1):
> arm64: defconfig: Enable HISILICON_LPC
>
> Shawn Guo (2):
> arm64: defconfig: sync it with savedefconfig
Same feedback here as for Gregory on his Marvell pull request -- please don't
run savedefconfig since it messes up and adds a lot of conflicts for everybody.
We'll do it in our tree right around the end of the merge window instead.
It's probably easiest to send the patches as patches so we can fix them up if
needed, so please resend separately and we'll apply. (Or send a new pull
request with just the two new config changes).
Thanks!
-Olof
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Josh Boyer @ 2018-05-25 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527246209-26685-2-git-send-email-vgarodia@codeaurora.org>
On Fri, May 25, 2018 at 7:03 AM Vikash Garodia <vgarodia@codeaurora.org>
wrote:
> This pull request adds firmware files for Venus h/w codec found on the
Qualcomm SDM845 chipset.
> The following changes since commit
2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> Merge branch 'for-upstreaming-v1.7.2' of
https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
> are available in the git repository at:
> https://github.com/vgarodia/linux-firmware master
> for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
> qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
> ----------------------------------------------------------------
> Vikash Garodia (1):
> qcom: add venus firmware files for v5.2
> WHENCE | 9 +++++++++
> qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
> qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
> qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
> qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
> qcom/venus-5.2/venus.b04 | 1 +
> qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
> qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
> 8 files changed, 10 insertions(+)
> create mode 100644 qcom/venus-5.2/venus.b00
> create mode 100644 qcom/venus-5.2/venus.b01
> create mode 100644 qcom/venus-5.2/venus.b02
> create mode 100644 qcom/venus-5.2/venus.b03
> create mode 100644 qcom/venus-5.2/venus.b04
> create mode 100644 qcom/venus-5.2/venus.mbn
> create mode 100644 qcom/venus-5.2/venus.mdt
The venus.mbn file isn't mentioned in WHENCE:
[jwboyer at vader linux-firmware]$ ./check_whence.py
E: qcom/venus-5.2/venus.mbn not listed in WHENCE
[jwboyer at vader linux-firmware]$
Can you fix that up and let me know when to re-pull?
josh
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.18
From: Olof Johansson @ 2018-05-25 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526548323.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:14:48PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC defconfig updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-defconfig-for-v4.18
>
> for you to fetch changes up to c1fcd2ec1b1970e0e7b0c40c64bc51cf667b1a75:
>
> arm64: defconfig: enable R8A77990 SoC (2018-05-16 11:08:20 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 Based SoC Defconfig Updates for v4.18
>
> * Enable in ARM64 defconfig:
> - Recently mainlined support for R-Car E3 (r8a77990) SoC
>
> - HDMI sound and depdencies.
>
> HDMI sound is used by R-Car Gen 3. These options are enabled as
> modules to avoid unnecesesarily enlarging the kernel image.
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL 1/5] dt-bindings: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-1-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:41PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-dt-bindings
>
> for you to fetch changes up to eb8f53b6d3125894e3d825976eb7e03150496362:
>
> dt-bindings: Relocate Tegra20 memory controller bindings (2018-04-27 11:15:51 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: tegra: Changes for v4.18-rc1
>
> This contains the device tree bindings updates for the memory controller
> hot resets that are implemented by driver patches in a different branch.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (3):
> dt-bindings: arm: tegra: Remove duplicated Tegra30+ MC binding
> dt-bindings: memory: tegra: Document #reset-cells property of the Tegra30 MC
> dt-bindings: arm: tegra: Document #reset-cells property of the Tegra20 MC
>
> Thierry Reding (1):
> dt-bindings: Relocate Tegra20 memory controller bindings
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/5] memory: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-2-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:42PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory
>
> for you to fetch changes up to bef89a8d81ca97aca864778746b110cf52847868:
>
> memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 12:33:02 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.18-rc1
>
> This contains some cleanup of the memory controller driver as well as
> unification work to share more code between Tegra20 and later SoC
> generations. Also included are an implementation for the hot resets
> functionality by the memory controller which is required to properly
> reset busy hardware.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (14):
> dt-bindings: memory: tegra: Add hot resets definitions
> memory: tegra: Do not handle spurious interrupts
> memory: tegra: Setup interrupts mask before requesting IRQ
> memory: tegra: Apply interrupts mask per SoC
> memory: tegra: Remove unused headers inclusions
> memory: tegra: Squash tegra20-mc into common tegra-mc driver
> memory: tegra: Introduce memory client hot reset
> memory: tegra: Add Tegra20 memory controller hot resets
> memory: tegra: Add Tegra30 memory controller hot resets
> memory: tegra: Add Tegra114 memory controller hot resets
> memory: tegra: Add Tegra124 memory controller hot resets
> memory: tegra: Register SMMU after MC driver became ready
> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
> memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>
> Thierry Reding (1):
> memory: tegra: Add Tegra210 memory controller hot resets
Looks like this is just additional/proper resets, are there any backwards
compatibility concerns with older device trees or new assumptions of properties
that should be handled?
-Olof
^ permalink raw reply
* [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries
From: Linus Walleij @ 2018-05-25 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525050103.3hg3u2v5mvftqhht@linaro.org>
On Fri, May 25, 2018 at 7:01 AM, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
> FYI, I have ordered S700 based Cubieboard and will work on adding support for
> that first. I still don't have access to S500 board yet since it is not
> available on my region. Will find a way to get this asap.
Awesome, then we can count on some actions action here.
>> Also I had been investing efforts in explaining the upstreaming process
>> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
>> CC and I have not seen any Reviewed-by or Acked-by from anyone at
>> Actions on this and the preceding series. There are more chips than the
>> one on Linaro's 96board, so I would prefer to assure that the design
>> works for all. Thus I am very critical of you applying the patches
>> without waiting for review by Actions.
>
> I don't think Actions would be interested in any upstreaming efforts. It
> is our (comunity) responsibility to add support for that in order to
> have our boards running mainline kernel and that's what we both have been
> doing. Moreover I only saw once David Liau responded to your patchset and
> there isn't much further. So how can you expect the subsystem maintainer's
> to hold the patch series waiting for a so far silent SoC manufacturer's
> response?
They are certainly informed now! :D
Actions semi folks, please familiarize yourself with the following:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt?h=devel
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/tree/drivers/pinctrl/actions?h=devel
If you have any concerns with this, now is a good time to share them.
> I
> did ask you to add me as Co-Maintainer but you didn't responded to that.
> I know that I can't send any pull requests to Arnd, but we should sort
> it out IMO. Also, if you are completely swamped, then I take take up the
> maintainership role now inorder to keep the things moving. TBH I don't
> want my patches to be floating for months without any reason.
Doing some comainatinership can very well include doing pull
requests as long as you agree on who does what.
I think it may be a bit late for the next merge window right now,
but if you simply queue up stuff in some git tree and ask
Srothwell to include it in linux-next then Andreas can very well
pull it to his tree from there and then to ARM SoC or you can
queue patches as well.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 2/5] memory: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518204351.GA26800@ulmo>
On Fri, May 18, 2018 at 10:43:51PM +0200, Thierry Reding wrote:
> On Fri, May 18, 2018 at 04:22:42PM +0200, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >
> > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory
> >
> > for you to fetch changes up to bef89a8d81ca97aca864778746b110cf52847868:
> >
> > memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 12:33:02 +0200)
> >
> > Thanks,
> > Thierry
> >
> > ----------------------------------------------------------------
> > memory: tegra: Changes for v4.18-rc1
> >
> > This contains some cleanup of the memory controller driver as well as
> > unification work to share more code between Tegra20 and later SoC
> > generations. Also included are an implementation for the hot resets
> > functionality by the memory controller which is required to properly
> > reset busy hardware.
> >
> > ----------------------------------------------------------------
> > Dmitry Osipenko (14):
> > dt-bindings: memory: tegra: Add hot resets definitions
> > memory: tegra: Do not handle spurious interrupts
> > memory: tegra: Setup interrupts mask before requesting IRQ
> > memory: tegra: Apply interrupts mask per SoC
> > memory: tegra: Remove unused headers inclusions
> > memory: tegra: Squash tegra20-mc into common tegra-mc driver
> > memory: tegra: Introduce memory client hot reset
> > memory: tegra: Add Tegra20 memory controller hot resets
> > memory: tegra: Add Tegra30 memory controller hot resets
> > memory: tegra: Add Tegra114 memory controller hot resets
> > memory: tegra: Add Tegra124 memory controller hot resets
> > memory: tegra: Register SMMU after MC driver became ready
> > dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
> > memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>
> Please don't pull this just yet. Dmitry just pointed out to me that the
> final two patches here break bisectibility. I'll reorder them and will
> send out a new pull request.
Please delete the tag when you withdraw a pull request, and do the next request
with a new tag name. That way I don't have to scan my mailbox to make sure all
pull requests are still valid when I go through it and won't accidentally merge
something that you have withdrawn.
-Olof
^ permalink raw reply
* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Heiko Stuebner @ 2018-05-25 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8495bffd-2a52-ca85-1bc9-afc3ea0af8e4@arm.com>
Hi Marc,
Am Freitag, 25. Mai 2018, 13:07:02 CEST schrieb Marc Zyngier:
> [Thanks Robin for pointing me to that patch.]
>
> Hi Heiko,
>
> On 24/05/18 23:06, Heiko St?bner wrote:
> > From: Sandy Huang <hjc@rock-chips.com>
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> > cases lead to a stall if the irq is triggered while the vop driver
> > still has it disabled.
> >
> > But there is no real need to disable the irq, as the vop can simply
> > also track its enabled state and ignore irqs in that case.
> >
> > So remove the enable/disable handling and add appropriate condition
> > to the irq handler.
> >
> > Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> > [added an actual commit message]
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > Hi Ezequiel,
> >
> > this patch came from a discussion I had with Rockchip people over the
> > iommu changes and resulting issues back in april, but somehow was
> > forgotten and not posted to the lists. Correcting that now.
> >
> > So removing the enable/disable voodoo on the shared interrupt is
> > the preferred way.
> >
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index 510cdf0..61493d4 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
> >
> > spin_unlock(&vop->reg_lock);
> >
> > - enable_irq(vop->irq);
> > -
> > drm_crtc_vblank_on(crtc);
> >
> > return 0;
> > @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
> >
> > vop_dsp_hold_valid_irq_disable(vop);
> >
> > - disable_irq(vop->irq);
> > -
> > vop->is_enabled = false;
> >
> > /*
> > @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
> > int ret = IRQ_NONE;
> >
> > /*
> > + * since the irq is shared with iommu, iommu irq is enabled before vop
> > + * enable, so before vop enable we do nothing.
> > + */
> > + if (!vop->is_enabled)
> > + return IRQ_NONE;
> > +
>
> What guarantee do we have that the IOMMU will actually service that
> interrupt? Can't we get into a situation where the interrupt gets
> ignored by both drivers and subsequently disabled by the core irq code
> as being spurious?
>
> From what I understood of the way things are plugged together on the
> rockchip platforms, each individual VOP is behind a single IOMMU, hence
> there there is hardly any point in handling IOMMU interrupts if the VOP
> is off.
Yeah, which is probably the reason that patch fell through the cracks
initially. I resurrected it from the internal discussion because of the issue
described below.
> But I'm missing the actual reason behind this patch. Could you enlighten me?
Recently the iommu driver moved the irq request from the iommu enablement
to its probe function. With that change Ezequiel got various stalls, see
https://lkml.org/lkml/2018/5/24/1347
Heiko
^ permalink raw reply
* [GIT PULL v2 2/5] memory: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518215837.29076-1-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 11:58:37PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory-v2
>
> for you to fetch changes up to a1be3cfdfb81cc55c1b2feb73aca6945f61acddb:
>
> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 22:45:01 +0200)
>
> This contains the same patches as the previous pull request with the exception
> that the final two are reordered to keep the set bisectible.
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.18-rc1
>
> This contains some cleanup of the memory controller driver as well as
> unification work to share more code between Tegra20 and later SoC
> generations. Also included are an implementation for the hot resets
> functionality by the memory controller which is required to properly
> reset busy hardware.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (14):
> dt-bindings: memory: tegra: Add hot resets definitions
> memory: tegra: Do not handle spurious interrupts
> memory: tegra: Setup interrupts mask before requesting IRQ
> memory: tegra: Apply interrupts mask per SoC
> memory: tegra: Remove unused headers inclusions
> memory: tegra: Squash tegra20-mc into common tegra-mc driver
> memory: tegra: Introduce memory client hot reset
> memory: tegra: Add Tegra20 memory controller hot resets
> memory: tegra: Add Tegra30 memory controller hot resets
> memory: tegra: Add Tegra114 memory controller hot resets
> memory: tegra: Add Tegra124 memory controller hot resets
> memory: tegra: Register SMMU after MC driver became ready
> memory: tegra: Remove Tegra114 SATA and AFI reset definitions
> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>
> Thierry Reding (1):
> memory: tegra: Add Tegra210 memory controller hot resets
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] ARM: tegra: Core changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-3-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:43PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-arm-soc
>
> for you to fetch changes up to 15164e0072b579f77c9025f3da3ed931869b89cd:
>
> ARM: tegra: Create platform device for tegra20-cpufreq driver (2018-05-18 11:15:42 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Core changes for v4.18-rc1
>
> Contains a single patch that instantiates a platform device for the CPU
> frequency driver.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/5] ARM: tegra: Device tree changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-4-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:44PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-arm-dt
>
> for you to fetch changes up to dc4ea601be724d7ad37c8c5b1059417126e97e27:
>
> ARM: dts: tegra114: Add IOMMU nodes to Host1x and its clients (2018-05-04 17:21:02 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.18-rc1
>
> Contains a fix for the high-speed UART on Toradex Apalis TK1 boards as
> well as IOMMU enablement for various devices on Tegra30 and Tegra30.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (2):
> ARM: dts: tegra30: Add IOMMU nodes to Host1x and its clients
> ARM: dts: tegra114: Add IOMMU nodes to Host1x and its clients
>
> Marcel Ziswiler (1):
> ARM: tegra: apalis-tk1: Fix high speed UART compatible
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 5/5] arm64: tegra: Device tree changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-5-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:45PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-arm64-dt
>
> for you to fetch changes up to 9df50ba76ac1485b844beffa1f3f5d9659d9cdaf:
>
> arm64: tegra: Make BCM89610 PHY interrupt as active low (2018-05-03 11:48:16 +0200)
>
> I already sent this out as a fix for v4.17, so if you decide to pick
> that up you can ignore this one. I've only included it here in case you
> had objections to take it into v4.17 at this point.
Ok, thanks -- merged the fix so not touching this.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: arm64 for v4.18 (#1)
From: Olof Johansson @ 2018-05-25 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874lj429kq.fsf@bootlin.com>
On Fri, May 18, 2018 at 06:49:09PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for arm64 for mvebu for v4.18.
>
> Gregory
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-arm64-4.18-1
>
> for you to fetch changes up to 3eb0a48af488b5e83d2986943a1b6905ca753571:
>
> arm64: defconfig: enable the Armada thermal driver (2018-05-16 20:08:31 +0200)
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v3 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Radu Pirea @ 2018-05-25 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d70c73e-9db7-bdff-7414-04a4843acae3@sorico.fr>
On 05/15/2018 04:14 PM, Richard Genoud wrote:
> On 15/05/2018 14:47, Radu Pirea wrote:
>> On Mon, 2018-05-14 at 12:57 +0200, Richard Genoud wrote:
>>> After your patch, the DMA is not selected anymore:
>>> atmel_usart_serial atmel_usart_serial.0.auto: TX channel not
>>> available, switch to pio
>>> instead of:
>>> atmel_usart fffff200.serial: using dma1chan2 for tx DMA transfers
>>>
>> Fixed.
>>> And the kernel doesn't log anymore on the serial console, despite the
>>> loglevel=8
>>> (after reverting this series, the kernel logs reappears on the serial
>>> console)
>>>
>> Which serial are you using as console?
> fffff200.serial (sam9g35-cm)
> ( stdout-path = "serial0:115200n8"; in the DTS )
>
> With this series applied, all the kernel log goes on the screen.
> Without, it goes on the serial debug.
>
I tested again with archlinux arm and poky-linux4sam release as distros
and kernel log goes on the serial debug. Can you give me more details
like cmdline?
>>> (tests done on sam9g35)
>>>
>> I will consider the rest of suggestions.
>>> regards,
>>> Richard
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.18 (#1)
From: Olof Johansson @ 2018-05-25 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8736yo29jb.fsf@bootlin.com>
On Fri, May 18, 2018 at 06:50:00PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt for mvebu for v4.18.
>
> Gregory
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.18-1
>
> for you to fetch changes up to 163043ab55210dbb92e36c1220a721f404df6834:
>
> ARM: dts: armada-xp-98dx: Add NAND pinctrl information (2018-05-18 18:36:57 +0200)
Definitely a pretty noisy pull request, but it's a good move from the format
that requires mimicing the tree structure and using phandles instead.
Merged!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.18 (#1)
From: Olof Johansson @ 2018-05-25 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871se829iq.fsf@bootlin.com>
On Fri, May 18, 2018 at 06:50:21PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for dt64 for mvebu for v4.18.
>
> Gregory
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.18-1
>
> for you to fetch changes up to bd473ecda24c6214868d58500c4d7569f6597946:
>
> arm64: dts: marvell: armada-37xx: mark the gpio controllers as irq controller (2018-05-18 18:35:16 +0200)
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Robin Murphy @ 2018-05-25 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJK69A3W=YrSfvPetM95CROOJhU1bW1rMEOGtji=t0ORQ@mail.gmail.com>
On 24/05/18 21:57, Rob Herring wrote:
> On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
>>> Deferred probe will currently wait forever on dependent devices to probe,
>>> but sometimes a driver will never exist. It's also not always critical for
>>> a driver to exist. Platforms can rely on default configuration from the
>>> bootloader or reset defaults for things such as pinctrl and power domains.
>>> This is often the case with initial platform support until various drivers
>>> get enabled. There's at least 2 scenarios where deferred probe can render
>>> a platform broken. Both involve using a DT which has more devices and
>>> dependencies than the kernel supports. The 1st case is a driver may be
>>> disabled in the kernel config. The 2nd case is the kernel version may
>>> simply not have the dependent driver. This can happen if using a newer DT
>>> (provided by firmware perhaps) with a stable kernel version.
>>>
>>> Subsystems or drivers may opt-in to this behavior by calling
>>> driver_deferred_probe_check_init_done() instead of just returning
>>> -EPROBE_DEFER. They may use additional information from DT or kernel's
>>> config to decide whether to continue to defer probe or not.
>>>
>>> Cc: Alexander Graf <agraf@suse.de>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> ---
>>> drivers/base/dd.c | 17 +++++++++++++++++
>>> include/linux/device.h | 2 ++
>>> 2 files changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>>> index c9f54089429b..d6034718da6f 100644
>>> --- a/drivers/base/dd.c
>>> +++ b/drivers/base/dd.c
>>> @@ -226,6 +226,16 @@ void device_unblock_probing(void)
>>> driver_deferred_probe_trigger();
>>> }
>>>
>>> +int driver_deferred_probe_check_init_done(struct device *dev, bool optional)
>>> +{
>>> + if (optional && initcalls_done) {
>>
>> Wait, what's the "optional" mess here?
>
> My intent was that subsystems just always call this function and never
> return EPROBE_DEFER themselves. Then the driver core can make
> decisions as to what to do (such as the timeout added in the next
> patch). Or it can print common error/debug messages. So optional is a
> hint to allow subsystems per device control.
Maybe just driver_defer_probe() might be a more descriptive name? To me,
calling "foo_check_x()" with a parameter that says "I don't actually
care about x" is the really unintuitive bit.
>>
>> The caller knows this value, so why do you need to even pass it in here?
>
> Because regardless of the value, we always stop deferring when/if we
> hit the timeout and the caller doesn't know about the timeout. If we
> get rid of it, we'd need functions for both init done and for deferred
> timeout.
>
>> And bool values that are not obvious are horrid. I had to go look this
>> up when reading the later patches that just passed "true" in this
>> variable as I had no idea what that meant.
>
> Perhaps inverting it and calling it "keep_deferring" would be better.
> However, the flag is ignored if we have timed out.
Perhaps an enum (or bitmask of named flags) then? That would allow the
most readability at callsites, plus it seems quite likely that we may
want intermediate degrees of "deferral strictness" eventually.
Robin.
>>
>> So as-is, no, this isn't ok, sorry.
>>
>> And at the least, this needs some kerneldoc to explain it :)
>
> That part is easy enough to fix.
>
> Rob
>
^ permalink raw reply
* [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.18
From: Olof Johansson @ 2018-05-25 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATphrRyYvMXMMJz--UtfNk2BZLWHAp3XXpQLob5=5w2Qg@mail.gmail.com>
On Sun, May 20, 2018 at 11:34:08AM +0900, Masahiro Yamada wrote:
> Hi Arnd, Olof,
>
> Here are UniPhier DT (32bit) updates for the v4.18 merge window.
> Please pull!
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
> tags/uniphier-dt-v4.18
>
> for you to fetch changes up to 526f872b8492fbfb1a0f342e601bdc5ba322f16b:
>
> ARM: dts: uniphier: add syscon-phy-mode property to each ethernet
> node (2018-04-25 00:21:51 +0900)
>
> ----------------------------------------------------------------
> UniPhier ARM SoC DT updates for v4.18
>
> - add more properties to ethernet nodes
>
> ----------------------------------------------------------------
> Kunihiko Hayashi (2):
> ARM: dts: uniphier: add required clocks and resets to Pro4 ethernet node
> ARM: dts: uniphier: add syscon-phy-mode property to each ethernet node
Hi,
Merged, but please spend a little more effort on the tag description (what are
these new properties giving you in functionality?)
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: uniphier: UniPhier DT updates for v4.18
From: Olof Johansson @ 2018-05-25 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASUq_9osPdzbiMCbYzeqc=W3Yv7tB63V+5gXqcZ9QBtYA@mail.gmail.com>
On Sun, May 20, 2018 at 11:38:39AM +0900, Masahiro Yamada wrote:
> Hi Arnd, Olof,
>
> Here are UniPhier DT (64bit) updates for the v4.18 merge window.
> Please pull!
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
> tags/uniphier-dt64-v4.18
>
> for you to fetch changes up to b076ff8bddfba793d49bca14feb49a0e84f41843:
>
> arm64: dts: uniphier: add syscon-phy-mode property to each ethernet
> node (2018-04-25 00:21:14 +0900)
>
> ----------------------------------------------------------------
> UniPhier ARM64 SoC DT updates for v4.18
>
> - add more properties to ethernet nodes
>
> ----------------------------------------------------------------
> Kunihiko Hayashi (2):
> arm64: dts: uniphier: add clock-names and reset-names to ethernet node
> arm64: dts: uniphier: add syscon-phy-mode property to each ethernet node
Merged, same comment as for the 32-bit pull request. Thanks!
-Olof
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Ulf Hansson @ 2018-05-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3a94d63-678c-eab6-47a8-43eca95da979@nvidia.com>
On 25 May 2018 at 13:07, Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 25/05/18 11:45, Ulf Hansson wrote:
>
> ...
>
>>> Right, but this case still seems like an error. My understanding is that
>>> only drivers will use this API directly and it will not be used by the
>>> device driver core (unlike dev_pm_domain_attach), so if anyone calls this
>>> attempting to attach another PM domain when one is already attached, they
>>> are doing something wrong.
>>
>>
>> [...]
>>
>> You may be right!
>>
>> What I was thinking of is whether multiple PM domains may be optional
>> in some cases, but instead a PM domain have already been attached by
>> dev_pm_domain_attach(), prior the driver starts to probe.
>>
>> Then, assuming we return an error for this case, that means the caller
>> then need to check the dev->pm_domain pointer, prior calling
>> dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear
>> though?
>
>
> IMO the driver should know whether is needs multiple power-domains or not
> and if it needs multiple then it should just call
> dev_pm_domain_attach_by_id() N times without needing to checking
> dev->pm_domain first. If it fails then either the PM domain core did
> something wrong or power-domains are missing from DT, but either way there
> is an error, so let it fail.
Right, sounds reasonable!
Kind regards
Uffe
^ 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