* [PATCH 1/3] ARM: exynos: remove unused <mach/memory.h>
From: Kukjin Kim @ 2014-07-22 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgA0fc0_8JOOE01y=UKv-eAZuWiAkAKHG5iam0Zkhp9TA@mail.gmail.com>
On 07/23/14 01:14, Olof Johansson wrote:
> On Tue, Jul 22, 2014 at 12:51 AM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
>> Hello,
>>
>> who takes care of this series?
>>
>> In fact they are all orthogonal to each other.
>>
>> The first patch
>>
>> ARM: exynos: remove unused<mach/memory.h>
>>
>> has been reviewed and tested by Tomasz Figa and Sachin Kamat. Can the
>> Samsung people pick it up? Or armsoc?
>
> Kukjin should apply this one.
>
Oh, thanks for gentle reminder and I've applied into 2nd cleanup.
Thanks,
Kukjin
>> Patch 2 (v2!)
>>
>> ARM: remove remaining definitions of PLAT_PHYS_OFFSET from<mach/memory.h>
>>
>> touches several arch/arm/mach-*/include/mach/memory.h and
>> arch/arm/Kconfig. armsoc? Russell?
>
> This can go through either, but Russell has already reviewed it once
> so send it to his patch tracker.
>
>> Patch 3 fixes a warning regarding nommu and touches the Kconfig entry
>> for Integrator and Renesas (non-multiplatform). armsoc?
>
> Don't know without seeing the patch. What's the patch subject so I can find it?
^ permalink raw reply
* [GIT PULL 4/5] Samsung exynos_mct update for v3.17
From: Kukjin Kim @ 2014-07-22 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CEA020.309@linaro.org>
On 07/23/14 02:32, Daniel Lezcano wrote:
> On 07/22/2014 12:59 PM, Kukjin Kim wrote:
>> Daniel Lezcano wrote:
>>>
>>> On 07/20/2014 12:06 AM, Olof Johansson wrote:
>>>> On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote:
>>>>> Note that this is also based on 3.16-rc5 because of dependency with
>>>>> previous samsung fixes including exynos_mct already merged in
>>>>> mainline during -rc.
>>>>>
>>>>> The following changes since commit
>>>>> 1795cd9b3a91d4b5473c97f491d63892442212ab:
>>>>>
>>>>> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> tags/exynos-mct
>>>>>
>>>>> for you to fetch changes up to
>>>>> 1a631118c1d085fe162f3b6d44f710c72206ef2d:
>>>>>
>>>>> clocksource: exynos_mct: Only use 32-bits where possible
>>>>> (2014-07-19 03:07:52 +0900)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> exynos_mct update for v3.17
>>>>> - only use 32-bit access for performance benefits on exynos
>>>>> 32-bit system and this means ARCH timer should be supported
>>>>> on exynos 64-bit system instead of current MCT.
>>>>> - use readl_relaxed/writel_relaxed to consistently use the
>>>>> proper functions in exynos_mct.
>>>>
>>>> There's no reason for these to go through arm-soc, is there? They
>>>> should
>>>> go through the clocksource tree (Daniel Lezcano / Thomas Gleixner).
>>>> They
>>>> also lack acks from them if they for some reason need to go through
>>>> arm-soc.
>>>
>> Olof, you're right. The branch has no dependency with arm-soc so I
>> agreed.
>>
>>> Yes, that's right. Furthermore I have been discussing with Doug about
>>> these patches before.
>>>
>>> Kukjin, is there any dependency on these patches ?
>>>
>> Yeah, Daniel, it should be handled in the clocksource tree so how
>> should I do
>> for it?
>
> I can pull your branch v3.17-next/mct-exynos and you drop the merge from
> this branch in your master ?
>
Yes please and I did drop the merge in my -next just now.
Thanks,
Kukjin
^ permalink raw reply
* [GIT PULL] mach-bcm: brcmstb platform support for 3.17
From: Brian Norris @ 2014-07-22 23:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Matt,
The following changes since commit 9a3c4145af32125c5ee39c0272662b47307a8323:
Linux 3.16-rc6 (2014-07-20 21:04:16 -0700)
are available in the git repository at:
git://github.com/brcm/linux.git tags/for-3.17/brcmstb
for you to fetch changes up to 4ba80cbf72940f44fc82067b66221996a20b23f1:
MAINTAINERS: add entry for Broadcom ARM STB architecture (2014-07-22 16:17:29 -0700)
Let me know if you'd prefer just Acked/Signed-off-by/Reviewed-by patches
sent to your mailbox instead of git pull reqs.
I expect these patches to go in through Russel King and through
drivers/power/, so I left them out:
ARM: Enable erratum 798181 for Broadcom Brahma-B15
ARM: do CPU-specific init for Broadcom Brahma15 cores
power: reset: Add reboot driver for brcmstb
----------------------------------------------------------------
brcmstb platform support, for BCM7xxx STB SoCs
----------------------------------------------------------------
Brian Norris (2):
ARM: brcmstb: select GISB arbiter and interrupt drivers
MAINTAINERS: add entry for Broadcom ARM STB architecture
Marc Carino (6):
ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
ARM: brcmstb: add debug UART for earlyprintk support
ARM: brcmstb: add CPU binding for Broadcom Brahma15
ARM: brcmstb: add misc. DT bindings for brcmstb
ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
.../devicetree/bindings/arm/brcm-brcmstb.txt | 95 ++++++
Documentation/devicetree/bindings/arm/cpus.txt | 2 +
Documentation/devicetree/bindings/arm/gic.txt | 1 +
MAINTAINERS | 8 +
arch/arm/Kconfig.debug | 16 +-
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/bcm7445-bcm97445svmb.dts | 14 +
arch/arm/boot/dts/bcm7445.dtsi | 111 +++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-bcm/Kconfig | 16 +
arch/arm/mach-bcm/Makefile | 5 +
arch/arm/mach-bcm/brcmstb.c | 28 ++
arch/arm/mach-bcm/brcmstb.h | 19 ++
arch/arm/mach-bcm/headsmp-brcmstb.S | 33 ++
arch/arm/mach-bcm/platsmp-brcmstb.c | 363 +++++++++++++++++++++
15 files changed, 713 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
create mode 100644 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
create mode 100644 arch/arm/boot/dts/bcm7445.dtsi
create mode 100644 arch/arm/mach-bcm/brcmstb.c
create mode 100644 arch/arm/mach-bcm/brcmstb.h
create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
create mode 100644 arch/arm/mach-bcm/platsmp-brcmstb.c
^ permalink raw reply
* [PATCH 0/6] net: mvpp2: Assorted fixes
From: Ezequiel Garcia @ 2014-07-22 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723002916.67a0bb3c@free-electrons.com>
On 23 Jul 12:29 AM, Thomas Petazzoni wrote:
> On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
>
> > >> This series does not apply to the 'net' tree at all, please respin
> > >> and resubmit.
> > >
> > > This series applies on net-next.
> > >
> > > Sorry for not mentioning it,
> >
> > They are bonafide bug fixes, therefore should be targetted at 'net'.
>
> Except that I believe they are fixes for a driver which itself is in
> net-next, i.e scheduled for 3.17.
>
That's right. These are fixes for the new mvpp2 driver, which is only
in net-next.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/6] net/macb: add RX checksum offload feature
From: Eric Dumazet @ 2014-07-22 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CE9109.9040407@atmel.com>
On Tue, 2014-07-22 at 18:27 +0200, Cyrille Pitchen wrote:
> Le 18/07/2014 17:36, Eric Dumazet a ?crit :
> > On Fri, 2014-07-18 at 16:21 +0200, Cyrille Pitchen wrote:
> >> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> >> ---
> >> drivers/net/ethernet/cadence/macb.c | 29 ++++++++++++++++++++++++++++-
> >> drivers/net/ethernet/cadence/macb.h | 2 ++
> >> 2 files changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> >> index 9bdcd1b..6acd6e2 100644
> >> --- a/drivers/net/ethernet/cadence/macb.c
> >> +++ b/drivers/net/ethernet/cadence/macb.c
> >> @@ -766,6 +766,8 @@ static int gem_rx(struct macb *bp, int budget)
> >>
> >> skb->protocol = eth_type_trans(skb, bp->dev);
> >> skb_checksum_none_assert(skb);
> >> + if (bp->dev->features & NETIF_F_RXCSUM)
> >> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> >>
> >
> >
> > Really ?
> >
> > If this is what you meant, this deserves a big and fat comment.
> >
> >
> >
> Hi Eric,
>
> Isn't it the proper way to do? According to Cadence documentation
> about RX checksum offload:
> "If any of the checksums (IP, TCP or UDP) are verified incorrect by
> the GEM, the packet is discarded."
>
> If I understand, when RX checksum offload is enabled setting bit 24 of
> the Network Configuration Register, the driver only receives RX frames
> with correct checksum. Then it tells the kernel that there's no need
> to verify the checksum again in software. This is done setting
> skb->ip_summed to CHECKSUM_UNNECESSARY. Intel e1000 driver does the
> same in e1000_rx_checksum() function.
>
> Also bit 24 of the Network Configuration Register is updated by
> macb_open() and macb_set_features() so it always matches the state of
> NETIF_F_RXCSUM flag in dev->features, once the network interface is
> up. That's why I'd rather read from dev->features than read from
> register.
>
> Did I make a mistake? Is it the kind of comment you expect to be
> added?
>
> Regards,
Usually, frames are not discarded, and a bit is present in rx descriptor
to tell us if (TCP) checksum was validated by the NIC
We want tcpdump to get a copy of corrupted TCP frames, even if TCP stack
drops them later.
If this NIC drops incorrect frames, I am afraid we cant use this RX
offload at all.
^ permalink raw reply
* [PATCH v7 0/5] Add Keystone PCIe controller driver
From: Bjorn Helgaas @ 2014-07-22 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405961925-27248-1-git-send-email-m-karicheri2@ti.com>
On Mon, Jul 21, 2014 at 12:58:40PM -0400, Murali Karicheri wrote:
> This patch series add PCIe controller driver for keystone SoCs. This is
> based on v4 of the series posted to the mailing list. Keystone PCI controller
> is based on version 3.65 of the DW hardware. This driver uses the DW core
> functions to implement the PCI controller driver for keystone.
>
> Testing:
> =======
>
> Testing of the driver is done on TI's K2HK EVM inserted to a Elma blu!eco
> MicroTCA chassis AMC slot with JumpGen SEM-200 AMC SATA Storage and Dual
> Ethernet Card Express inserted on another AMC slot. The e1000e driver available
> on intel's website is patched to the kernel source tree and build. e1000e.ko
> is dynamically loaded and executed ping and iperf tests to test the
> functionality.
>
> Thanks to all of you who have contributed by reviewing and offering valuable
> comments. If you want me to add your "Reviewed-by", please let me know so that
> I can add it to the commit log and re-send. Patch 1-3 has Acks from maintainers
> and I believe this can be merged to upstream branch. Patch 4 is waiting for
> Ack from DT maintainer. Please provide the same at the earliest.
>
> Thanks
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>
> CC: Russell King <linux@arm.linux.org.uk>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mohit Kumar <mohit.kumar@st.com>
> CC: Jingoo Han <jg1.han@samsung.com>
> CC: Bjorn Helgaas <bhelgaas@google.com>
> CC: Pratyush Anand <pratyush.anand@st.com>
> CC: Richard Zhu <r65037@freescale.com>
> CC: Kishon Vijay Abraham I <kishon@ti.com>
> CC: Marek Vasut <marex@denx.de>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: Mark Rutland <mark.rutland@arm.com>
> CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
> CC: Kumar Gala <galak@codeaurora.org>
> CC: Randy Dunlap <rdunlap@infradead.org>
> CC: Grant Likely <grant.likely@linaro.org>
>
> Changelog:
>
> v7
> - Removed ti,enable_linktrain DT property. The driver now check if
> the link is up and then retrain the link if not already up. This
> is as per comment from DT maintainer.
> - Rebased to upstream kernel v3.16-rc6
>
> v6
> - Added Ack from Maintainer for patch 3. Patch 1-3 now have the
> Acks from maintainer and can be merged to upstream branch.
> Patch 4 is waiting ack from DT maintainer.
> v5
> - Rebased to upstream kernel v3.16-rc5
> - Reworked Patch 3/6 and 4/6 into a single patch based on
> maintainer comment to use a API callback model to support
> the v3.65 h/w.
> v4
> - Addressed comments against 5/5.
> - Added a patch 6/6 for Maintainer information
> - Added couple of Acked-By:
> - Rebased to latest Linux 3.16-rc4
> v3
> - DW application register handling code is now part of
> Keystone PCI driver. RFC had this code part of Keystone
> PCI driver, then V1 moved this to a separate file to
> re-use on other platforms that uses this version of the
> DW h/w. Then based on comments against v2, this is moved
> back to Keystone driver.
> - Keystone SerDes phy driver is removed from this series so that
> this can be merged independent of that patch
> - added msi_set_irq()/clear_irq() API's to support Keystone
>
> V2
> - Split the designware pcie enhancement patch to multiple
> patches based on functionality added
> - Remove the quirk code and add a patch to fix mps/mrss
> tuning for ARM. Use kernel command line parameter
> pci=pcie_bus_perf to work with Keystone PCI Controller.
> Following patch addressed this.
> [PATCH v1] ARM: pci: add call to pcie_bus_configure_settings()
> - Add documentation for device tree bindings
> - Add separate interrupt controller nodes for MSI and Legacy
> IRQs and use irq map for legacy IRQ
> - Use compatibility to identify v3.65 version of the DW hardware
> and use it to customize the designware common code.
> - Use reg property for configuration space instead of range
> - Other minor updates based on code inspection.
>
> V1
> - Add an interrupt controller node for Legacy irq chip and use
> interrupt map/map-mask property to map legacy IRQs A/B/C/D
> - Add a Phy driver to replace the original serdes driver
> - Move common application register handling code to a separate
> file to allow re-use across other platforms that use older
> DW PCIe h/w
> - PCI quirk for maximum read request size. Check and override only
> if the maximum is higher than what controller can handle.
> - Converted to a module platform driver.
>
> Murali Karicheri (5):
> PCI: designware: add rd[wr]_other_conf API
> PCI: designware: refactor MSI code to work with v3.65 dw hardware
I applied the above two to my pci/host-designware branch. The rest didn't
apply cleanly because I applied Kishon's DRA7xx changes first, and there
are several conflicts. Can you rebase the rest of them on top of
pci/host-designware?
> PCI: designware: enhance dw_pcie_host_init() to support v3.65 DW
> hardware
> PCI: add PCI controller for keystone PCIe h/w
> PCI: keystone: Update maintainer information
You can squash the MAINTAINERS update into the driver addition. They're
logically part of the same change.
Bjorn
> .../devicetree/bindings/pci/pci-keystone.txt | 68 +++
> MAINTAINERS | 7 +
> drivers/pci/host/Kconfig | 5 +
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pci-keystone-dw.c | 521 ++++++++++++++++++++
> drivers/pci/host/pci-keystone.c | 386 +++++++++++++++
> drivers/pci/host/pci-keystone.h | 58 +++
> drivers/pci/host/pcie-designware.c | 116 +++--
> drivers/pci/host/pcie-designware.h | 9 +
> 9 files changed, 1135 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/pci-keystone.txt
> create mode 100644 drivers/pci/host/pci-keystone-dw.c
> create mode 100644 drivers/pci/host/pci-keystone.c
> create mode 100644 drivers/pci/host/pci-keystone.h
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v7 4/5] PCI: add PCI controller for keystone PCIe h/w
From: Murali Karicheri @ 2014-07-22 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722223527.GA27965@google.com>
Bjorn,
On 07/22/2014 06:35 PM, Bjorn Helgaas wrote:
> On Mon, Jul 21, 2014 at 12:58:44PM -0400, Murali Karicheri wrote:
>> keystone PCIe controller is based on v3.65 version of the
>> designware h/w. Main differences are
>> 1. No ATU support
>> 2. Legacy and MSI irq functions are implemented in
>> application register space
>> 3. MSI interrupts are multiplexed over 8 IRQ lines to the Host
>> side.
>> All of the Application register space handing code are organized into
>> pci-keystone-dw.c and the functions are called from pci-keystone.c
>> to implement PCI controller driver. Also add necessary DT documentation
>> for the driver.
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>> Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> ...
>
>> +++ b/Documentation/devicetree/bindings/pci/pci-keystone.txt
>> ...
>
>> +Note for PCI driver usage
>> +=========================
>> +Driver requires pci=pcie_bus_perf in the bootargs for proper functioning.
>
> Whoa, why is this? Special boot args should not be required.
This was discussed initially and I had added following commit to get
this working instead of a PCI quirk. To get some background please see
the thread for commit below that you also had signed off as well.
commit 8b5742ad156d30ee38486652cdbd152e2d6ebbcc
Author: Murali Karicheri <m-karicheri2@ti.com>
Date: Wed May 28 13:14:53 2014 -0400
ARM/PCI: Call pcie_bus_configure_settings() to set MPS
Call pcie_bus_configure_settings() on ARM, like for other platforms.
pcie_bus_configure_settings() makes sure the MPS across the bus is
uniform
and provides the ability to tune the MRSS and MPS to higher performance
values. This is particularly important for embedded where there is no
firmware to program these PCIe settings for the OS.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
This was added as a preparatory patch to support keystone and
avoid a PCI quirk to do the same. Keystone has MRSS limitation
of 256 bytes. So adding a bootargs flag was suggested a better option
than a PCI quirk.
I will look into the rest of the comments and possibly try to address
them or discuss.
BTW, please apply patch 1-3 that has already got ack from maintainers
and is indepdent of this patch.
Thanks
Murali
>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 21df477..f8bc475 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -46,4 +46,9 @@ config PCI_HOST_GENERIC
>> Say Y here if you want to support a simple generic PCI host
>> controller, such as the one emulated by kvmtool.
>>
>> +config PCI_KEYSTONE
>> + bool "TI Keystone PCIe controller"
>> + depends on ARCH_KEYSTONE
>> + select PCIE_DW
>> + select PCIEPORTBUS
>
> It'd be nice to have some help text here. I know, not everybody else does.
>
>> +++ b/drivers/pci/host/pci-keystone-dw.c
>> ...
>> +void ks_dw_pcie_handle_msi_irq(struct keystone_pcie *ks_pcie , int offset)
>> +{
>> + struct pcie_port *pp =&ks_pcie->pp;
>> + u32 pending, vector;
>> + int src, virq;
>> +
>> + pending = readl(ks_pcie->va_app_base + MSI0_IRQ_STATUS + (offset<< 4));
>
> Blank line here (before the block comment).
>
>> + /*
>> + * MSI0, Status bit 0-3 shows vectors 0, 8, 16, 24, MSI1 status bit
>> + * shows 1, 9, 17, 25 and so forth
>> + */
>> + for (src = 0; src< 4; src++) {
>> + if (BIT(src)& pending) {
>> + vector = offset + (src<< 3);
>> + virq = irq_linear_revmap(pp->irq_domain, vector);
>> + dev_dbg(pp->dev,
>> + "irq: bit %d, vector %d, virq %d\n",
>> + src, vector, virq);
>> + generic_handle_irq(virq);
>> + }
>> + }
>> +}
>> +
>> ...
>
>> +static void __iomem *ks_pcie_cfg_setup(struct keystone_pcie *ks_pcie, u8 bus,
>> + unsigned int devfn)
>> +{
>> + u8 device = PCI_SLOT(devfn), function = PCI_FUNC(devfn);
>> + struct pcie_port *pp =&ks_pcie->pp;
>> + u32 regval;
>> +
>> + if (bus == 0)
>> + return pp->dbi_base;
>> +
>> + regval = (bus<< 16) | (device<< 8) | function;
>> + /*
>> + * Since Bus#1 will be a virtual bus, we need to have TYPE0
>> + * access only.
>> + * TYPE 1
>> + */
>> + if (bus != 1)
>> + regval |= BIT(24);
>> +
>> + writel(regval, ks_pcie->va_app_base + CFG_SETUP);
>> + return pp->va_cfg0_base;
>> +}
>> +
>> +int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
>> + unsigned int devfn, int where, int size, u32 *val)
>> +{
>> + struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
>> + u8 bus_num = bus->number;
>> + void __iomem *addr;
>> + int ret;
>> +
>> + addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>> + ret = dw_pcie_cfg_read(addr + (where& ~0x3), where, size, val);
>
> This *looks* like it needs a lock to protect against concurrent
> ks_pcie_cfg_setup() users, since it writes a register.
>
>> +
>> + return ret;
>
> Please use the same style as in ks_dw_pcie_wr_other_conf(), i.e., get rid
> of "ret".
>
>> +}
>> +
>> +int ks_dw_pcie_wr_other_conf(struct pcie_port *pp,
>> + struct pci_bus *bus, unsigned int devfn, int where,
>> + int size, u32 val)
>> +{
>> + struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
>> + u8 bus_num = bus->number;
>> + void __iomem *addr;
>> +
>> + addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>> +
>> + return dw_pcie_cfg_write(addr + (where& ~0x3), where, size, val);
>> +}
>
>> +++ b/drivers/pci/host/pci-keystone.c
>> ...
>
>> +static struct platform_driver ks_pcie_driver __refdata = {
>
> Why does this need to be __refdata? There are no other occurrences in
> drivers/pci.
>
>> + .probe = ks_pcie_probe,
>> + .remove = __exit_p(ks_pcie_remove),
>> + .driver = {
>> + .name = "keystone-pcie",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(ks_pcie_of_match),
>> + },
>> +};
>
> Bjorn
^ permalink raw reply
* [PATCH v8 02/11] power: reset: Add reboot driver for brcmstb
From: Brian Norris @ 2014-07-22 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5224854.YNJjMxFltp@wuerfel>
+ Sebastian
On Tue, Jul 22, 2014 at 11:02:07PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:02:13 Brian Norris wrote:
> > How about a third option, where we drop the 'select' statement and
> > set POWER_RESET_BRCMSTB to be 'default y'? Then we don't have to modify
> > the defconfig, and it gives the added bonus of choosing a sane default
> > even if you're not based on the multi_v7_defconfig. i.e.:
> >
> > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > index 58c01aed9752..634de7b7fd28 100644
> > --- a/arch/arm/mach-bcm/Kconfig
> > +++ b/arch/arm/mach-bcm/Kconfig
> > @@ -94,7 +94,6 @@ config ARCH_BRCMSTB
> > select MIGHT_HAVE_PCI
> > select HAVE_SMP
> > select HAVE_ARM_ARCH_TIMER
> > - select POWER_RESET_BRCMSTB
> > select BRCMSTB_GISB_ARB
> > select BRCMSTB_L2_IRQ
> > help
> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > index fcb9825debe5..ab5d57e2766d 100644
> > --- a/drivers/power/reset/Kconfig
> > +++ b/drivers/power/reset/Kconfig
> > @@ -23,6 +23,7 @@ config POWER_RESET_AXXIA
> > config POWER_RESET_BRCMSTB
> > bool "Broadcom STB reset driver"
> > depends on POWER_RESET && ARCH_BRCMSTB
> > + default y
> > help
> > This driver provides restart support for ARM-based Broadcom STB
> > boards.
>
> I don't like this too much. Why do you want to allow disabling the
> driver if you make it 'default y' in the first place?
Not much of a reason, but I thought configurability is a positive.
There's really not a good reason to not have this driver though; I can't
imagine someone wanting to build our platform but not be able to reboot
it.
> We try to avoid 'default y' for user-selectable drivers in general.
I didn't know that. A default is technically different than "should a
user be able to disable this," but I suppose the policy makes sense.
> I noticed that in my example, I was missing the default.
I see. That's why I immediately ruled it out.
> It should have been
>
> config POWER_RESET_BRCMSTB
> bool "Broadcom STB reset driver" if COMPILE_TEST
> depends on POWER_RESET && ARM
> default ARCH_BRCMSTB
OK, that's OK with me if it's OK with Sebastian, et al. Respin coming
soon, separate from the mach-bcm and ARM stuff...
(BTW, we might consider rewriting the other config entries to be
similar, if we really want to make this things consistently
nitpick-proof.)
> This way, it always gets selected when ARCH_BRCMSTB is on and
> COMPILE_TEST is off. With COMPILE_TEST enabled, it defaults to
> ARCH_BRCMSTB but can be enabled or disabled for the purpose
> of compile testing.
Thanks,
Brian
^ permalink raw reply
* [PATCH v7 4/5] PCI: add PCI controller for keystone PCIe h/w
From: Bjorn Helgaas @ 2014-07-22 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405961925-27248-5-git-send-email-m-karicheri2@ti.com>
On Mon, Jul 21, 2014 at 12:58:44PM -0400, Murali Karicheri wrote:
> keystone PCIe controller is based on v3.65 version of the
> designware h/w. Main differences are
> 1. No ATU support
> 2. Legacy and MSI irq functions are implemented in
> application register space
> 3. MSI interrupts are multiplexed over 8 IRQ lines to the Host
> side.
> All of the Application register space handing code are organized into
> pci-keystone-dw.c and the functions are called from pci-keystone.c
> to implement PCI controller driver. Also add necessary DT documentation
> for the driver.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ...
> +++ b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> ...
> +Note for PCI driver usage
> +=========================
> +Driver requires pci=pcie_bus_perf in the bootargs for proper functioning.
Whoa, why is this? Special boot args should not be required.
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 21df477..f8bc475 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -46,4 +46,9 @@ config PCI_HOST_GENERIC
> Say Y here if you want to support a simple generic PCI host
> controller, such as the one emulated by kvmtool.
>
> +config PCI_KEYSTONE
> + bool "TI Keystone PCIe controller"
> + depends on ARCH_KEYSTONE
> + select PCIE_DW
> + select PCIEPORTBUS
It'd be nice to have some help text here. I know, not everybody else does.
> +++ b/drivers/pci/host/pci-keystone-dw.c
> ...
> +void ks_dw_pcie_handle_msi_irq(struct keystone_pcie *ks_pcie , int offset)
> +{
> + struct pcie_port *pp = &ks_pcie->pp;
> + u32 pending, vector;
> + int src, virq;
> +
> + pending = readl(ks_pcie->va_app_base + MSI0_IRQ_STATUS + (offset << 4));
Blank line here (before the block comment).
> + /*
> + * MSI0, Status bit 0-3 shows vectors 0, 8, 16, 24, MSI1 status bit
> + * shows 1, 9, 17, 25 and so forth
> + */
> + for (src = 0; src < 4; src++) {
> + if (BIT(src) & pending) {
> + vector = offset + (src << 3);
> + virq = irq_linear_revmap(pp->irq_domain, vector);
> + dev_dbg(pp->dev,
> + "irq: bit %d, vector %d, virq %d\n",
> + src, vector, virq);
> + generic_handle_irq(virq);
> + }
> + }
> +}
> +
> ...
> +static void __iomem *ks_pcie_cfg_setup(struct keystone_pcie *ks_pcie, u8 bus,
> + unsigned int devfn)
> +{
> + u8 device = PCI_SLOT(devfn), function = PCI_FUNC(devfn);
> + struct pcie_port *pp = &ks_pcie->pp;
> + u32 regval;
> +
> + if (bus == 0)
> + return pp->dbi_base;
> +
> + regval = (bus << 16) | (device << 8) | function;
> + /*
> + * Since Bus#1 will be a virtual bus, we need to have TYPE0
> + * access only.
> + * TYPE 1
> + */
> + if (bus != 1)
> + regval |= BIT(24);
> +
> + writel(regval, ks_pcie->va_app_base + CFG_SETUP);
> + return pp->va_cfg0_base;
> +}
> +
> +int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> + unsigned int devfn, int where, int size, u32 *val)
> +{
> + struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
> + u8 bus_num = bus->number;
> + void __iomem *addr;
> + int ret;
> +
> + addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
> + ret = dw_pcie_cfg_read(addr + (where & ~0x3), where, size, val);
This *looks* like it needs a lock to protect against concurrent
ks_pcie_cfg_setup() users, since it writes a register.
> +
> + return ret;
Please use the same style as in ks_dw_pcie_wr_other_conf(), i.e., get rid
of "ret".
> +}
> +
> +int ks_dw_pcie_wr_other_conf(struct pcie_port *pp,
> + struct pci_bus *bus, unsigned int devfn, int where,
> + int size, u32 val)
> +{
> + struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
> + u8 bus_num = bus->number;
> + void __iomem *addr;
> +
> + addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
> +
> + return dw_pcie_cfg_write(addr + (where & ~0x3), where, size, val);
> +}
> +++ b/drivers/pci/host/pci-keystone.c
> ...
> +static struct platform_driver ks_pcie_driver __refdata = {
Why does this need to be __refdata? There are no other occurrences in
drivers/pci.
> + .probe = ks_pcie_probe,
> + .remove = __exit_p(ks_pcie_remove),
> + .driver = {
> + .name = "keystone-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(ks_pcie_of_match),
> + },
> +};
Bjorn
^ permalink raw reply
* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Brian Norris @ 2014-07-22 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6456081.JRV4vu9CHq@wuerfel>
On Wed, Jul 23, 2014 at 12:24:23AM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 17:33:50 Matt Porter wrote:
> > > > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > > > soon enough, unless Matt/Arnd/Olof object.
> > >
> > > I'll wait for Matt to comment before pulling it, otherwise that sounds
> > > fine.
> >
> > I'm fine with it, but we were asked to have one request for bcm5301x to
> > make life easy for the arm-soc team.
That's all news to me; thanks for the explanation.
> > If we want each platform to do pull
> > requests directly with arm-soc we should advise Hauke to do the same as
> > well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
> > relatively low as there's a dwindling amount of code of interest in new
> > platform mach directories like ours.
> >
> > I would like to see a consistent path for all BCM platform maintainers.
>
> Ok. Brian, please send the pull request or patches to Matt then.
Sure thing. I'll drop the 'select POWER_RESET_BRCMSTB' and also drop our
git tree from MAINTAINERS. I'll send v9 of the reboot driver separately,
targeted at Sebastian (or else to also defer to Matt's tree).
Thanks,
Brian
^ permalink raw reply
* [PATCH] tty: serial: msm: Add DT based earlycon support
From: Stephen Boyd @ 2014-07-22 22:29 UTC (permalink / raw)
To: linux-arm-kernel
Add support for DT based early console on platforms with the msm
serial hardware.
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
I've tested this on top of Rob's arm-fixmap[1] branch and a cherry-pick
of commit 68252424a7c7 (tty: serial: msm: Support big-endian CPUs, 2014-06-30)
and the merge of commit 45e0f0f56843 (tty/serial: pl011: add DT based earlycon
support, 2014-03-27)
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-fixmap
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/msm_serial.c | 72 ++++++++++++++++++++++++++++++++++-------
2 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 26cec64dadd7..903a3277fa60 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1051,6 +1051,7 @@ config SERIAL_MSM_CONSOLE
bool "MSM serial console support"
depends on SERIAL_MSM=y
select SERIAL_CORE_CONSOLE
+ select SERIAL_EARLYCON
config SERIAL_MSM_HS
tristate "MSM UART High Speed: Serial Driver"
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index c549110509bb..d68faa2e7a6c 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -856,22 +856,15 @@ static inline struct uart_port *get_port_from_line(unsigned int line)
}
#ifdef CONFIG_SERIAL_MSM_CONSOLE
-static void msm_console_write(struct console *co, const char *s,
- unsigned int count)
+static void __msm_console_write(struct uart_port *port, const char *s,
+ unsigned int count, bool is_uartdm)
{
int i;
- struct uart_port *port;
- struct msm_port *msm_port;
int num_newlines = 0;
bool replaced = false;
void __iomem *tf;
- BUG_ON(co->index < 0 || co->index >= UART_NR);
-
- port = get_port_from_line(co->index);
- msm_port = UART_TO_MSM(port);
-
- if (msm_port->is_uartdm)
+ if (is_uartdm)
tf = port->membase + UARTDM_TF;
else
tf = port->membase + UART_TF;
@@ -883,7 +876,7 @@ static void msm_console_write(struct console *co, const char *s,
count += num_newlines;
spin_lock(&port->lock);
- if (msm_port->is_uartdm)
+ if (is_uartdm)
reset_dm_count(port, count);
i = 0;
@@ -892,7 +885,7 @@ static void msm_console_write(struct console *co, const char *s,
unsigned int num_chars;
char buf[4] = { 0 };
- if (msm_port->is_uartdm)
+ if (is_uartdm)
num_chars = min(count - i, (unsigned int)sizeof(buf));
else
num_chars = 1;
@@ -921,6 +914,20 @@ static void msm_console_write(struct console *co, const char *s,
spin_unlock(&port->lock);
}
+static void msm_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct uart_port *port;
+ struct msm_port *msm_port;
+
+ BUG_ON(co->index < 0 || co->index >= UART_NR);
+
+ port = get_port_from_line(co->index);
+ msm_port = UART_TO_MSM(port);
+
+ __msm_console_write(port, s, count, msm_port->is_uartdm);
+}
+
static int __init msm_console_setup(struct console *co, char *options)
{
struct uart_port *port;
@@ -963,6 +970,47 @@ static int __init msm_console_setup(struct console *co, char *options)
return uart_set_options(port, co, baud, parity, bits, flow);
}
+static void
+msm_serial_early_write(struct console *con, const char *s, unsigned n)
+{
+ struct earlycon_device *dev = con->data;
+
+ __msm_console_write(&dev->port, s, n, false);
+}
+
+static int __init
+msm_serial_early_console_setup(struct earlycon_device *device, const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->con->write = msm_serial_early_write;
+ return 0;
+}
+OF_EARLYCON_DECLARE(msm_serial, "qcom,msm-uart",
+ msm_serial_early_console_setup);
+
+static void
+msm_serial_early_write_dm(struct console *con, const char *s, unsigned n)
+{
+ struct earlycon_device *dev = con->data;
+
+ __msm_console_write(&dev->port, s, n, true);
+}
+
+static int __init
+msm_serial_early_console_setup_dm(struct earlycon_device *device,
+ const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+
+ device->con->write = msm_serial_early_write_dm;
+ return 0;
+}
+OF_EARLYCON_DECLARE(msm_serial_dm, "qcom,msm-uartdm",
+ msm_serial_early_console_setup_dm);
+
static struct uart_driver msm_uart_driver;
static struct console msm_console = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 0/6] net: mvpp2: Assorted fixes
From: Thomas Petazzoni @ 2014-07-22 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722.131639.1180592286226896307.davem@davemloft.net>
Dear David Miller,
On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
> >> This series does not apply to the 'net' tree at all, please respin
> >> and resubmit.
> >
> > This series applies on net-next.
> >
> > Sorry for not mentioning it,
>
> They are bonafide bug fixes, therefore should be targetted at 'net'.
Except that I believe they are fixes for a driver which itself is in
net-next, i.e scheduled for 3.17.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3] ARM: shmobile: r8a7791: link PCI USB devices to USB PHY
From: Sergei Shtylyov @ 2014-07-22 22:25 UTC (permalink / raw)
To: linux-arm-kernel
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against 'renesas-devel-v3.16-rc5-20140722' tag of Simon Horman's
'renesas.git' repo plus R8A7791/Koelsch/Henninger USB PHY support patches posted
before. The patch requires the USB PHY driver, and USB HCD generic PHY support
(also already posted) in order to work.
Changes in version 3:
- adjusted "phys" properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#1 node to reflect that channel #1 support
was dropped;
- resolved rejects.
arch/arm/boot/dts/r8a7791.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -1030,6 +1030,20 @@
interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb at 0,1 {
+ reg = <0x800 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
+
+ usb at 0,2 {
+ reg = <0x1000 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
};
pci1: pci at ee0d0000 {
@@ -1050,6 +1064,20 @@
interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb at 0,1 {
+ reg = <0x800 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
+
+ usb at 0,2 {
+ reg = <0x1000 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
};
pciec: pcie at fe000000 {
^ permalink raw reply
* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Arnd Bergmann @ 2014-07-22 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722213350.GX2593@beef>
On Tuesday 22 July 2014 17:33:50 Matt Porter wrote:
>
> > > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > > soon enough, unless Matt/Arnd/Olof object.
> >
> > I'll wait for Matt to comment before pulling it, otherwise that sounds
> > fine.
>
> I'm fine with it, but we were asked to have one request for bcm5301x to
> make life easy for the arm-soc team. If we want each platform to do pull
> requests directly with arm-soc we should advise Hauke to do the same as
> well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
> relatively low as there's a dwindling amount of code of interest in new
> platform mach directories like ours.
>
> I would like to see a consistent path for all BCM platform maintainers.
>
Ok. Brian, please send the pull request or patches to Matt then.
Arnd
^ permalink raw reply
* [PATCH v3] ARM: shmobile: r8a7790: link PCI USB devices to USB PHY
From: Sergei Shtylyov @ 2014-07-22 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Describe the PCI USB devices that are behind the PCI bridges, adding necessary
links to the USB PHY device.
Based on the original work by Ben Dooks <ben.dooks@codethink.co.uk>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against 'renesas-devel-v3.16-rc5-20140722' tag of Simon Horman's
'renesas.git' repo plus R8A7790/Lager USB PHY support patches posted before.
The patch requires the USB PHY driver, and USB HCD generic PHY support (also
already posted) in order to work.
Changes in version 3:
- adjusted "phys" properties in the PCI OHCI/EHCI device nodes;
- resolved rejects.
Changes in version 2:
- renamed the PCI OHCI/EHCI device nodes to comply with the PCI binding;
- changed the PHY specifier in the PCI#2 node to reflect that channel #1 support
was dropped;
- resolved rejects, refreshed the patch.
arch/arm/boot/dts/r8a7790.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -999,6 +999,20 @@
interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb at 0,1 {
+ reg = <0x800 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
+
+ usb at 0,2 {
+ reg = <0x1000 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb0 0>;
+ phy-names = "usb";
+ };
};
pci1: pci at ee0b0000 {
@@ -1039,6 +1053,20 @@
interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+
+ usb at 0,1 {
+ reg = <0x800 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
+
+ usb at 0,2 {
+ reg = <0x1000 0 0 0 0>;
+ device_type = "pci";
+ phys = <&usb2 0>;
+ phy-names = "usb";
+ };
};
pciec: pcie at fe000000 {
^ permalink raw reply
* [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend
From: Stephen Boyd @ 2014-07-22 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9B862.5050106@linaro.org>
On 07/18/14 17:14, John Stultz wrote:
> On 07/18/2014 04:24 PM, Stephen Boyd wrote:
>> On 07/18/14 15:42, John Stultz wrote:
>>> If its a regression (and needs -stable backports) it needs to go in via
>>> tip/timers/urgent, and not via the regular merge window.
>>>
>>> Whats the additional risk -stable wise for canceling the timer during
>>> suspend and starting it back up during resume?
>>>
>> I'd say close to zero given that we'd only be making the timer run a
>> little bit later and we have slack in there already. Here's that version.
> Ok, thanks. I'll try to do a closer review it and get it queued. Is
> there anyone who might be able to validate this and provide a Tested-by: ?
>
Maybe someone from Linaro can give a Tested-by? I basically did this:
# grep -A1 'sched_clock' /proc/timer_list && echo mem > /sys/power/state && grep -A1 'sched_clock' /proc/timer_list
and made sure that the expires time was reset.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v3] platform: Make platform_bus device a platform device
From: Greg Kroah-Hartman @ 2014-07-22 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406051719-17354-1-git-send-email-pawel.moll@arm.com>
On Tue, Jul 22, 2014 at 06:55:19PM +0100, Pawel Moll wrote:
> ... describing the root of the device tree, so one can write
> a platform driver initializing the platform.
>
> There has been a lot of references to platform_bus device where
> it didn't make any sense, because simply using NULL as a parent
> will make the device be adopted by the top level anyway.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> Changes since v2:
>
> * replaced references to platform_bus.dev with NULL
> in places where it shouldn't make any difference
How about split this up with just the "change to NULL" changes as one
patch, and the rest as a second one?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ARM: dts: rk3188-radxarock: add GPIO IR receiver node
From: Heiko Stübner @ 2014-07-22 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140714190355.GA16904@gmail.com>
Am Montag, 14. Juli 2014, 21:04:26 schrieb Beniamino Galvani:
> On Sun, Jul 13, 2014 at 02:37:40PM +0200, Heiko St?bner wrote:
> > Am Sonntag, 13. Juli 2014, 14:10:01 schrieb Beniamino Galvani:
> > > This adds a device tree node for the infrared receiver connected to a
> > > GPIO pin on the Radxa Rock.
> > >
> > > Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
> > > ---
> > >
> > > arch/arm/boot/dts/rk3188-radxarock.dts | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
> > > b/arch/arm/boot/dts/rk3188-radxarock.dts index 19d45b4..1d87bcb 100644
> > > --- a/arch/arm/boot/dts/rk3188-radxarock.dts
> > > +++ b/arch/arm/boot/dts/rk3188-radxarock.dts
> > > @@ -23,6 +23,13 @@
> > >
> > > reg = <0x60000000 0x80000000>;
> > >
> > > };
> > >
> > > + ir_recv: ir-receiver {
> > > + compatible = "gpio-ir-receiver";
> > > + gpios = <&gpio0 10 1>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ir_recv_pin>;
> > > + };
> > > +
> >
> > hmm, on second glance, I'm actually not sure if this shouldn't belong in
> > the soc subnode, like the gpio-keys and leds.
>
> (adding devicetree mailing list)
>
> I placed the IR receiver under the root node after looking at what
> other boards do, for example:
>
> imx6dl-hummingboard.dts
> imx6qdl-cubox-i.dtsi
> dove-cubox.dts
>
> On the other hand, if gpio-keys and leds are under the soc node
> probably it makes sense to follow the same rule also for the IR
> receiver.
your way was the right one actually ... using artificial subnodes is not
encouraged at all - see comments I received , so the soc node itself also may
go away.
I'll add the patch to my queue.
Heiko
^ permalink raw reply
* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Matt Porter @ 2014-07-22 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5044348.IEPQPrahyu@wuerfel>
On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> >
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
>
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
>
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> >
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
>
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.
We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:
BROADCOM BCM5301X ARM ARCHICTURE
M: Hauke Mehrtens <hauke@hauke-m.de>
L: linux-arm-kernel at lists.infradead.org
S: Maintained
F: arch/arm/mach-bcm/bcm_5301x.c
F: arch/arm/boot/dts/bcm5301x.dtsi
F: arch/arm/boot/dts/bcm470*
which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.
> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
>
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.
I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.
I would like to see a consistent path for all BCM platform maintainers.
-Matt
^ permalink raw reply
* [PATCH] efi/arm64: efistub: don't abort if base of DRAM is occupied
From: Leif Lindholm @ 2014-07-22 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057330.12484.21.camel@deneb.redhat.com>
On Tue, Jul 22, 2014 at 03:28:50PM -0400, Mark Salter wrote:
> > > It doesn't filter them to keep them around, it filters them to avoid
> > > calling free_bootmem_late() with an invalid address. If there are UEFI
> > > regions below the kernel, we don't want to call memblock_reserve() or
> > > free_bootmem_late() for them.
> >
> > Then why not just flip things around and do like the arm port and only
> > add the blocks we actually want to keep around to begin with?
>
> I'd rather leave it as-is with everything which can be covered by the
> normal kernel mem mapping.
>
> > > > > > (And I do agree with Mark R here - let's not work around bugs that
> > > > > > don't exist yet.)
> > > > > >
> > > > >
> > > > > I'm not sure if they still exist or not, but on Foundation, I saw a
> > > > > crash in SetVirtualAddressMap unless I kept BS regions around.
> > > >
> > > > For the topic of keeping boot services code around:
> > > > I did also see issues with not keeping boot services regions on v7 -
> > > > ages ago. I have not seen it this year, and I _really_ want to see if
> > > > any such issues resurface.
> > >
> > > My view is that a problem has been seen in the past with tianocore for
> > > arm64. There is no harm in delaying the freeing of BS regions.
> >
> > There is a huge harm.
>
> huge? really?
Yes. It is setting a precedent that "we will try to second-guess how
you might code incorrectly and just deal with it - in those few places
where this is possible, and not in others".
> > > The
> > > memory becomes usable for general kernel use at early_initcall time.
> > > This issue has also been seen with x86 firmware and some of those same
> > > vendors will be providing arm64 firmware.
> >
> > This issue has been seen with x86 firmware because in the early days
> > (last year) noone bothered validating anything other than CSM. They no
> > longer have that luxury.
> >
> > The Linux kernel, currently being the most avid tester of existing
> > arm64 UEFI firmware, falling over itself to cater for hypothetical
> > broken implementations pretty much guarantees the situation will end
> > up just as bad as it ever was on x86 - without us even having CSM.
>
> It is hardly falling over itself. And if the problem is hypothetical,
> why is this in the arm32 EFI patches:
>
> +/*
> + * If you need to (temporarily) support buggy firmware, set to 0.
> + */
> +#define DISCARD_BOOT_SERVICES_REGIONS 1
Because in the early days we did indeed have such an issue.
Had we not had this enabled, we never would have spotted it.
Felt useful to have around _and_disabled_ in case we ever run into
anything like it again. Haven't happened for over a year.
> > > The problem isn't reproducible
> > > now, but I'm not sure if there was a bug fix for it or if it just went
> > > underground for some reason. Kernel boot may succeed by chance if some
> > > needed BS memory isn't reused by kernel.
> >
> > And it may succeed by chance anyway.
> > I'm not saying we won't see broken firmware - I'm saying that this is
> > the window we have to try to _help_ people (and ourselves) by letting
> > broken firmware fail - before it happens in the data centre.
>
> In this particular case, we are removing a workaround to a problem
> which has been seen in the past. So we would open a door to allow
> this particular problem to reach the data center.
No, we are removing a workaround to a problem that has possibly been
seen in the past, not sure of the circumstances, not sure if it was a
model cache management bug.
A UEFI implementation that does not keep track of local and global
symbols is just as likely to not update a pointer between runtime
services regions as it is to not stop using boot services regions
after ExitBootServices(). Keeping boot services regions around does
not solve the problem - it slightly reduces the likelihood of it
manifesting.
> > > > So post-3.16 I would quite like to see the
> > > > call to free_boot_services() moved earlier to flush out any such
> > > > issues before we see large-scale deployments.
> > >
> > > You can just get rid of it altogether:
> >
> > Well, clearly, that would not be my preference :)
>
> Why not? There's no point in keeping it if it isn't wanted/needed. Or at
> least make it optional with a #define as in arm32. Anyway, my opinion is
> known and I'm really not that attached to the code. So, if someone wants
> to submit a patch to take it out, I'm not going to make a fuss over it.
I'll try to get that together tomorrow.
I certainly don't mind keeping a #define around (and it might enable
more code sharing arm/arm64).
/
Leif
^ permalink raw reply
* [PATCH v3 3/3] ARM: shmobile: henninger: enable USB PHY
From: Sergei Shtylyov @ 2014-07-22 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407230122.49264.sergei.shtylyov@cogentembedded.com>
Enable USB PHY device for the Henninger board.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- refreshed the patch.
arch/arm/boot/dts/r8a7791-henninger.dts | 4 ++++
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ renesas/arch/arm/boot/dts/r8a7791-henninger.dts
@@ -253,6 +253,10 @@
pinctrl-names = "default";
};
+&usbphy {
+ status = "okay";
+};
+
&pcie_bus_clk {
status = "okay";
};
^ permalink raw reply
* [PATCH v3 2/3] ARM: shmobile: koelsch: enable USB PHY
From: Sergei Shtylyov @ 2014-07-22 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407230122.49264.sergei.shtylyov@cogentembedded.com>
Enable USB PHY device for the Koelsch board.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- refreshed the patch.
Changes in version 2:
- fixed the wrong board name in the changelog;
- refreshed the patch.
arch/arm/boot/dts/r8a7791-koelsch.dts | 4 ++++
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -452,6 +452,10 @@
pinctrl-names = "default";
};
+&usbphy {
+ status = "okay";
+};
+
&pcie_bus_clk {
status = "okay";
};
^ permalink raw reply
* [PATCH v3 1/3] ARM: shmobile: r8a7791: add USB PHY DT support
From: Sergei Shtylyov @ 2014-07-22 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407230122.49264.sergei.shtylyov@cogentembedded.com>
Define the R8A7791 generic part of the USB PHY device node. It is up to the
board file to enable the device.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- changed subnodes of the USB PHY node to be per-channel;
- changed "renesas,phy-select" property to "reg" in the subnodes, and thus added
"#address-cells" and "#size-cells" properties to the parent node;
- moved "#phy-cells" property from the parent node to the subnodes, changing its
value to <1>;
- refreshed the patch.
Changes in version 2:
- added subnodes to the USB PHY node;
- refreshed the patch.
arch/arm/boot/dts/r8a7791.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -550,6 +550,25 @@
status = "disabled";
};
+ usbphy: usb-phy at e6590100 {
+ compatible = "renesas,usb-phy-r8a7791";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
+ clock-names = "usbhs";
+ status = "disabled";
+
+ usb0: usb-channel at 0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel at 2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
^ permalink raw reply
* [PATCH v3 0/3] Add USB PHY device tree support for R8A7791/Koelsch/Henninger board
From: Sergei Shtylyov @ 2014-07-22 21:22 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.16-rc5-20140722' tag. Here we add the USB PHY device tree
support on the R8A7791/Koelsch/Henninger boards. The patchset requires the USB
PHY driver (just re-posted) in order to work.
[1/3] ARM: shmobile: r8a7791: add USB PHY DT support
[2/3] ARM: shmobile: koelsch: enable USB PHY
[3/3] ARM: shmobile: henninger: enable USB PHY
WBR, Sergei
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: first set of hwmod data patches for v3.17
From: Paul Walmsley @ 2014-07-22 21:21 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-hwmod-a
for you to fetch changes up to c913c8a15a02e91c1f0302d68bebf66838a9689d:
ARM: DRA7: hwmod: Add data for RTC (2014-07-22 14:35:06 -0600)
- ----------------------------------------------------------------
OMAP hwmod data additions for v3.17. Most of these are DRA7xx-related,
although one patch adds DSS hwmods for AM43xx.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/hwmod-a-v3.17/20140722143514/
- ----------------------------------------------------------------
Kishon Vijay Abraham I (2):
arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Lokesh Vutla (1):
ARM: DRA7: hwmod: Add data for RTC
Mugunthan V N (1):
arm: dra7xx: Add hwmod data for MDIO and CPSW
Roger Quadros (1):
ARM: DRA7: hwmod: Add OCP2SCP3 module
Sathya Prakash M R (1):
ARM: AM43xx: hwmod: add DSS hwmod data
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/cm2_7xx.h | 4 +
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 ----
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 ++++++++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 260 +++++++++++++++++++++
.../mach-omap2/omap_hwmod_common_ipblock_data.c | 55 +++++
arch/arm/mach-omap2/prcm43xx.h | 1 +
arch/arm/mach-omap2/prm7xx.h | 4 +
8 files changed, 425 insertions(+), 40 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJTztWUAAoJEMePsQ0LvSpLjF4P/0PEGsq8ctRAQNaIKsVNtsDg
2plzao0Zk0hJjwTQ1HfcrGOiaMRwBpulmvb/hkFu4y7GDBiY2WEJn8d6qHDzbzLJ
2XJxfY69wtrQBs5SG587xNJSmDVoZXKZRbghM0fqJi3ip41bge5HtRD19VXVN5Rj
KZbKZVHWxtyVyZD1Lzl5lTufBgIgLG3nJUrkpIR5nPa0R9k2KtJMeFs88U578Nfs
XT6rQwKyFULqXCYoOOE1Kl2Wmo9mdeVEByx6GYUf0Qz5KES+3+2hiCBsc4FylVSO
tW695bfMgOQ186UZXSYxnQ2pDU/D1meVQ2IQVvlKyG7q+BPslWOgoeFgr1yVZkCz
wRPILUn6G6JRyJ/cCN8nYfrTnFXmV6Ve+Tb2BroHHkiJLPuxNEenFHkVHDaZgwYK
1zDoi1QAVUfy9cnic5yv2/Wd+5rxWwW2V9RCoAU4CT/sRrbH+kqMD1kR0U/Gr06k
L9nowkGwvTUO6aKtUjdsCRXKlThZLcjZcj+yGbDaF7V9UhGS1ys5bTgIXqGU8CDT
ZNg17MpslWTfL2NG6WFkSjU7DO2H8oO3D+o6pETSN6+h2SRkfLhxTjkILm6wSQVQ
HFgPE0fKNLWCRZZk8klAOiG6S4GlxK9S7lDAbVEgr4ivTShdH1p0EsjqDRu+ckPX
AJ8zX9YSxfEqcW/f08LX
=I+wx
-----END PGP SIGNATURE-----
^ 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