* [PATCH v2 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang at mediatek.com @ 2017-12-21 2:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
Two fixups for mediatek's host bridge:
The first patch fixup the IRQ handle routine to avoid IRQ reentry which
may exist for both MT2712 and MT7622.
The second patch fixup class type for MT7622.
Change Since v1:
- Add the second patch.
- Make the first patch's commit message more standard.
Honghui Zhang (2):
PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
PCI: mediatek: Fixup class type for MT7622
drivers/pci/host/pcie-mediatek.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--
2.6.4
^ permalink raw reply
* [GIT PULL] arm64: Updates of aarch64 DTS files for v4.15-next
From: Sean Wang @ 2017-12-21 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f497c32-0947-8185-d794-50f3ba539e96@gmail.com>
Hi, Matthias
title and content seems not consistent, and the other git pull for armv7
does too.
Sean
On Wed, 2017-12-20 at 20:19 +0100, Matthias Brugger wrote:
> Hi Olof, hi Arnd,
>
> Please take the patches below into consideration.
>
> Thanks a lot,
> Matthias
>
> ---
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git
> tags/v4.15-next-dts32
>
> for you to fetch changes up to a227cf4dfd74a873857c9cc017100168d01539ed:
>
> dt-bindings: ARM: Mediatek: Fix ethsys documentation (2017-12-20 18:10:12 +0100)
>
> ----------------------------------------------------------------
> - add reset cells mt2701 and mt7623 ethsys
> - update mmc nodes for mt7623
> - mt7623 change mmc card detection pin to active low
> - mt7623 set unit address to lower case
>
> ----------------------------------------------------------------
> Mathieu Malaterre (1):
> arm: mt7: dts: Remove leading 0x and 0s from bindings notation
>
> Matthias Brugger (3):
> arm: dts: mt7623: Update ethsys binding
> arm: dts: mt2701: Add reset-cells
> dt-bindings: ARM: Mediatek: Fix ethsys documentation
>
> Sean Wang (2):
> arm: dts: mt7623: update mmc related nodes with the appropriate fallback
> arm: dts: mt7623: fix card detection issue on bananapi-r2
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> arch/arm/boot/dts/mt2701.dtsi | 2 ++
> arch/arm/boot/dts/mt7623.dtsi | 5 +++--
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
> arch/arm/boot/dts/mt7623n-rfb-nand.dts | 2 +-
> 5 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH v2 0/9] soc: brcmstb: biuctrl updates for 64-bit chips
From: Florian Fainelli @ 2017-12-21 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Le 12/19/17 ? 11:22, Florian Fainelli a ?crit?:
> Hi all,
>
> This patch series updates the Broadcom STB Bus Interface Unit controller to
> support newer chips such as 7260, 7268, 7271 and 7278. These chips require
> additional tuning in order to provide the expected bus throughput.
>
> In the process, we need to re-organize the common.c file a little bit in order
> to extract the family and product identifiers a little earlier.
>
> Finally, by moving the biuctrl initialization an early_initcall level, we can
> remove some code from the ARM-32bit machine descriptor file.
>
> Provided that we are happy with these changes, I would route them through my
> drivers/next branch and a subsequent Broadcom ARM SoC pull request.
>
> Thank you
>
> Changes in v2:
>
> - collect Rob's acked-by on the first patch
> - fixed the binding as suggested by Rob
>
> Florian Fainelli (9):
> dt-bindings: arm: Add entry for Broadcom Brahma-B53
> dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
> soc: brcmstb: Make CPU credit offset more parameterized
> soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
> soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
> soc: brcmstb: biuctrl: Wire-up new registers
> soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
> soc: brcmstb: Split initialization
> soc: brcmstb: biuctrl: Move to early_initcall
Series applied to drivers/next.
--
Florian
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Honghui Zhang @ 2017-12-21 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221005240.GC30595@bhelgaas-glaptop.roam.corp.google.com>
On Wed, 2017-12-20 at 18:52 -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
>
> Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
> make yours match. Same capitalization, same sentence structure, etc.,
> e.g.,
>
> PCI: mediatek: Clear IRQ status ...
>
> s/dispathed/dispatched/
>
> s/irq/IRQ/ in the summary and all the English text below.
Thanks for your review and sorry for the mismatch, I will fix that in
next version.
>
> On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zhang at mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > There maybe a same irq reentry scenario after irq received in current
> > irq handle flow:
> > EP device PCIe host driver EP driver
> > 1. issue an irq
> > 2. received irq
> > 3. clear irq status
> > 4. dispatch irq
> > 5. clear irq source
> > The irq status was not successfully cleared at step 2 since the irq
> > source was not cleared yet. So the PCIe host driver may receive the
> > same irq after step 5. Then there's an irq reentry occurred.
> > Even worse, if the reentry irq was not an irq that EP driver expected,
> > it may not handle the irq. Then we may run into the dead loop from
>
> By "dead loop" I assume you mean "infinite loop"? I don't think it's
> a deadlock since nothing is waiting.
>
Yes, it should be "infinite loop", I will update the commit message in
next version.
thanks.
> > step 2 to step 4.
> > Clear the irq status after irq have been dispatched to avoid the irq
> > reentry.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index db93efd..3248771 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
> >
> > while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> > for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> > - /* Clear the INTx */
> > - writel(1 << bit, port->base + PCIE_INT_STATUS);
> > virq = irq_find_mapping(port->irq_domain,
> > bit - INTX_SHIFT);
> > generic_handle_irq(virq);
> > + /* Clear the INTx */
> > + writel(1 << bit, port->base + PCIE_INT_STATUS);
> > }
> > }
> >
> > @@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
> >
> > while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
> > for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
> > - /* Clear the MSI */
> > - writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> > virq = irq_find_mapping(port->msi_domain, bit);
> > generic_handle_irq(virq);
> > + /* Clear the MSI */
> > + writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> > }
> > }
> > /* Clear MSI interrupt status */
> > --
> > 2.6.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/2] bcm2835-drivers-next-2017-12-19
From: Florian Fainelli @ 2017-12-21 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220004257.16764-2-eric@anholt.net>
Le 12/19/17 ? 16:42, Eric Anholt a ?crit?:
> The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
>
> Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
>
> are available in the Git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-drivers-next-2017-12-19
>
> for you to fetch changes up to 9107ee6a50b81180f29a9f6588b21917dde2abdd:
>
> firmware: raspberrypi: print time using time64_t (2017-11-28 16:24:33 -0800)
>
> ----------------------------------------------------------------
> This pull request brings in a (cosmetic) y2038 fix for the Raspberry
> Pi firmware driver.
>
> ----------------------------------------------------------------
> Arnd Bergmann (1):
> firmware: raspberrypi: print time using time64_t
Merged, thanks Eric!
--
Florian
^ permalink raw reply
* [GIT PULL 1/2] bcm2835-dt-next-2017-12-19
From: Florian Fainelli @ 2017-12-21 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220004257.16764-1-eric@anholt.net>
Le 12/19/17 ? 16:42, Eric Anholt a ?crit?:
> Hi Florian,
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://github.com/anholt/linux tags/bcm2835-dt-next-2017-12-19
>
> for you to fetch changes up to 3edb73d87e9e824326f588b5d5c5661bf53449be:
>
> ARM: dts: bcm283x: Use GPIO polarity defines consistently (2017-12-08 13:10:09 -0800)
>
> ----------------------------------------------------------------
> This pull request cleans up the bcm2835 DT to use #defines for GPIO
> polarity.
>
> ----------------------------------------------------------------
> Stefan Wahren (1):
> ARM: dts: bcm283x: Use GPIO polarity defines consistently
Merged; thanks Eric!
--
Florian
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-21 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221003947.GJ7997@codeaurora.org>
On 12/20/17 6:39 PM, Stephen Boyd wrote:
> I don't see how it hurts to treat it generically. Presumably
> that's the way it will be done on ACPI platforms going forward?
> No need to tie it to some ACPI HID.
But it is tied to a HID. The "num-gpios" and "gpios" properties belong
to a specific HID. Someone could create a new HID with different
properties, and then what? That's why I want all the ACPI stuff in the
client driver.
At this point I don't really care any more about what the patches look
like, but I really do think that putting the ACPI code in pinctrl-msm is
a bad idea.
We're debating adding support for multiple TLMMs, and we may create a
new HID for that, so that we can define all pins on all TLMMs in one
device. We would need to create a new HID and new DSDs to go with it.
> I'm trying to resolve everything at once: gpios, pinctrl pins,
> and irqs exposed by the TLMM hardware. The value is that we solve
> it all, once, now.
Keep in mind that I am now in vacation, and so I won't be able to submit
any more patches for a while.
> The DT binding can also be resolved at the
> same time, so when we need to express this in DT it's already
> done.
Ok.
> Otherwise, something can request irqs from the irqdomain
> even if the irq can't be enabled, or it can try to mux the pin to
> some other function, even if the function selection can't be
> configured.
Is it possible to request an IRQ for a pin if the pin itself can't be
requested?
> Boiling everything down into the irq valid mask should cover all
> these cases, and not require us to strip const from all the data
> in the non-ACPI pinctrl drivers to replace the value in the npins
> field at runtime.
Ok.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Fix typo in MSCL clock controller unit address
From: Chanwoo Choi @ 2017-12-21 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220192702.32515-2-krzk@kernel.org>
On 2017? 12? 21? 04:27, Krzysztof Kozlowski wrote:
> Fix typo in unit address of MSCL clock controller (the reg entry is
> correct).
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 0ba5df825eff..3e8311c60d1b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -468,7 +468,7 @@
> clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
> };
>
> - cmu_mscl: clock-controller at 105d0000 {
> + cmu_mscl: clock-controller at 150d0000 {
> compatible = "samsung,exynos5433-cmu-mscl";
> reg = <0x150d0000 0x1000>;
> #clock-cells = <1>;
>
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH] PCI: Mediatek: clear irq status after irq dispathed to avoid reentry
From: Bjorn Helgaas @ 2017-12-21 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513738334-26213-1-git-send-email-honghui.zhang@mediatek.com>
[+cc Lorenzo, please cc him on all drivers/{host,dwc,endpoint} material]
Please run "git log --oneline drivers/pci/host/pcie-mediatek.c" and
make yours match. Same capitalization, same sentence structure, etc.,
e.g.,
PCI: mediatek: Clear IRQ status ...
s/dispathed/dispatched/
s/irq/IRQ/ in the summary and all the English text below.
On Wed, Dec 20, 2017 at 10:52:14AM +0800, honghui.zhang at mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> There maybe a same irq reentry scenario after irq received in current
> irq handle flow:
> EP device PCIe host driver EP driver
> 1. issue an irq
> 2. received irq
> 3. clear irq status
> 4. dispatch irq
> 5. clear irq source
> The irq status was not successfully cleared at step 2 since the irq
> source was not cleared yet. So the PCIe host driver may receive the
> same irq after step 5. Then there's an irq reentry occurred.
> Even worse, if the reentry irq was not an irq that EP driver expected,
> it may not handle the irq. Then we may run into the dead loop from
By "dead loop" I assume you mean "infinite loop"? I don't think it's
a deadlock since nothing is waiting.
> step 2 to step 4.
> Clear the irq status after irq have been dispatched to avoid the irq
> reentry.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> ---
> drivers/pci/host/pcie-mediatek.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index db93efd..3248771 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -605,11 +605,11 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
> for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
> - /* Clear the INTx */
> - writel(1 << bit, port->base + PCIE_INT_STATUS);
> virq = irq_find_mapping(port->irq_domain,
> bit - INTX_SHIFT);
> generic_handle_irq(virq);
> + /* Clear the INTx */
> + writel(1 << bit, port->base + PCIE_INT_STATUS);
> }
> }
>
> @@ -619,10 +619,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>
> while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
> for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
> - /* Clear the MSI */
> - writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> virq = irq_find_mapping(port->msi_domain, bit);
> generic_handle_irq(virq);
> + /* Clear the MSI */
> + writel(1 << bit, port->base + PCIE_IMSI_STATUS);
> }
> }
> /* Clear MSI interrupt status */
> --
> 2.6.4
>
>
> _______________________________________________
> 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 1/2] arm64: dts: exynos: Use lower case hex addresses in node unit addresses
From: Chanwoo Choi @ 2017-12-21 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220192702.32515-1-krzk@kernel.org>
Dear Krzysztof,
On 2017? 12? 21? 04:27, Krzysztof Kozlowski wrote:
> Convert all hex addresses in node unit addresses to lower case to
> fix warnings like:
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dtb: Warning (simple_bus_reg):
> Node /soc/video-scaler at 13C00000 simple-bus unit address format error, expected "13c00000"
>
> Conversion was done using sed:
> $ sed -e 's/@\([a-zA-Z0-9_-]*\) {/@\L\1 {/' -i arch/arm64/boot/dts/exynos/*.dts*
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 1962b8074349..0ba5df825eff 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -994,7 +994,7 @@
> reg = <0x145f0000 0x1038>;
> };
>
> - gsc_0: video-scaler at 13C00000 {
> + gsc_0: video-scaler at 13c00000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c00000 0x1000>;
> interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1008,7 +1008,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - gsc_1: video-scaler at 13C10000 {
> + gsc_1: video-scaler at 13c10000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c10000 0x1000>;
> interrupts = <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1022,7 +1022,7 @@
> power-domains = <&pd_gscl>;
> };
>
> - gsc_2: video-scaler at 13C20000 {
> + gsc_2: video-scaler at 13c20000 {
> compatible = "samsung,exynos5433-gsc";
> reg = <0x13c20000 0x1000>;
> interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1049,7 +1049,7 @@
> power-domains = <&pd_mscl>;
> };
>
> - mfc: codec at 152E0000 {
> + mfc: codec at 152e0000 {
> compatible = "samsung,exynos5433-mfc";
> reg = <0x152E0000 0x10000>;
> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 9a3fbed1765a..3504837b1d43 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -103,7 +103,7 @@
> #size-cells = <1>;
> ranges;
>
> - pdma0: pdma at 10E10000 {
> + pdma0: pdma at 10e10000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10E10000 0x1000>;
> interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
> @@ -114,7 +114,7 @@
> #dma-requests = <32>;
> };
>
> - pdma1: pdma at 10EB0000 {
> + pdma1: pdma at 10eb0000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10EB0000 0x1000>;
> interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
>
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-21 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a5809701-3f81-3f79-f558-a831ce4091c2@codeaurora.org>
On 12/20, Timur Tabi wrote:
> On 12/20/2017 02:15 AM, Stephen Boyd wrote:
> >Here's the patch. I get a hang when dumping debugfs, but at least
> >sysfs expose fails when trying to request blocked gpios. I need
> >to check if we need to say "yes" to pins that are above the gpio
> >max for pinctrl. I'll do that tomorrow.
>
> Sorry, I just don't see how this is better than my patches. I don't
> understand the need for involving the IRQ valid mask. I also don't
> see the value in adding code to look for a property that exists only
> in one ACPI HID (QCOM8002) as if it were generic. The "num-gpios"
> and "gpios" DSDs are not supposed to exist in any other HID, so
> there should be no code that reads it in pinctrl-msm.
I don't see how it hurts to treat it generically. Presumably
that's the way it will be done on ACPI platforms going forward?
No need to tie it to some ACPI HID.
I'm trying to resolve everything at once: gpios, pinctrl pins,
and irqs exposed by the TLMM hardware. The value is that we solve
it all, once, now. The DT binding can also be resolved at the
same time, so when we need to express this in DT it's already
done. Otherwise, something can request irqs from the irqdomain
even if the irq can't be enabled, or it can try to mux the pin to
some other function, even if the function selection can't be
configured.
Boiling everything down into the irq valid mask should cover all
these cases, and not require us to strip const from all the data
in the non-ACPI pinctrl drivers to replace the value in the npins
field at runtime.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] spi: pxa2xx: avoid redundant gpio_to_desc(desc_to_gpio()) round-trip
From: Rasmus Villemoes @ 2017-12-21 0:37 UTC (permalink / raw)
To: linux-arm-kernel
gpio_free(gpio) simply does gpiod_free(gpio_to_desc(gpio)), so it's
simpler and cleaner to use gpiod_free directly.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/spi/spi-pxa2xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4cb515a3104c..c209dc1047b5 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1237,7 +1237,7 @@ static int setup_cs(struct spi_device *spi, struct chip_data *chip,
* different chip_info, release previously requested GPIO
*/
if (chip->gpiod_cs) {
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
chip->gpiod_cs = NULL;
}
@@ -1417,7 +1417,7 @@ static void cleanup(struct spi_device *spi)
if (drv_data->ssp_type != CE4100_SSP && !drv_data->cs_gpiods &&
chip->gpiod_cs)
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
kfree(chip);
}
--
2.11.0
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add self as extended maintainer for a slew of files
From: Alessandro Rubini @ 2017-12-20 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2LFGyTfdQ2AYd=jeu4vCbu5oVqQJhVjFwwc-zChLyj=A@mail.gmail.com>
>> Alessandro is not working on this platform any more.
>>
>> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Yes, that's true. Thanks Linusw, and Arnd.
Acked-by: Alessandro Rubini <rubini@unipv.it>
/alessandro
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Russell King @ 2017-12-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
The 88e1545 PHY has its interrupts wired to the VF610, so we might as
well use them.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This is certainly not correct, as all PHYs on this device share the
same interrupt line, but we can't specify the pinmux settings
individually on each PHY. How should this be handled?
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 782b69a3acdf..d6786c5d0109 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -312,12 +312,20 @@
#size-cells = <0>;
switch2phy0: phy at 0 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mv88e1545>;
};
switch2phy1: phy at 1 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <1>;
};
switch2phy2: phy at 2 {
+ interrupt-parent = <&gpio0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
reg = <2>;
};
};
@@ -488,6 +496,12 @@
>;
};
+ pinctrl_mv88e1545: pinctrl-mv88e1545 {
+ fsl,pins = <
+ VF610_PAD_PTB0__GPIO_22 0x219d
+ >;
+ };
+
pinctrl_pca9554_22: pinctrl-pca95540-22 {
fsl,pins = <
VF610_PAD_PTB28__GPIO_98 0x219d
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
first three PHYs are used, the remaining PHY is unused. When we wire
up the SFF sockets in a later commit, the omission of this causes the
fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
the auto-probing of the bus, and discovery of this PHY.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index ede8649ba515..782b69a3acdf 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -255,16 +255,19 @@
port at 0 {
reg = <0>;
label = "lan6";
+ phy-handle = <&switch2phy0>;
};
port at 1 {
reg = <1>;
label = "lan7";
+ phy-handle = <&switch2phy1>;
};
port at 2 {
reg = <2>;
label = "lan8";
+ phy-handle = <&switch2phy2>;
};
port at 3 {
@@ -304,6 +307,20 @@
};
};
};
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch2phy0: phy at 0 {
+ reg = <0>;
+ };
+ switch2phy1: phy at 1 {
+ reg = <1>;
+ };
+ switch2phy2: phy at 2 {
+ reg = <2>;
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: vf610-zii-dev-rev-b: fix interrupt for GPIO expander
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
The interrupt specification for the GPIO expander is wrong - the
expander is wired to PTB28, which is GPIO98. GPIO98 is on gpio chip
3, not 2.
In addition, the device is missing a required property. Interrupt
controllers must have the "interrupt-controller" property specified.
Add this.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index acdf12ad0622..ede8649ba515 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -371,7 +371,8 @@
reg = <0x22>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&gpio2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: vf610-zii-dev: enable edma1
From: Russell King @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220231108.GJ10595@n2100.armlinux.org.uk>
EDMA1 is required for the SPI controller used on the ZII boards to be
functional. Enable EDMA1.
Fixes: 14c416336820 ("ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 6b58d3a97992..aadd36db0092 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -96,6 +96,10 @@
status = "okay";
};
+&edma1 {
+ status = "okay";
+};
+
&esdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_esdhc1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] vf610-zii-dev updates
From: Russell King - ARM Linux @ 2017-12-20 23:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
These patches update the DT for the ZII VF610 boards.
The first patch fixes complaints at boot about missing DMAs on rev C
boards, particularly for the SPI interface. This is because edma1 is
not enabled. This seems to be a regression from the 4.10 era.
The second patch fixes an interrupt storm during boot on rev B boards,
which causes boot to take 80+ seconds - this seems to be a long
standing issue since the DT description was first added. The PTB28
pin is definitely GPIO 98, and GPIO 98 is definitely part of the
gpio3 block, not the gpio2 block. Since GPIO 66 (which is the
corresponding GPIO in gpio2) is low, and the IRQ trigger is level-low,
this causes an interrupt storm.
The last two patches add an explicit description of the PHYs that are
actually connected to the switch - the 88e1545 is a quad PHY, and
without describing the MDIO bus, DSA assumes that any PHYs it can
discover are present for the switch. As only the first three PHYs
are connected, this leads the 4th port to believe it is connected to
the 4th PHY when the fixed-link definition is (eventually) removed.
Head this off by providing the proper descriptions, and as we have
them, also describe the interrupts for these PHYs.
Note, however, that the interrupt description is not quite correct -
the 88e1545 PHYs all share one interrupt line, and there is a register
in the PHY which can be used to demux the interrupt to the specific
PHY. However, in this description, we ignore the demux register, and
just share the interrupt between the PHYs. That much is fine, but
the pinmuxing becomes problematical - if we describe the same pinmux
settings for each PHY for the interrupt line, the 2nd/3rd PHYs fail.
This has no known solution. Suggestions welcome.
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 34 ++++++++++++++++++++++++++++++-
arch/arm/boot/dts/vf610-zii-dev.dtsi | 4 ++++
2 files changed, 37 insertions(+), 1 deletion(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v3 02/20] dt-bindings: gpio: Add ASPEED constants
From: Rob Herring @ 2017-12-20 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220032328.30584-3-joel@jms.id.au>
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote:
> These are used to by the device tree to map pin numbers to constants
> required by the GPIO bindings.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> --
> v3:
> - Remove dtsi includes from this patch, they will come later
> ---
> include/dt-bindings/gpio/aspeed-gpio.h | 49 ++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 include/dt-bindings/gpio/aspeed-gpio.h
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Rob Herring @ 2017-12-20 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219210523.10428-1-kevans91@ksu.edu>
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver for FreeBSD.
>
> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> ---
>
> Changes in v2:
> - remove bogus "From:" line in commit text; no functional change
>
> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
> 2 files changed, 6 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: dts: stratix10: fix SPI settings
From: thor.thayer at linux.intel.com @ 2017-12-20 21:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <thor.thayer@linux.intel.com>
Correct the SPI Master node settings.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 7c9bdc7ab50b..367bc00be802 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -248,7 +248,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda4000 0x1000>;
- interrupts = <0 101 4>;
+ interrupts = <0 99 4>;
+ resets = <&rst SPIM0_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
@@ -259,7 +261,9 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0xffda5000 0x1000>;
- interrupts = <0 102 4>;
+ interrupts = <0 100 4>;
+ resets = <&rst SPIM1_RESET>;
+ reg-io-width = <4>;
num-chipselect = <4>;
bus-num = <0>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2017-12-20 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3lxccr7.fsf@belgarion.home>
On Wed, 20 Dec 2017 22:26:04 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
>
> > Hello Robert,
> >
> > On Mon, 18 Dec 2017 08:11:35 +0100
> > Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >
> >> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> >>
> >> >> Robert, it would be great if you could also do more testing on PXA
> >> >> and validate this driver. If needed, a branch ready to be tested is
> >> >> available at [3]. It is based on nand/next and has all the changes
> >> >> brought by the previously mentionned series as well as this one.
> >> >
> >> > Robert, do you think you'll have some time to test Miquel's branch
> >> > on your PXA boards? Miquel already tested on one of these boards
> >> > (CM-X300), but we'd like to have other testers. Also feel free to
> >> > review the driver if have the time.
> >> >
> >> > Thanks,
> >> >
> >> > Boris
> >>
> >> Hi Boris and Miquel,
> >>
> >> I have applied the whole serie to linux-next yesterday.
> >>
> >> A boot attempt on my zylonite with my old defconfig (with the new
> >> Marvell NAND config activated) yields to :
> >> - this message
> >> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
> >> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
> >> error -22
> >> - then my board hangs
> >>
> >> Is there something to be done to improve the trace level so that you
> >> can guess what's happening ?
> >
> > Thank you very much for testing this.
> >
> > Could you please try this branch [1] instead of linux-next + the
> > patches?
> >
> > Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> > it should help us figuring out what is wrong.
>
> Done, same result, the dmesg is in [1].
Looks like there is a mismatch on the nand bus width detected by the
core and the one declared by the driver. Can you try with the following
diff applied?
Thanks,
Boris
--->8---
diff --git a/drivers/mtd/nand/marvell_nand.c b/drivers/mtd/nand/marvell_nand.c
index c618ccb22a61..ddd6a07888e2 100644
--- a/drivers/mtd/nand/marvell_nand.c
+++ b/drivers/mtd/nand/marvell_nand.c
@@ -2481,6 +2481,7 @@ static int marvell_nand_chip_init(struct device *dev, struct marvell_nfc *nfc,
*/
chip->ecc.mode = NAND_ECC_HW;
+ chip->options |= NAND_BUSWIDTH_AUTO;
ret = nand_scan_ident(mtd, marvell_nand->nsels, NULL);
if (ret) {
dev_err(dev, "could not identify the nand chip\n");
^ permalink raw reply related
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-20 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218092535.2ca1fe13@xps13>
Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
> Hello Robert,
>
> On Mon, 18 Dec 2017 08:11:35 +0100
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
>> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>>
>> >> Robert, it would be great if you could also do more testing on PXA
>> >> and validate this driver. If needed, a branch ready to be tested is
>> >> available at [3]. It is based on nand/next and has all the changes
>> >> brought by the previously mentionned series as well as this one.
>> >
>> > Robert, do you think you'll have some time to test Miquel's branch
>> > on your PXA boards? Miquel already tested on one of these boards
>> > (CM-X300), but we'd like to have other testers. Also feel free to
>> > review the driver if have the time.
>> >
>> > Thanks,
>> >
>> > Boris
>>
>> Hi Boris and Miquel,
>>
>> I have applied the whole serie to linux-next yesterday.
>>
>> A boot attempt on my zylonite with my old defconfig (with the new
>> Marvell NAND config activated) yields to :
>> - this message
>> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
>> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
>> error -22
>> - then my board hangs
>>
>> Is there something to be done to improve the trace level so that you
>> can guess what's happening ?
>
> Thank you very much for testing this.
>
> Could you please try this branch [1] instead of linux-next + the
> patches?
>
> Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
> it should help us figuring out what is wrong.
Done, same result, the dmesg is in [1].
Cheers.
--
Robert
[1] Kernel output
Loading ARM Linux zImage '/mnt/tftp/zImage_jenkins'
commandline: ram=64M console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=/home/none/nfsroot/zylonite,v3,tcp earlycon mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root)
arch_number: 1233
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00041-g4dc0195 (jenkins at belgarath) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29)) #721 PREEMPT Wed Dec 20 22:15:08 CET 2017
[ 0.000000] CPU: XScale-V3 based processor [69056891] revision 1 (ARMv5TE), cr=0000397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: PXA3xx Platform Development Kit (aka Zylonite)
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] RO Mode clock: 0.00MHz
[ 0.000000] Run Mode clock: 0.00MHz
[ 0.000000] Turbo Mode clock: 0.00MHz
[ 0.000000] System bus clock: 0.00MHz
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[ 0.000000] random: fast init done
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/ram0 ip=192.168.1.232:192.168.1.5::255.255.255.0::eth0:on console=ttyS0,115200 mem=64M mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root) ubi.mtd=5 earlycon=pxa,io,0xf6200000,115200n8 debug no_console_suspend
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 56856K/65536K available (4225K kernel code, 202K rwdata, 972K rodata, 2396K init, 102K bss, 8680K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04289e8 (4227 kB)
[ 0.000000] .init : 0xc053f000 - 0xc0796000 (2396 kB)
[ 0.000000] .data : 0xc0796000 - 0xc07c8bec ( 203 kB)
[ 0.000000] .bss : 0xc07c8bec - 0xc07e25fc ( 103 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 336, preallocated irqs: 336
[ 0.000000] RJK: parent_rate=13000000, xl=8, xn=1
[ 0.000069] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[ 0.000267] clocksource: oscr0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[ 0.002142] Console: colour dummy device 80x30
[ 0.002302] Calibrating delay loop... 103.83 BogoMIPS (lpj=519168)
[ 0.081019] pid_max: default: 32768 minimum: 301
[ 0.081860] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.081960] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.085178] CPU: Testing write buffer coherency: ok
[ 0.089002] Setting up static identity map for 0x80008200 - 0x80008260
[ 0.089962] Hierarchical SRCU implementation.
[ 0.102994] devtmpfs: initialized
[ 0.113882] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.114023] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.116361] NET: Registered protocol family 16
[ 0.119175] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.389891] Advanced Linux Sound Architecture Driver Initialized.
[ 0.394261] clocksource: Switched to clocksource oscr0
[ 0.552465] NET: Registered protocol family 2
[ 0.559531] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559757] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559938] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.560478] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.560660] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.561794] NET: Registered protocol family 1
[ 0.563834] RPC: Registered named UNIX socket transport module.
[ 0.563934] RPC: Registered udp transport module.
[ 0.563988] RPC: Registered tcp transport module.
[ 0.564046] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.503938] Initialise system trusted keyrings
[ 2.506180] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 2.510083] NFS: Registering the id_resolver key type
[ 2.510312] Key type id_resolver registered
[ 2.510374] Key type id_legacy registered
[ 2.516887] Key type asymmetric registered
[ 2.516991] Asymmetric key parser 'x509' registered
[ 2.517149] io scheduler noop registered
[ 2.517213] io scheduler deadline registered
[ 2.517601] io scheduler cfq registered (default)
[ 2.517671] io scheduler mq-deadline registered
[ 2.517732] io scheduler kyber registered
[ 2.577937] pxa-dma pxa-dma.0: initialized 32 channels on 100 requestors
[ 2.581363] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1
[ 3.056921] console [ttyS0] enabled
[ 3.063284] pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37, base_baud = 928571) is a UART2
[ 3.076187] pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36, base_baud = 928571) is a UART3
[ 3.091759] nand: executing subop:
[ 3.097924] nand: ->CMD [0xff]
[ 3.101830] nand: ->WAITRDY [max 250 ms]
[ 3.106998] marvell-nfc pxa3xx-nand:
[ 3.106998] NDCR: 0x90079fff
[ 3.106998] NDCB0: 0x00a000ff
[ 3.106998] NDCB1: 0x00000000
[ 3.106998] NDCB2: 0x00000000
[ 3.106998] NDCB3: 0x00000000
[ 3.126261] nand: executing subop:
[ 3.129732] nand: ->CMD [0x90]
[ 3.133605] nand: ->ADDR [1 cyc: 00]
[ 3.138275] nand: ->DATA_IN [2 B, force 8-bit]
[ 3.143276] marvell-nfc pxa3xx-nand:
[ 3.143276] NDCR: 0x90079fff
[ 3.143276] NDCB0: 0x00610090
[ 3.143276] NDCB1: 0x00000000
[ 3.143276] NDCB2: 0x00000000
[ 3.143276] NDCB3: 0x00000000
[ 3.162111] nand: executing subop:
[ 3.165754] nand: ->CMD [0x90]
[ 3.169644] nand: ->ADDR [1 cyc: 00]
[ 3.173945] nand: ->DATA_IN [8 B, force 8-bit]
[ 3.179056] marvell-nfc pxa3xx-nand:
[ 3.179056] NDCR: 0x90079fff
[ 3.179056] NDCB0: 0x00610090
[ 3.179056] NDCB1: 0x00000000
[ 3.179056] NDCB2: 0x00000000
[ 3.179056] NDCB3: 0x00000000
[ 3.197729] nand: executing subop:
[ 3.201185] nand: ->CMD [0x90]
[ 3.205207] nand: ->ADDR [1 cyc: 20]
[ 3.209519] nand: ->DATA_IN [4 B, force 8-bit]
[ 3.214626] marvell-nfc pxa3xx-nand:
[ 3.214626] NDCR: 0x90079fff
[ 3.214626] NDCB0: 0x00610090
[ 3.214626] NDCB1: 0x00000020
[ 3.214626] NDCB2: 0x00000000
[ 3.214626] NDCB3: 0x00000000
[ 3.233249] nand: executing subop:
[ 3.236837] nand: ->CMD [0x90]
[ 3.240719] nand: ->ADDR [1 cyc: 40]
[ 3.245158] nand: ->DATA_IN [5 B, force 8-bit]
[ 3.250133] marvell-nfc pxa3xx-nand:
[ 3.250133] NDCR: 0x90079fff
[ 3.250133] NDCB0: 0x00610090
[ 3.250133] NDCB1: 0x00000040
[ 3.250133] NDCB2: 0x00000000
[ 3.250133] NDCB3: 0x00000000
[ 3.268756] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xba
[ 3.275239] nand: ST Micro pxa3xx-nand
[ 3.279028] nand: bus width 8 instead of 16 bits
[ 3.283651] nand: No NAND device found
[ 3.287582] marvell-nfc pxa3xx-nand: could not identify the nand chip
[ 3.294466] marvell-nfc: probe of pxa3xx-nand failed with error -22
^ permalink raw reply
* [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC
From: Alexandre Belloni @ 2017-12-20 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218115133.16371-1-linux-kernel-dev@beckhoff.com>
On 18/12/2017 at 12:51:29 +0100, linux-kernel-dev at beckhoff.com wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
>
Applied 1/4 and 3/4, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Rob Herring @ 2017-12-20 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-3-f.fainelli@gmail.com>
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote:
> Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
> compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
> document in the binding the fallback property
> ("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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