* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Shawn Guo @ 2014-07-22 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407220700.49046.marex@denx.de>
On Tue, Jul 22, 2014 at 07:00:48AM +0200, Marek Vasut wrote:
> On Tuesday, July 22, 2014 at 05:03:38 AM, Shawn Guo wrote:
> > On Tue, Jul 22, 2014 at 04:10:26AM +0200, Marek Vasut wrote:
> > > On Monday, March 24, 2014 at 02:49:38 AM, Shawn Guo wrote:
> > > > On Tue, Mar 18, 2014 at 01:37:09AM +0100, Marek Vasut wrote:
> > > > > On Friday, February 28, 2014 at 12:58:41 PM, Marek Vasut wrote:
> > > > > > Add alias for FEC ethernet on i.MX to allow bootloaders (like
> > > > > > U-Boot) patch-in the MAC address for FEC using this alias.
> > > > > >
> > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > >
> > > > > Bump ?
> > > >
> > > > Sorry. I had actually applied the patch but forgot replying.
> > >
> > > Hello Shawn,
> > >
> > > I'd like to apply this patch for 3.14-stable , are you OK with this
> > > please ? Shall I submit it ?
> >
> > I do not see why this is a stable material. But you do not need my
> > approval to send patch for stable kernel. The person you need to
> > convince is Greg.
>
> Without this patch, you will not get a mac address patched into the DT by the
> bootloader. Therefore, your device will use a random mac address on the network
> which is different on every boot. This is not a good thing, don't you agree?
I agree this is not a good thing. But it's neither a regression nor a
critical issue as defined by stable_kernel_rules.txt.
Shawn
^ permalink raw reply
* [PATCH v4] pcie: Add Xilinx PCIe Host Bridge IP driver
From: Srikanth Thokala @ 2014-07-22 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140716173824.GA24357@google.com>
Hi Bjorn,
On Wed, Jul 16, 2014 at 11:08 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Thu, Jul 03, 2014 at 09:57:34AM +0530, Srikanth Thokala wrote:
>> This is the driver for Xilinx AXI PCIe Host Bridge Soft IP
>>
>> Signed-off-by: Srikanth Thokala <sthokal@xilinx.com>
>> ---
>> Changes in v4:
>> - Regarding the comments to separate ECAM functionality,
>> I have sent a separate patch and it is decided to implement
>> it later. The patch is here,
>> https://lkml.org/lkml/2014/5/18/54
>> - Fixed issue with adding configuration bus resource.
>> - Moved the logic for setting up bus resources to probe() from
>> pcie_setup().
>> - Instead of mapping all the MSI interrupts in the probe, changed
>> to map only when a MSI is requested.
>> - Earlier, the implementation of legacy and MSI interrupts init-
>> is mutually exclusive, now changed to have the legacy interrupts
>> init always and MSI interrupt init based on CONFIG_PCI_MSI flag.
>> - Regarding the MSI generic implementation comment, I will plan to
>> do on top of this driver patch.
>> - Rebased on 3.16-rc2.
>> - Fixed other minor comments.
>> - Thanks Arnd and Bjorn for the review.
>>
>> Changes in v3:
>> - Rebased on v3.15.0-rc1
>> - Added support for interrupt-map DT functionality.
>> - Removed map_irq() wrapper, instead using of_irq_parse_and_map_pci().
>> - Modified resource mapping logic as per the series
>> "PCI: ARM: add support for generic PCI host controller"
>> - Modified devicetree binding documentation to update with interrupt-
>> map properties.
>> - Use devm calls wherever applicable.
>> - Fixed minor comments from Jason
>> - Thanks Jason for the review and suggestions.
>>
>> Changes in v2:
>> - Rebased on v3.14.0-rc8
>> - Removed IP specific DT properties like include-rc, axibar-num etc.,
>> as suggested by Jason and Bjorn, Thanks
>> ---
>> .../devicetree/bindings/pci/xilinx-pcie.txt | 62 ++
>> drivers/pci/host/Kconfig | 7 +
>> drivers/pci/host/Makefile | 1 +
>> drivers/pci/host/pci-xilinx.c | 1027 ++++++++++++++++++++
>> 4 files changed, 1097 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> create mode 100644 drivers/pci/host/pci-xilinx.c
>
> I see I forgot to ask for a MAINTAINERS entry for this driver. Can
> you add one?
There was a discussion on this earlier and Michal mentioned it is not
required as it is
handled by our Xilinx record.
Here is the reply from Michal to the MAINTAINERS update comment,
< Reply from Michal >
> Please also include a MAINTAINERS update for drivers/pci/host/pci-xilinx.c.
This should be handle by our record that's why MAINTAINERS update is
not necessary.
(N: xilinx below)
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
W: http://wiki.xilinx.com
T: git git://git.xilinx.com/linux-xlnx.git
S: Supported
F: arch/arm/mach-zynq/
F: drivers/cpuidle/cpuidle-zynq.c
N: zynq
N: xilinx
F: drivers/clocksource/cadence_ttc_timer.c
F: drivers/mmc/host/sdhci-of-arasan.c
Thanks,
Michal
< Reply from Michal >
>
> I'd also like an ack from Arnd or another devicetree person for the
> binding.
Sure, I will request them.
>
> I have a few minor comments below.
Sure.
>
>> diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> new file mode 100644
>> index 0000000..3e2c88d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> @@ -0,0 +1,62 @@
>> +* Xilinx AXI PCIe Root Port Bridge DT description
>> +
>> +Required properties:
>> +- #address-cells: Address representation for root ports, set to <3>
>> +- #size-cells: Size representation for root ports, set to <2>
>> +- #interrupt-cells: specifies the number of cells needed to encode an
>> + interrupt source. The value must be 1.
>> +- compatible: Should contain "xlnx,axi-pcie-host-1.00.a"
>> +- reg: Should contain AXI PCIe registers location and length
>> +- device_type: must be "pci"
>> +- interrupts: Should contain AXI PCIe interrupt
>> +- interrupt-map-mask,
>> + interrupt-map: standard PCI properties to define the mapping of the
>> + PCI interface to interrupt numbers.
>> +- ranges: ranges for the PCI memory regions (I/O space region is not
>> + supported by hardware)
>> + Please refer to the standard PCI bus binding document for a more
>> + detailed explanation
>> +
>> +Optional properties:
>> +- bus-range: PCI bus numbers covered
>> +
>> +Interrupt controller child node
>> ++++++++++++++++++++++++++++++++
>> +Required properties:
>> +- interrupt-controller: identifies the node as an interrupt controller
>> +- #address-cells: specifies the number of cells needed to encode an
>> + address. The value must be 0.
>> +- #interrupt-cells: specifies the number of cells needed to encode an
>> + interrupt source. The value must be 1.
>> +
>> +NOTE:
>> +The core provides a single interrupt for both INTx/MSI messages. So,
>> +created a interrupt controller node to support 'interrupt-map' DT
>> +functionality. The driver will create an IRQ domain for this map, decode
>> +the four INTx interrupts in ISR and route them to this domain.
>> +
>> +
>> +Example:
>> +++++++++
>> +
>> + pci_express: axi-pcie at 50000000 {
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + #interrupt-cells = <1>;
>> + compatible = "xlnx,axi-pcie-host-1.00.a";
>> + reg = < 0x50000000 0x10000000 >;
>> + device_type = "pci";
>> + interrupts = < 0 52 4 >;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie_intc 1>,
>> + <0 0 0 2 &pcie_intc 2>,
>> + <0 0 0 3 &pcie_intc 3>,
>> + <0 0 0 4 &pcie_intc 4>;
>> + ranges = < 0x02000000 0 0x60000000 0x60000000 0 0x10000000 >;
>> +
>> + pcie_intc: interrupt-controller {
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <1>;
>> + }
>> + };
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 21df477..afedcde 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -46,4 +46,11 @@ 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_XILINX
>> + bool "Xilinx AXI PCIe host bridge support"
>> + depends on ARCH_ZYNQ
>> + help
>> + Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
>> + Host Bridge driver.
>> +
>> endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 611ba4b..68dfd06 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
>> obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
>> obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
>> obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>> +obj-$(CONFIG_PCI_XILINX) += pci-xilinx.o
>> diff --git a/drivers/pci/host/pci-xilinx.c b/drivers/pci/host/pci-xilinx.c
>> new file mode 100644
>> index 0000000..57d59e7
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xilinx.c
>> @@ -0,0 +1,1027 @@
>> +/*
>> + * PCIe host controller driver for Xilinx AXI PCIe Bridge
>> + *
>> + * Copyright (c) 2012 - 2014 Xilinx, Inc.
>> + *
>> + * Based on the Tegra PCIe driver
>> + *
>> + * Bits taken from Synopsys Designware Host controller driver and
>> + * ARM PCI Host generic driver.
>> + *
>> + * This program is free software: you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation, either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include <linux/interrupt.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/msi.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/pci.h>
>> +#include <linux/platform_device.h>
>> +
>> +/* Register definitions */
>> +#define XILINX_PCIE_REG_VSECC 0x00000128
>> +#define XILINX_PCIE_REG_VSECH 0x0000012c
>> +#define XILINX_PCIE_REG_BIR 0x00000130
>> +#define XILINX_PCIE_REG_BSCR 0x00000134
>> +#define XILINX_PCIE_REG_IDR 0x00000138
>> +#define XILINX_PCIE_REG_IMR 0x0000013c
>> +#define XILINX_PCIE_REG_BLR 0x00000140
>> +#define XILINX_PCIE_REG_PSCR 0x00000144
>> +#define XILINX_PCIE_REG_RPSC 0x00000148
>> +#define XILINX_PCIE_REG_MSIBASE1 0x0000014c
>> +#define XILINX_PCIE_REG_MSIBASE2 0x00000150
>> +#define XILINX_PCIE_REG_RPEFR 0x00000154
>> +#define XILINX_PCIE_REG_RPIFR1 0x00000158
>> +#define XILINX_PCIE_REG_RPIFR2 0x0000015c
>> +#define XILINX_PCIE_REG_VSECC2 0x00000200
>> +#define XILINX_PCIE_REG_VSECH2 0x00000204
>> +
>> +/* Interrupt registers definitions */
>> +#define XILINX_PCIE_INTR_LINK_DOWN BIT(0)
>> +#define XILINX_PCIE_INTR_ECRC_ERR BIT(1)
>> +#define XILINX_PCIE_INTR_STR_ERR BIT(2)
>> +#define XILINX_PCIE_INTR_HOT_RESET BIT(3)
>> +#define XILINX_PCIE_INTR_CFG_COMPL GENMASK(7, 5)
>> +#define XILINX_PCIE_INTR_CFG_TIMEOUT BIT(8)
>> +#define XILINX_PCIE_INTR_CORRECTABLE BIT(9)
>> +#define XILINX_PCIE_INTR_NONFATAL BIT(10)
>> +#define XILINX_PCIE_INTR_FATAL BIT(11)
>> +#define XILINX_PCIE_INTR_INTX BIT(16)
>> +#define XILINX_PCIE_INTR_MSI BIT(17)
>> +#define XILINX_PCIE_INTR_SLV_UNSUPP BIT(20)
>> +#define XILINX_PCIE_INTR_SLV_UNEXP BIT(21)
>> +#define XILINX_PCIE_INTR_SLV_COMPL BIT(22)
>> +#define XILINX_PCIE_INTR_SLV_ERRP BIT(23)
>> +#define XILINX_PCIE_INTR_SLV_CMPABT BIT(24)
>> +#define XILINX_PCIE_INTR_SLV_ILLBUR BIT(25)
>> +#define XILINX_PCIE_INTR_MST_DECERR BIT(26)
>> +#define XILINX_PCIE_INTR_MST_SLVERR BIT(27)
>> +#define XILINX_PCIE_INTR_MST_ERRP BIT(28)
>> +#define XILINX_PCIE_IMR_ALL_MASK 0x1FF30FED
>> +#define XILINX_PCIE_IDR_ALL_MASK 0xFFFFFFFF
>> +
>> +/* Root Port Error FIFO Read Register definitions */
>> +#define XILINX_PCIE_RPEFR_ERR_VALID BIT(18)
>> +#define XILINX_PCIE_RPEFR_REQ_ID GENMASK(15, 0)
>> +#define XILINX_PCIE_RPEFR_ALL_MASK 0xFFFFFFFF
>> +
>> +/* Root Port Interrupt FIFO Read Register 1 definitions */
>> +#define XILINX_PCIE_RPIFR1_INTR_VALID BIT(31)
>> +#define XILINX_PCIE_RPIFR1_MSI_INTR BIT(30)
>> +#define XILINX_PCIE_RPIFR1_INTR_ASSRT BIT(29)
>> +#define XILINX_PCIE_RPIFR1_INTR_MASK GENMASK(28, 27)
>> +#define XILINX_PCIE_RPIFR1_MSI_ADR_MASK GENMASK(26, 16)
>> +#define XILINX_PCIE_RPIFR1_ALL_MASK 0xFFFFFFFF
>> +#define XILINX_PCIE_RPIFR1_INTR_SHIFT 27
>> +#define XILINX_PCIE_RPIFR1_MSI_ADR_SHIFT 16
>> +
>> +/* Bridge Info Register definitions */
>> +#define XILINX_PCIE_BIR_ECAM_SZ_MASK GENMASK(18, 16)
>> +#define XILINX_PCIE_BIR_ECAM_SZ_SHIFT 16
>> +
>> +/* Root Port Interrupt FIFO Read Register 2 definitions */
>> +#define XILINX_PCIE_RPIFR2_MSG_DATA GENMASK(15, 0)
>> +
>> +/* Root Port Status/control Register definitions */
>> +#define XILINX_PCIE_REG_RPSC_BEN BIT(0)
>> +
>> +/* Phy Status/Control Register definitions */
>> +#define XILINX_PCIE_REG_PSCR_LNKUP BIT(11)
>> +
>> +/* ECAM definitions */
>> +#define ECAM_BUS_NUM_SHIFT 20
>> +#define ECAM_DEV_NUM_SHIFT 12
>> +
>> +/* PCI Configuration space Bus Number Register definitions */
>> +#define PCI_SECONDARY_BUS_NUM_SHIFT 8
>> +#define PCI_SUBORDINATE_BUS_NUM_SHIFT 16
>> +#define PCI_LATENCY_TIMER_MASK GENMASK(31, 24)
>
> These three #defines aren't used; can you remove them? (If you need
> them someday, you should either try to use generic definitions from
> include/uapi/linux/pci_regs.h, or if they're Xilinx-specific, rename
> them so they look Xilinx-specific rather than generic.
Ok.
>
>> +
>> +/* Number of MSI IRQs */
>> +#define XILINX_NUM_MSI_IRQS 128
>> +
>> +/* Number of Memory Resources */
>> +#define XILINX_MAX_NUM_RESOURCES 3
>> +
>> +/**
>> + * struct xilinx_pcie_port - PCIe port information
>> + * @reg_base: IO Mapped Register Base
>> + * @irq: Interrupt number
>> + * @msi_pages: MSI pages
>> + * @root_busno: Root Bus number
>> + * @link_up: Link status flag
>> + * @dev: Device pointer
>> + * @irq_domain: IRQ domain pointer
>> + * @bus_range: Bus range
>> + * @resources: Bus Resources
>> + */
>> +struct xilinx_pcie_port {
>> + void __iomem *reg_base;
>> + u32 irq;
>> + unsigned long msi_pages;
>> + u8 root_busno;
>> + bool link_up;
>> + struct device *dev;
>> + struct irq_domain *irq_domain;
>> + struct resource bus_range;
>> + struct list_head resources;
>> +};
>> +
>> +static DECLARE_BITMAP(msi_irq_in_use, XILINX_NUM_MSI_IRQS);
>> +
>> +static inline struct xilinx_pcie_port *sys_to_pcie(struct pci_sys_data *sys)
>> +{
>> + return sys->private_data;
>> +}
>> +
>> +static inline u32 pcie_read(struct xilinx_pcie_port *port, u32 reg)
>> +{
>> + return readl(port->reg_base + reg);
>> +}
>> +
>> +static inline void pcie_write(struct xilinx_pcie_port *port,
>> + u32 val, u32 reg)
>> +{
>> + writel(val, port->reg_base + reg);
>> +}
>> +
>> +static inline bool xilinx_pcie_is_link_up(struct xilinx_pcie_port *port)
>
> Bool function names should be statements or properties, not questions,
> since a statement can be true or false but a question cannot. For
> example, in this case, "xilinx_pcie_link_up()" or
> "xilinx_pcie_link_is_up()" would read better.
Ok.
>
>> +{
>> + return (pcie_read(port, XILINX_PCIE_REG_PSCR) &
>> + XILINX_PCIE_REG_PSCR_LNKUP) ? 1 : 0;
>> +}
>> +
>> +/**
>> + * xilinx_pcie_clear_err_interrupts - Clear Error Interrupts
>> + * @port: PCIe port information
>> + */
>> +static inline void
>> +xilinx_pcie_clear_err_interrupts(struct xilinx_pcie_port *port)
>
> Put the signature all on one line. It probably doesn't need to be
> inline (we're making a couple register accesses, so speed isn't a
> concern), and removing that will make it fit.
Ok.
>
>> +{
>> + u32 val = pcie_read(port, XILINX_PCIE_REG_RPEFR);
>> +
>> + if (val & XILINX_PCIE_RPEFR_ERR_VALID) {
>> + dev_dbg(port->dev, "Requester ID %d\n",
>> + val & XILINX_PCIE_RPEFR_REQ_ID);
>> + pcie_write(port, XILINX_PCIE_RPEFR_ALL_MASK,
>> + XILINX_PCIE_REG_RPEFR);
>> + }
>> +}
>> +
>> +/**
>> + * xilinx_pcie_verify_config - Verify configuration
>> + * @bus: PCI Bus structure
>> + * @devfn: device/function
>> + *
>> + * Return: 0 on success and error value for invalid configuration
>> + */
>> +static int xilinx_pcie_verify_config(struct pci_bus *bus,
>> + unsigned int devfn)
>
> "verify_config" is not a great function name because it doesn't give a
> good clue about what the return value is. If you make it boolean and
> name it, e.g., xilinx_pcie_valid_device(), then it's obvious.
Ok.
>
>> +{
>> + struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
>> +
>> + /* Check if link is up when trying to access downstream ports */
>> + if (bus->number != port->root_busno)
>> + if (!xilinx_pcie_is_link_up(port))
>> + return -EINVAL;
>> +
>> + /* Only one device down on each root port */
>> + if (bus->number == port->root_busno && devfn > 0)
>> + return -EINVAL;
>> +
>> + /*
>> + * Do not read more than one device on the bus directly attached
>> + * to RC.
>> + */
>> + if (bus->primary == port->root_busno && devfn > 0)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * xilinx_pcie_get_config_base - Get configuration base
>> + * @bus: PCI Bus structure
>> + * @devfn: Device/function
>> + * @where: Offset from base
>> + *
>> + * Return: Base address of the configuration space needed to be
>> + * accessed.
>> + */
>> +static void __iomem *xilinx_pcie_get_config_base(struct pci_bus *bus,
>> + unsigned int devfn,
>> + int where)
>
> "xilinx_pcie_config_base()" would be sufficient. We use "get" as a
> clue that we're acquiring a reference (obviously not an issue here,
> but I think the "get" in this function name is still a bit redundant.)
Ok.
>
>> +{
>> + struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
>> + int relbus;
>> +
>> + relbus = (bus->number << ECAM_BUS_NUM_SHIFT) |
>> + (devfn << ECAM_DEV_NUM_SHIFT);
>> +
>> + return port->reg_base + relbus + where;
>> +}
>> +
>> +/**
>> + * xilinx_pcie_read_config - Read configuration space
>> + * @bus: PCI Bus structure
>> + * @devfn: Device/function
>> + * @where: Offset from base
>> + * @size: Byte/word/dword
>> + * @val: Value to be read
>> + *
>> + * Return: PCIBIOS_SUCCESSFUL on success
>> + * EINVAL/PCIBIOS_DEVICE_NOT_FOUND/PCIBIOS_BAD_REGISTER_NUMBER
>> + * on failure.
>> + */
>> +static int xilinx_pcie_read_config(struct pci_bus *bus,
>> + unsigned int devfn, int where,
>> + int size, u32 *val)
>> +{
>> + struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
>> + void __iomem *addr;
>> +
>> + if (!port) {
>> + BUG();
>> + return -EINVAL;
>> + }
>
> I don't think you need to test "port" for NULL here. And I don't
> think callers will be prepared for -EINVAL anyway; they'll be
> expecting PCIBIOS_* values.
Ok, I will fix in all the suggested places.
>
>> + if (xilinx_pcie_verify_config(bus, devfn)) {
>> + *val = 0xFFFFFFFF;
>> + return PCIBIOS_DEVICE_NOT_FOUND;
>> + }
<snip>
>> + */
>> +static void xilinx_pcie_add_bus(struct pci_bus *bus)
>> +{
>> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>
> Did you verify that this builds with both CONFIG_PCI_MSI=y and with it
> unset?
Yes, I have tested.
< snip >
>> +{
>> + port->link_up = xilinx_pcie_is_link_up(port);
>> + if (!port->link_up)
>
> I'd use "if (port->link_up)" and reorder the dev_info() to avoid the
> negation (trivial, I know, but why use the negative when the positive
> works just as well?)
Ok.
>
>> + dev_info(port->dev, "PCIe Link is DOWN\n");
>> + else
>> + dev_info(port->dev, "PCIe Link is UP\n");
>> +
>> + /* Disable all interrupts*/
>> + pcie_write(port, ~XILINX_PCIE_IDR_ALL_MASK,
>> + XILINX_PCIE_REG_IMR);
>> +
>> + /* Clear pending interrupts */
>> + pcie_write(port, pcie_read(port, XILINX_PCIE_REG_IDR) &
>> + XILINX_PCIE_IMR_ALL_MASK,
>> + XILINX_PCIE_REG_IDR);
>> +
>> + /* Enable all interrupts*/
>
> Missing space before "*/" (also on "Disable all interrupts" comment).
Ok.
>
>> + pcie_write(port, XILINX_PCIE_IMR_ALL_MASK, XILINX_PCIE_REG_IMR);
>> +
>> + /* Enable the Bridge enable bit */
>> + pcie_write(port, pcie_read(port, XILINX_PCIE_REG_RPSC) |
>> + XILINX_PCIE_REG_RPSC_BEN,
>> + XILINX_PCIE_REG_RPSC);
>> +}
>> +
>> +/**
>> + * xilinx_pcie_setup - Setup memory resources
>> + * @nr: Bus number
>> + * @sys: Per controller structure
>> + *
>> + * Return: '1' on success and error value on failure
>
> Incorrect. No point in a comment that explains obvious code anyway.
> But maybe DocBook requires it, and I guess it's OK then.
>
Ok.
>> + */
>> +static int xilinx_pcie_setup(int nr, struct pci_sys_data *sys)
>> +{
>> + struct xilinx_pcie_port *port = sys_to_pcie(sys);
>> +
>> + list_splice_init(&port->resources, &sys->resources);
>> +
>> + return 1;
>> +}
>> +
>> +/**
>> + * xilinx_pcie_scan_bus - Scan PCIe bus for devices
>> + * @nr: Bus number
>> + * @sys: Per controller structure
>> + *
>> + * Return: Valid Bus pointer on success and NULL on failure
>> + */
>> +static struct pci_bus __init *xilinx_pcie_scan_bus(int nr,
>> + struct pci_sys_data *sys)
>> +{
>> + struct xilinx_pcie_port *port = sys_to_pcie(sys);
>> + struct pci_bus *bus;
>> +
>> + if (port) {
>
> I think this test (and the BUG()) is superfluous. I don't think it's
> possible to get here with sys->private_data == NULL. And if we do,
> we'll take a null pointer fault and get a nice backtrace anyway.
Ok.
>
>> + port->root_busno = sys->busnr;
>> + bus = pci_scan_root_bus(port->dev, sys->busnr, &xilinx_pcie_ops,
>> + sys, &sys->resources);
>> + } else {
>> + bus = NULL;
>> + BUG();
>> + }
< snip >
>> +MODULE_AUTHOR("Xilinx Inc");
>> +MODULE_DESCRIPTION("Xilinx AXI PCIe driver");
>> +MODULE_LICENSE("GPLv2");
>
> I think you want "GPL v2" here (with the space; see
> license_is_gpl_compatible()).
I will fix them in my v5.
Thanks for the review,
Srikanth.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages
From: Dave Airlie @ 2014-07-22 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuJFCQdRuuJ=WQAL65MMoWzPj03evGiXmfQh=2K7+i5Gdg@mail.gmail.com>
On 22 July 2014 14:21, Alexandre Courbot <gnurou@gmail.com> wrote:
> DRM maintainers, could I have a comment about this patch? A bunch of
> Nouveau changes depend on it.
I'm not sure we really have anyone who is in a great position to comment,
my major issue would be its allocate a large chunk of RAM that might
not be needed
in all cases, and if we could avoid that when we don't need it, then
it would be good.
Or maybe we could join some allocations together, but with the Linux
mm subsystem,
who knows maybe separate small allocs have a better hope of success.
Dave.
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Marek Vasut @ 2014-07-22 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722030337.GV8537@dragon>
On Tuesday, July 22, 2014 at 05:03:38 AM, Shawn Guo wrote:
> On Tue, Jul 22, 2014 at 04:10:26AM +0200, Marek Vasut wrote:
> > On Monday, March 24, 2014 at 02:49:38 AM, Shawn Guo wrote:
> > > On Tue, Mar 18, 2014 at 01:37:09AM +0100, Marek Vasut wrote:
> > > > On Friday, February 28, 2014 at 12:58:41 PM, Marek Vasut wrote:
> > > > > Add alias for FEC ethernet on i.MX to allow bootloaders (like
> > > > > U-Boot) patch-in the MAC address for FEC using this alias.
> > > > >
> > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > >
> > > > Bump ?
> > >
> > > Sorry. I had actually applied the patch but forgot replying.
> >
> > Hello Shawn,
> >
> > I'd like to apply this patch for 3.14-stable , are you OK with this
> > please ? Shall I submit it ?
>
> I do not see why this is a stable material. But you do not need my
> approval to send patch for stable kernel. The person you need to
> convince is Greg.
Without this patch, you will not get a mac address patched into the DT by the
bootloader. Therefore, your device will use a random mac address on the network
which is different on every boot. This is not a good thing, don't you agree?
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2] ARM: i.MX6: add more chip revision support
From: Shawn Guo @ 2014-07-22 4:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Jason Liu <r64343@freescale.com>
Add more revision support for the new i.MX6DQ tape-out (TO1.5). This
TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
and TO1.4 are never revealed.
Signed-off-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
Changes since v1:
- Add a note in code for the numbering mismatch between code and
data sheet
- Fix a typo of tape-out in commit log
arch/arm/mach-imx/anatop.c | 13 +++++++++++++
arch/arm/mach-imx/mxc.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 4a40bbb46183..8259a625a920 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -104,6 +104,19 @@ void __init imx_init_revision_from_anatop(void)
case 2:
revision = IMX_CHIP_REVISION_1_2;
break;
+ case 3:
+ revision = IMX_CHIP_REVISION_1_3;
+ break;
+ case 4:
+ revision = IMX_CHIP_REVISION_1_4;
+ break;
+ case 5:
+ /*
+ * i.MX6DQ TO1.5 is defined as Rev 1.3 in Data Sheet, marked
+ * as 'D' in Part Number last character.
+ */
+ revision = IMX_CHIP_REVISION_1_5;
+ break;
default:
revision = IMX_CHIP_REVISION_UNKNOWN;
}
diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
index a39b69ef4301..17a41ca65acf 100644
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -43,6 +43,8 @@
#define IMX_CHIP_REVISION_1_1 0x11
#define IMX_CHIP_REVISION_1_2 0x12
#define IMX_CHIP_REVISION_1_3 0x13
+#define IMX_CHIP_REVISION_1_4 0x14
+#define IMX_CHIP_REVISION_1_5 0x15
#define IMX_CHIP_REVISION_2_0 0x20
#define IMX_CHIP_REVISION_2_1 0x21
#define IMX_CHIP_REVISION_2_2 0x22
--
1.9.1
^ permalink raw reply related
* [PATCH RESEND] drm/ttm: expose CPU address of DMA-allocated pages
From: Alexandre Courbot @ 2014-07-22 4:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405390206-5081-1-git-send-email-acourbot@nvidia.com>
DRM maintainers, could I have a comment about this patch? A bunch of
Nouveau changes depend on it.
Thanks,
Alex.
On Tue, Jul 15, 2014 at 11:10 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Pages allocated using the DMA API have a coherent memory mapping. Make
> this mapping visible to drivers so they can decide to use it instead of
> creating their own redundant one.
>
> This is not a mere optimization: for instance, on ARM it is illegal to
> have several memory mappings to the same memory with different protection.
> The mapping provided by dma_alloc_coherent() and exposed by this patch is
> guaranteed to be safe, but subsequent mappings performed by drivers are
> not. Thus drivers using the DMA page allocator should use this mapping
> instead of creating their own.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> This patch was previously part of a series but I figured it would make more
> sense to send it separately. It is to be used by Nouveau (and hopefully
> other drivers) on ARM.
>
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 ++
> drivers/gpu/drm/ttm/ttm_tt.c | 6 +++++-
> include/drm/ttm/ttm_bo_driver.h | 2 ++
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index fb8259f69839..0301fac5badd 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -847,6 +847,7 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
> if (count) {
> d_page = list_first_entry(&pool->free_list, struct dma_page, page_list);
> ttm->pages[index] = d_page->p;
> + ttm_dma->cpu_address[index] = d_page->vaddr;
> ttm_dma->dma_address[index] = d_page->dma;
> list_move_tail(&d_page->page_list, &ttm_dma->pages_list);
> r = 0;
> @@ -978,6 +979,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev)
> INIT_LIST_HEAD(&ttm_dma->pages_list);
> for (i = 0; i < ttm->num_pages; i++) {
> ttm->pages[i] = NULL;
> + ttm_dma->cpu_address[i] = 0;
> ttm_dma->dma_address[i] = 0;
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 75f319090043..341594ede596 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -58,6 +58,8 @@ static void ttm_dma_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
> ttm->ttm.pages = drm_calloc_large(ttm->ttm.num_pages, sizeof(void*));
> ttm->dma_address = drm_calloc_large(ttm->ttm.num_pages,
> sizeof(*ttm->dma_address));
> + ttm->cpu_address = drm_calloc_large(ttm->ttm.num_pages,
> + sizeof(*ttm->cpu_address));
> }
>
> #ifdef CONFIG_X86
> @@ -228,7 +230,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
>
> INIT_LIST_HEAD(&ttm_dma->pages_list);
> ttm_dma_tt_alloc_page_directory(ttm_dma);
> - if (!ttm->pages || !ttm_dma->dma_address) {
> + if (!ttm->pages || !ttm_dma->dma_address || !ttm_dma->cpu_address) {
> ttm_tt_destroy(ttm);
> pr_err("Failed allocating page table\n");
> return -ENOMEM;
> @@ -243,6 +245,8 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
>
> drm_free_large(ttm->pages);
> ttm->pages = NULL;
> + drm_free_large(ttm_dma->cpu_address);
> + ttm_dma->cpu_address = NULL;
> drm_free_large(ttm_dma->dma_address);
> ttm_dma->dma_address = NULL;
> }
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 202f0a7171e8..1d9f0f1ff52d 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -133,6 +133,7 @@ struct ttm_tt {
> * struct ttm_dma_tt
> *
> * @ttm: Base ttm_tt struct.
> + * @cpu_address: The CPU address of the pages
> * @dma_address: The DMA (bus) addresses of the pages
> * @pages_list: used by some page allocation backend
> *
> @@ -142,6 +143,7 @@ struct ttm_tt {
> */
> struct ttm_dma_tt {
> struct ttm_tt ttm;
> + void **cpu_address;
> dma_addr_t *dma_address;
> struct list_head pages_list;
> };
> --
> 2.0.1
>
^ permalink raw reply
* Fix me in netx-regs.h
From: Nick Krause @ 2014-07-22 4:16 UTC (permalink / raw)
To: linux-arm-kernel
Hey Russell,
I did give thought to our previous conversations and I will still do
fix mes but am going to be more careful
with I submit them. Furthermore it seems #define
NETX_GPIO_COUNTER_CTRL_GPIO_RE is not defined
correctly. As the maintainer what should I define it to?
Cheers Nick
^ permalink raw reply
* [PATCH] cpufreq: tests: Providing cpufreq regression test
From: Sachin Kamat @ 2014-07-22 4:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718135933.0837e094@amdc2363>
Hi Lukasz,
On Fri, Jul 18, 2014 at 5:29 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Sachin,
>
>> Hi Lukasz,
>>
>> I tested this script on 4210 based Origen board.
>> This is the output:
>> ./cpufreq_freq_test.sh
>> CURRENT GOVERNOR: performance
>> SET GOVERNOR: performance
>> ######################################
>> TEST AVAILABLE FREQS
>> ######################################
>> FREQ: 1200000 sleep: invalid number '0.1'
>> [ 5.918347] random: gzip urandom read with 61 bits of entropy
>> available OK
>> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> ######################################
>> TEST FREQS SWITCHING
>> ######################################
>> REFERENCE FREQ: 1200000
>> FREQ: 1200000 ----> FREQ: 1200000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1200000 ----> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1200000 ----> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1200000 ----> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1200000 ----> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> REFERENCE FREQ: 1000000
>> FREQ: 1000000 ----> FREQ: 1200000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1000000 ----> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1000000 ----> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1000000 ----> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 1000000 ----> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> REFERENCE FREQ: 800000
>> FREQ: 800000 ----> FREQ: 1200000 sleep: invalid number '0.1'
>> OK
>> FREQ: 800000 ----> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 800000 ----> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 800000 ----> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 800000 ----> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> REFERENCE FREQ: 500000
>> FREQ: 500000 ----> FREQ: 1200000 sleep: invalid number '0.1'
>> OK
>> FREQ: 500000 ----> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 500000 ----> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 500000 ----> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 500000 ----> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> REFERENCE FREQ: 200000
>> FREQ: 200000 ----> FREQ: 1200000 sleep: invalid number '0.1'
>> OK
>> FREQ: 200000 ----> FREQ: 1000000 sleep: invalid number '0.1'
>> OK
>> FREQ: 200000 ----> FREQ: 800000 sleep: invalid number '0.1'
>> OK
>> FREQ: 200000 ----> FREQ: 500000 sleep: invalid number '0.1'
>> OK
>> FREQ: 200000 ----> FREQ: 200000 sleep: invalid number '0.1'
>> OK
>> ######################################
>> ERRORS: 0
>> ######################################
>>
>> Though it says 0 errors, what does the "invalid number..." signify?
>
> I guess that this message is caused by your default sleep
> implementation.
>
> Could you type 'sleep 0.1' and then 'sleep 1' in your console on the
> target system?
> Is the "invalid number" not present with the second case?
Only with first case (sleep 0.1) I get the "invalid number" message.
sleep 1 seems to be OK.
--
Regards,
Sachin.
^ permalink raw reply
* [PATCH v3 00/13] Add support for Hisilicon SMMU architecture
From: leizhen @ 2014-07-22 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721093951.GC16122@arm.com>
On 2014/7/21 17:39, Will Deacon wrote:
> [re-adding the lists]
>
> On Mon, Jul 21, 2014 at 02:51:48AM +0100, leizhen wrote:
>> Hi, Will
>
> Hello,
>
>> I have sent this patch a week ago. I saw that you and Mitchel Humpherys had
>> sent some patches which will impact my code. I list below:
>> iommu/arm-smmu: remove support for chained SMMUs
>> iommu/arm-smmu: fix some checkpatch issues
>
> There's also all of the development work I'm doing for VFIO and the page-table
> rework that Varun's working on, so these patches are going to be difficult
> to merge if we ever get to that point. I think Mitchel and Olav are also
> busy trying to get their SMMU supported by the driver. Given that they've
> actually bothered to follow the architecture, I don't see why they should
> be messed about by your patches causing conflicts all over the place.
>
>> I can ajust my patch because of above. I known this patch is not follow what
>> you suggested before(fit into arm-smmu.c). But I found when we need to support
>> ARM SMMUv3, maybe we should do like this. I really want to know whether or not
>> you agree the software framework in this patch? Or what do you think about
>> SMMUv3?
>
> The only code I foresee sharing between SMMUv2 and SMMUv3 is the page-table
> creation code. The two architectures are significantly different, so I don't
> think your split really helps us there. For example, you've left the probing
> code in smmu-base.c. Of course, if HiSilicon follow the SMMUv3 spec as well
> they did with SMMUv2, then your point is moot anyway and we may as well go
> home.
>
>>> I tried to merge hisi-smmu driver into arm-smmu.c, but it looks impossible.
>>> The biggest problem is that too many registers are diffrent: the base address,
>>> the field definition, or present only on one side. And if I use #if, hisi-smmu
>>> and arm-smmu can not coexist in one binary file. Almost need 20 #if.
>
> I don't think #ifdefs are necessarily the right way to go. There are IMPDEF
> parts of a compliant SMMU (e.g. power management), so having a new compatible
> string and a set of internal ops which can be overridden by a particular
> implementation wouldn't be the end of the world and would be far less
> invasive.
>
> The problem you have is that your SMMU isn't architecturally compliant, so
> you'll end up having to restructure parts of the driver so you can add
> internal hooks for operations that aren't actually IMPDEF. That's the part
> I'm worried about and we will have to draw the line somewhere, especially
> when other people are trying to work with this code for compliant
> implementations.
>
> So, NAK to your current approach. You need to try something like I said
> above and, if you want to spit the file up, start with the page-table code.
>
> Will
>
> .
>
OK. We have decided to discard current SMMU hardware design, and will
completely follow the SMMUv3 specification.
^ permalink raw reply
* Tegra baseline test results for v3.16-rc6
From: Paul Walmsley @ 2014-07-22 3:45 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v3.16-rc6.
Logs and other details at:
http://nvt.pwsan.com/pub/linux/testlogs/test_v3.16-rc6/20140721180104/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Boot to userspace: multi_v7_defconfig:
Pass: ( 2/ 2): tegra114-dalmore-a04, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 2/ 2): tegra114-dalmore-a04, tegra30-beaver
vmlinux object size
(delta in bytes from test_v3.16-rc5 (1795cd9b3a91d4b5473c97f491d63892442212ab)):
text data bss total kernel
+2289 +376 0 +2665 multi_v7_defconfig
+2341 +408 0 +2749 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v3.16-rc5 (1795cd9b3a91d4b5473c97f491d63892442212ab))
avail rsrvd high freed board kconfig dtb
-8k 8k . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
-8k 8k . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
^ permalink raw reply
* Tegra baseline test results for v3.16-rc5
From: Paul Walmsley @ 2014-07-22 3:45 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v3.16-rc5.
Logs and other details at:
http://nvt.pwsan.com/pub/linux/testlogs/test_v3.16-rc5/20140713143106/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Boot to userspace: multi_v7_defconfig:
Pass: ( 2/ 2): tegra114-dalmore-a04, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 2/ 2): tegra114-dalmore-a04, tegra30-beaver
vmlinux object size
(delta in bytes from test_v3.16-rc4 (cd3de83f147601356395b57a8673e9c5ff1e59d1)):
text data bss total kernel
+5204 -160 0 +5044 multi_v7_defconfig
+560 -8 0 +552 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v3.16-rc4 (cd3de83f147601356395b57a8673e9c5ff1e59d1))
avail rsrvd high freed board kconfig dtb
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
-8k 8k . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
-8k 8k . . tegra30-beaver tegra_defconfig tegra30-beaver
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Vince Hsu @ 2014-07-22 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721090208.GJ8843@ulmo>
On 07/21/2014 05:02 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Jul 21, 2014 at 03:09:29PM +0800, Vince Hsu wrote:
>> On 07/17/2014 07:01 PM, Thierry Reding wrote:
>>>> Old Signed by an unknown key
>>> On Thu, Jul 17, 2014 at 12:01:56PM +0300, Peter De Schrijver wrote:
>>>> On Thu, Jul 17, 2014 at 10:53:08AM +0200, Peter De Schrijver wrote:
>>>>> On Wed, Jul 16, 2014 at 08:57:16PM +0200, Thierry Reding wrote:
>>>>>>> Old Signed by an unknown key
>>>>>> On Wed, Jul 16, 2014 at 05:22:03PM +0200, Arnd Bergmann wrote:
>>>>>>> On Wednesday 16 July 2014 17:14:29 Thierry Reding wrote:
>>>>>>>>> Ok, I'll have a look. I think when this becomes a separate driver, it
>>>>>>>>> should also have its own header file, so maybe you can in the meantime
>>>>>>>>> make it a local header file in mach-tegra until we have found a good
>>>>>>>>> place for it.
>>>>>>>> Why do you think it should be a separate header? We already have a
>>>>>>>> couple in include/linux and I'm not sure it's useful to add even more.
>>>>>>>> If anything I would've thought it made sense to move the content of the
>>>>>>>> other headers into tegra-soc.h.
>>>>>>> I very much dislike the idea of having a per-vendor header file that
>>>>>>> everything gets crammed into. We should try to have proper subsystems
>>>>>>> and generic interfaces for these wherever possible.
>>>>>> I completely agree. However spreading the SoC-specific functions across
>>>>>> multiple header files isn't going to help. If we keep all the per-vendor
>>>>>> APIs in one file it makes it easier to see what could still be moved off
>>>>>> into a separate subsystem.
>>>>>>
>>>>>> Now for PMC specifically, we've investigated converting the powergate
>>>>>> API to power domains. I don't think it will be possible to make that
>>>>>> work. The issue is that there's a defined sequence that needs to be
>>>>>> respected to make sure the device is powered up properly. That sequence
>>>>>> involves the primary clock and reset of the device. It's been proposed
>>>>>> to make these clocks available to the PMC driver so that it can control
>>>>>> them, but then we can't make sure that clocks are really off if they
>>>>>> need to be, since we have two drivers accessing them. The only way I see
>>>>> resets do not have reference counts, so they can be controlled by a
>>>>> powerdomain driver without any problems. For clocks, there would only be
>>>>> a problem for the module clocks if the drivers don't use runtime PM. If
>>>>> we move all drivers to runtime PM, the clock control can move into the
>>>>> powerdomain code and runtime PM will ensure domains are not turned off
>>>>> with active modules.
>>>>>
>>>>>> to make that work reliably is by moving complete control of the
>>>>>> powergate into drivers so that they can make sure clocks and resets are
>>>>>> in the correct states.
>>>>>>
>>>>> Which won't work if you have domains which contain several modules.
>>>> We also need to control the memory clients in the domains using
>>>> MC_CLIENT_HOTRESET_CTRL.
>>> Oh, great. More interdependencies...
>> Some domains depend on others. Can we take this into account?
> I'm not aware of any dependencies. Can you point me at the relevant
> section in the TRM?
As we talked offline yesterday, that's in 5.6.6.7 - 5.6.6.9.
Thanks,
Vince
^ permalink raw reply
* [PATCH 0/6] net: mvpp2: Assorted fixes
From: David Miller @ 2014-07-22 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405961296-5846-1-git-send-email-ezequiel.garcia@free-electrons.com>
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Mon, 21 Jul 2014 13:48:10 -0300
> This patchset contains a set of fixes for issues found while doing some
> more intensive tests on the recently accepted mvpp2 ethernet driver.
>
> David: if we are still in time, we'd like to get the driver fixes merged
> for v3.17-rc1.
>
> For the devicetree changes, it's already too late for that, since Jason
> Cooper has already posted the PRs for v3.17. I'll re-post them when
> v3.17-rc1 is released.
>
> As usual, feedback is welcome.
This series does not apply to the 'net' tree at all, please respin
and resubmit.
^ permalink raw reply
* [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge.
From: Bjorn Helgaas @ 2014-07-22 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140714163922.GH1112@arm.com>
On Mon, Jul 14, 2014 at 10:39 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> ...
> Some more thinking, so I guess we could get away without changing the
> API. On top of Liviu's tree here:
>
> http://linux-arm.org/git?p=linux-ld.git;a=shortlog;h=refs/heads/for-upstream/pci_v8
>
> I reverted "pci: Introduce a domain number for pci_host_bridge.":
>
> http://linux-arm.org/git?p=linux-ld.git;a=commitdiff;h=b44e1c7d6b01c436f6f55662a1414e925161c9ca
>
> and added this patch on top (if you agree with the idea, we can split it
> nicely in arm64, OF and PCI specific parts). What we get is the
> domain_nr in a generic structure and free the sysdata pointer for the
> host controller driver.
>
> ----------------8<----------------------------------------
> From b32606aa3997fc8a45014a64f99e921eef4872b0 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Mon, 14 Jul 2014 17:20:01 +0100
> Subject: [PATCH] pci: Add support for generic domain_nr in pci_bus
>
> This patch adds domain_nr in struct pci_bus if
> CONFIG_PCI_DOMAINS_GENERIC is enabled. The default implementation for
> pci_domain_nr() simply returns bus->domain_nr. For the root bus, the
> core PCI code calls pci_set_domain_nr(bus, parent_device) while the
> child buses inherit the domain nr of the parent bus.
>
> This patch also adds an of_pci_set_domain_nr() implementation which
> parses the device tree for the "pci-domain" property or sets domain_nr
> to the next available value (this function could also be implemented
> entirely in arm64).
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
I like this. It seems like a reasonable step forward. I don't really
like the pci_set_domain_nr() interface because the domain conceptually
exists before the root bus in the domain, but we can deal with that
later.
Tiny nit: please remove the "extern" on the pci_set_domain_nr()
declaration in include/linux/pci.h; we recently removed all the rest
(f39d5b72913e).
I'd really like to see all this stuff in v3.17, but I'm going to be on
vacation for the next three weeks and won't be able to do much until
Aug 11, which is probably going to be in the middle of the merge
window. But maybe the series can be integrated in -next via an ARM
tree or something. If it helps, you can add my
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
for this piece. I don't remember how many other PCI changes are
involved; maybe my ack on this will be enough? Even if we can't get
it in for the merge window, I'm open to trying to merge it after
v3.17-rc1 if it's isolated enough.
Bjorn
> ---
> arch/arm64/Kconfig | 3 +++
> arch/arm64/include/asm/pci.h | 10 ----------
> arch/arm64/kernel/pci.c | 5 +++++
> drivers/of/of_pci.c | 20 +++++++++++++-------
> drivers/pci/probe.c | 11 ++++++++---
> include/linux/of_pci.h | 5 +++++
> include/linux/pci.h | 15 +++++++++++++++
> 7 files changed, 49 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 48ed631adde2..2c884f7453ba 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -160,6 +160,9 @@ config PCI
> config PCI_DOMAINS
> def_bool PCI
>
> +config PCI_DOMAINS_GENERIC
> + def_bool PCI
> +
> config PCI_SYSCALL
> def_bool PCI
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> index 3f7856e92d66..4f091a5135b7 100644
> --- a/arch/arm64/include/asm/pci.h
> +++ b/arch/arm64/include/asm/pci.h
> @@ -29,16 +29,6 @@ struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus);
> extern int isa_dma_bridge_buggy;
>
> #ifdef CONFIG_PCI
> -static inline int pci_domain_nr(struct pci_bus *bus)
> -{
> - struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> -
> - if (bridge)
> - return bridge->domain_nr;
> -
> - return 0;
> -}
> -
> static inline int pci_proc_domain(struct pci_bus *bus)
> {
> return 1;
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 955d6d1cb011..d5ed1afb0d88 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -36,3 +36,8 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> {
> return res->start;
> }
> +
> +void pci_set_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> + of_pci_set_domain_nr(bus, parent);
> +}
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index e81402af5cde..54f06b748bf1 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -175,7 +175,7 @@ static atomic_t domain_nr = ATOMIC_INIT(-1);
> struct pci_host_bridge *
> of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops, void *host_data)
> {
> - int err, domain, busno;
> + int err, busno;
> struct resource *bus_range;
> struct pci_bus *root_bus;
> struct pci_host_bridge *bridge;
> @@ -186,10 +186,6 @@ of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops, void *host
> if (!bus_range)
> return ERR_PTR(-ENOMEM);
>
> - domain = of_alias_get_id(parent->of_node, "pci-domain");
> - if (domain == -ENODEV)
> - domain = atomic_inc_return(&domain_nr);
> -
> err = of_pci_parse_bus_range(parent->of_node, bus_range);
> if (err) {
> dev_info(parent, "No bus range for %s, using default [0-255]\n",
> @@ -207,8 +203,7 @@ of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops, void *host
> goto err_create;
>
> /* then create the root bus */
> - root_bus = pci_create_root_bus_in_domain(parent, domain, busno,
> - ops, host_data, &res);
> + root_bus = pci_create_root_bus(parent, busno, ops, host_data, &res);
> if (IS_ERR(root_bus)) {
> err = PTR_ERR(root_bus);
> goto err_create;
> @@ -225,6 +220,17 @@ err_create:
> }
> EXPORT_SYMBOL_GPL(of_create_pci_host_bridge);
>
> +void of_pci_set_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> + int domain;
> +
> + domain = of_alias_get_id(parent->of_node, "pci-domain");
> + if (domain == -ENODEV)
> + domain = atomic_inc_return(&domain_nr);
> +
> + bus->domain_nr = domain;
> +}
> +
> #ifdef CONFIG_PCI_MSI
>
> static LIST_HEAD(of_pci_msi_chip_list);
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 2c9266237edc..aa30a9e8915d 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -485,7 +485,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
> }
> }
>
> -static struct pci_bus *pci_alloc_bus(void)
> +static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
> {
> struct pci_bus *b;
>
> @@ -500,6 +500,10 @@ static struct pci_bus *pci_alloc_bus(void)
> INIT_LIST_HEAD(&b->resources);
> b->max_bus_speed = PCI_SPEED_UNKNOWN;
> b->cur_bus_speed = PCI_SPEED_UNKNOWN;
> +#ifdef CONFIG_PCI_DOMAINS_GENERIC
> + if (parent)
> + b->domain_nr = parent->domain_nr;
> +#endif
> return b;
> }
>
> @@ -670,7 +674,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
> /*
> * Allocate a new bus, and inherit stuff from the parent..
> */
> - child = pci_alloc_bus();
> + child = pci_alloc_bus(parent);
> if (!child)
> return NULL;
>
> @@ -1767,13 +1771,14 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> bridge->dev.parent = parent;
> bridge->dev.release = pci_release_host_bridge_dev;
>
> - b = pci_alloc_bus();
> + b = pci_alloc_bus(NULL);
> if (!b)
> goto err_out;
>
> b->sysdata = sysdata;
> b->ops = ops;
> b->number = b->busn_res.start = bus;
> + pci_set_domain_nr(b, parent);
> b2 = pci_find_bus(pci_domain_nr(b), bus);
> if (b2) {
> /* If we already got to this bus through a different bridge, ignore it */
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 71e36d091db2..af16ac40c7a2 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -17,6 +17,7 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
> struct pci_host_bridge *of_create_pci_host_bridge(struct device *parent,
> struct pci_ops *ops, void *host_data);
> +void of_pci_set_domain_nr(struct pci_bus *bus, struct device *parent);
>
> #else
> static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
> @@ -53,6 +54,10 @@ of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops,
> {
> return NULL;
> }
> +
> +static inline void of_pci_set_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> +}
> #endif
>
> #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d32b4ed1f411..9113f62c5038 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -457,6 +457,9 @@ struct pci_bus {
> unsigned char primary; /* number of primary bridge */
> unsigned char max_bus_speed; /* enum pci_bus_speed */
> unsigned char cur_bus_speed; /* enum pci_bus_speed */
> +#ifdef CONFIG_PCI_DOMAINS_GENERIC
> + int domain_nr;
> +#endif
>
> char name[48];
>
> @@ -1292,6 +1295,18 @@ static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
> static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
> #endif /* CONFIG_PCI_DOMAINS */
>
> +#ifdef CONFIG_PCI_DOMAINS_GENERIC
> +static inline int pci_domain_nr(struct pci_bus *bus)
> +{
> + return bus->domain_nr;
> +}
> +extern void pci_set_domain_nr(struct pci_bus *bus, struct device *parent);
> +#else
> +static inline void pci_set_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> +}
> +#endif
> +
> /* some architectures require additional setup to direct VGA traffic */
> typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
> unsigned int command_bits, u32 flags);
^ permalink raw reply
* [PATCH v2 1/3] mtd: atmel_nand: add NFC status error check
From: Brian Norris @ 2014-07-22 3:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1402393811-24578-1-git-send-email-josh.wu@atmel.com>
On Tue, Jun 10, 2014 at 05:50:09PM +0800, Josh Wu wrote:
> Add a new function to read the NFC status. Meantime, this function will
> theck if there is any errors in NFC.
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
Fixed up some of the wording and pushed to l2-mtd.git. Thanks!
Brian
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Shawn Guo @ 2014-07-22 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407220410.26694.marex@denx.de>
On Tue, Jul 22, 2014 at 04:10:26AM +0200, Marek Vasut wrote:
> On Monday, March 24, 2014 at 02:49:38 AM, Shawn Guo wrote:
> > On Tue, Mar 18, 2014 at 01:37:09AM +0100, Marek Vasut wrote:
> > > On Friday, February 28, 2014 at 12:58:41 PM, Marek Vasut wrote:
> > > > Add alias for FEC ethernet on i.MX to allow bootloaders (like U-Boot)
> > > > patch-in the MAC address for FEC using this alias.
> > > >
> > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > >
> > > Bump ?
> >
> > Sorry. I had actually applied the patch but forgot replying.
>
> Hello Shawn,
>
> I'd like to apply this patch for 3.14-stable , are you OK with this please ?
> Shall I submit it ?
I do not see why this is a stable material. But you do not need my
approval to send patch for stable kernel. The person you need to
convince is Greg.
Shawn
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-sabresd: add always on pcie regulator
From: Shawn Guo @ 2014-07-22 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405707270-22901-1-git-send-email-l.stach@pengutronix.de>
On Fri, Jul 18, 2014 at 08:14:30PM +0200, Lucas Stach wrote:
> Everything in the PCI specification assumes devices to be
> enumerable on startup. This is only possible if they have
> power available.
>
> A future improvement may allow this regulator to be switched
> off for D3hot and D3cold power states, but there is a lot
> of work to do the pcie host controller side for this to work.
> To keep things simple always enable the regulator for now.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Just curious if this fixes any known PCIe issue?
> ---
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index ec43dde78525..bbbd501098e6 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -54,6 +54,17 @@
> gpio = <&gpio4 10 0>;
> enable-active-high;
> };
> +
> + reg_pcie: regulator at 3 {
> + compatible = "regulator-fixed";
> + reg = <3>;
> + regulator-name = "pcie-supply";
I would start asking to name the regulator in the same way that board
document like schematics names it. In this case, it should be
"MPCIE_3V3".
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 19 0>;
> + regulator-always-on;
> + enable-active-high;
> + };
> };
>
> gpio-keys {
> @@ -323,6 +334,7 @@
> MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000
> MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000
> MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x80000000
> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
No more GPIO setup in hog group, and no more 0x80000000 on pad config.
Please have a dedicate pinctrl entry for it with a proper config value,
and refer to the entry in that reg_pcie node.
Shawn
> >;
> };
>
> --
> 2.0.1
>
^ permalink raw reply
* [PATCH v2] mtd: atmel_nand: make ecc parameters same as definition
From: Brian Norris @ 2014-07-22 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1402559925-20910-1-git-send-email-voice.shen@atmel.com>
On Thu, Jun 12, 2014 at 03:58:45PM +0800, Bo Shen wrote:
> If the ecc parameter is not the same as definition, when the
> mtd core check these parameters, it will give the error result.
>
> Take the following as an example:
>
> Calculate how many bits can be corrected in one page.
> According to the ecc parameters definition,
>
> one page correct bits = (mtd->writesize * ecc->strength) / ecc->size
>
> take the following use case as an example:
> mtd->writesize = 2048 bytes
> ecc->strength = 4 bytes (for 512 bytes)
>
> before this patch, the ecc->size = 2048, so the result is 4 bytes.
> after this patch, the ecc->size = 512, so the result is 16 bytes.
>
> So, align the ecc parameters the same as definition to correct
> this kind of error.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> Acked-by: Josh Wu <josh.wu@atmel.com>
> ---
> Changes in v2:
> - Enhancement the commit message.
Pushed to l2-mtd.git. Thanks!
Brian
^ permalink raw reply
* [PATCH 4/6] chipidea: usbmisc_imx: Add USB support for VF610 SoCs
From: Shawn Guo @ 2014-07-22 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e776c8a6ea0d919edb5e3ce1bf0697b23f09f028.1405702442.git.stefan@agner.ch>
On Fri, Jul 18, 2014 at 07:01:40PM +0200, Stefan Agner wrote:
> @@ -283,6 +307,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
> .compatible = "fsl,imx6q-usbmisc",
> .data = &imx6q_usbmisc_ops,
> },
> + {
> + .compatible = "fsl,vf610-usbmisc",
Update Documentation/devicetree/bindings/usb/usbmisc-imx.txt please.
Shawn
> + .data = &vf610_usbmisc_ops,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
^ permalink raw reply
* [PATCH 2/6] ARM: imx: clk-vf610: add USBPHY clocks
From: Shawn Guo @ 2014-07-22 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fe660ff42e95a286a954c0560b2b7b2aad81634b.1405702442.git.stefan@agner.ch>
On Fri, Jul 18, 2014 at 07:01:38PM +0200, Stefan Agner wrote:
> This commit adds PLL7 which is required for USBPHY1. It also adds
> the USB PHY and USB Controller clocks and the gates to enable them.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Jingchang,
Does the patch look good to you?
Shawn
> ---
> All the main PLLs are currently turned on by boot ROM or boot loader, within
> the kernel we only set the fixed factor. Altough, the function imx_clk_pllv3
> would provide enabling and rate calculation support.
> Because PLL7 is _not_ enabled at boot up, we need enable support. With this,
> we make use of the imx_clk_pllv3 function the first time in clk-vf610. In
> order to be aligned, would it make sense to use the function for all the
> main PLLs? I think support for all types of PLL available in Vybrid is
> already there, altough this need to be verified first.
>
> arch/arm/mach-imx/clk-vf610.c | 12 ++++++++++--
> include/dt-bindings/clock/vf610-clock.h | 5 ++++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
> index 22dc3ee..159c5c4 100644
> --- a/arch/arm/mach-imx/clk-vf610.c
> +++ b/arch/arm/mach-imx/clk-vf610.c
> @@ -58,6 +58,8 @@
> #define PFD_PLL1_BASE (anatop_base + 0x2b0)
> #define PFD_PLL2_BASE (anatop_base + 0x100)
> #define PFD_PLL3_BASE (anatop_base + 0xf0)
> +#define PLL3_CTRL (anatop_base + 0x10)
> +#define PLL7_CTRL (anatop_base + 0x20)
>
> static void __iomem *anatop_base;
> static void __iomem *ccm_base;
> @@ -148,6 +150,9 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
> clk[VF610_CLK_PLL5_MAIN] = imx_clk_fixed_factor("pll5_main", "fast_clk_sel", 125, 6);
> /* pll6: default 960Mhz */
> clk[VF610_CLK_PLL6_MAIN] = imx_clk_fixed_factor("pll6_main", "fast_clk_sel", 40, 1);
> + /* pll7: USB1 PLL at 480MHz */
> + clk[VF610_CLK_PLL7_MAIN] = imx_clk_pllv3(IMX_PLLV3_USB, "pll7_main", "fast_clk_sel", PLL7_CTRL, 0x2);
> +
> clk[VF610_CLK_PLL1_PFD_SEL] = imx_clk_mux("pll1_pfd_sel", CCM_CCSR, 16, 3, pll1_sels, 5);
> clk[VF610_CLK_PLL2_PFD_SEL] = imx_clk_mux("pll2_pfd_sel", CCM_CCSR, 19, 3, pll2_sels, 5);
> clk[VF610_CLK_SYS_SEL] = imx_clk_mux("sys_sel", CCM_CCSR, 0, 3, sys_sels, ARRAY_SIZE(sys_sels));
> @@ -160,8 +165,11 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
> clk[VF610_CLK_PLL4_MAIN_DIV] = clk_register_divider_table(NULL, "pll4_main_div", "pll4_main", 0, CCM_CACRR, 6, 3, 0, pll4_main_div_table, &imx_ccm_lock);
> clk[VF610_CLK_PLL6_MAIN_DIV] = imx_clk_divider("pll6_main_div", "pll6_main", CCM_CACRR, 21, 1);
>
> - clk[VF610_CLK_USBC0] = imx_clk_gate2("usbc0", "pll3_main", CCM_CCGR1, CCM_CCGRx_CGn(4));
> - clk[VF610_CLK_USBC1] = imx_clk_gate2("usbc1", "pll3_main", CCM_CCGR7, CCM_CCGRx_CGn(4));
> + clk[VF610_CLK_USBPHY0] = imx_clk_gate("usbphy0", "pll3_main", PLL3_CTRL, 6);
> + clk[VF610_CLK_USBPHY1] = imx_clk_gate("usbphy1", "pll7_main", PLL7_CTRL, 6);
> +
> + clk[VF610_CLK_USBC0] = imx_clk_gate2("usbc0", "ipg_bus", CCM_CCGR1, CCM_CCGRx_CGn(4));
> + clk[VF610_CLK_USBC1] = imx_clk_gate2("usbc1", "ipg_bus", CCM_CCGR7, CCM_CCGRx_CGn(4));
>
> clk[VF610_CLK_QSPI0_SEL] = imx_clk_mux("qspi0_sel", CCM_CSCMR1, 22, 2, qspi_sels, 4);
> clk[VF610_CLK_QSPI0_EN] = imx_clk_gate("qspi0_en", "qspi0_sel", CCM_CSCDR3, 4);
> diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
> index a916029..6593757 100644
> --- a/include/dt-bindings/clock/vf610-clock.h
> +++ b/include/dt-bindings/clock/vf610-clock.h
> @@ -164,6 +164,9 @@
> #define VF610_CLK_DMAMUX1 151
> #define VF610_CLK_DMAMUX2 152
> #define VF610_CLK_DMAMUX3 153
> -#define VF610_CLK_END 154
> +#define VF610_CLK_PLL7_MAIN 154
> +#define VF610_CLK_USBPHY0 155
> +#define VF610_CLK_USBPHY1 156
> +#define VF610_CLK_END 157
>
> #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> --
> 2.0.1
>
^ permalink raw reply
* [PATCH 1/6] ARM: dts: vf610: add USB PHY and controller
From: Shawn Guo @ 2014-07-22 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <839af70e8acf139bc0f7bbdb4dd68dd146b5d6a8.1405702442.git.stefan@agner.ch>
On Fri, Jul 18, 2014 at 07:01:37PM +0200, Stefan Agner wrote:
> This adds USB PHY and USB controller nodes. Vybrid SoCs have two
> independent USB cores which each supports DR (dual role). However,
> real OTG is not supported since the OTG ID pin is not available.
>
> The PHYs are located within the anadig register range, hence we need
> to change the length of the anadig registers.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> arch/arm/boot/dts/vf610.dtsi | 46 +++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index 6a6190c..f6c3f02 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -25,6 +25,8 @@
> gpio2 = &gpio3;
> gpio3 = &gpio4;
> gpio4 = &gpio5;
> + usbphy0 = &usbphy0;
> + usbphy1 = &usbphy1;
> };
>
> cpus {
> @@ -285,9 +287,25 @@
> gpio-ranges = <&iomuxc 0 128 7>;
> };
>
> - anatop at 40050000 {
> - compatible = "fsl,vf610-anatop";
> - reg = <0x40050000 0x1000>;
> + anatop: anatop at 40050000 {
> + compatible = "fsl,vf610-anatop", "syscon";
> + reg = <0x40050000 0x400>;
> + };
> +
> + usbphy0: usbphy at 40050800 {
> + compatible = "fsl,vf610-usbphy", "fsl,imx23-usbphy";
Since phy driver will match "fsl,vf610-usbphy" anyway, we do not need
"fsl,imx23-usbphy" here.
> + reg = <0x40050800 0x400>;
> + interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_USBPHY0>;
> + fsl,anatop = <&anatop>;
> + };
> +
> + usbphy1: usbphy at 40050c00 {
> + compatible = "fsl,vf610-usbphy", "fsl,imx23-usbphy";
> + reg = <0x40050c00 0x400>;
> + interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_USBPHY1>;
> + fsl,anatop = <&anatop>;
> };
>
> i2c0: i2c at 40066000 {
> @@ -309,6 +327,18 @@
> reg = <0x4006b000 0x1000>;
> #clock-cells = <1>;
> };
> +
> + usbdev0: usb at 40034000 {
> + compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
It doesn't really make any sense to have "fsl,imx6q-usb" here. The
following one should be less confusing.
compatible = "fsl,vf610-usb", "fsl,imx27-usb";
Shawn
> + reg = <0x40034000 0x800>;
> + interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_USBC0>;
> + fsl,usbphy = <&usbphy0>;
> + dr_mode = "peripheral";
> + status = "disabled";
> + };
> +
> +
> };
>
> aips1: aips-bus at 40080000 {
> @@ -371,6 +401,16 @@
> status = "disabled";
> };
>
> + usbh1: usb at 400b4000 {
> + compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
> + reg = <0x400b4000 0x800>;
> + interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_USBC1>;
> + fsl,usbphy = <&usbphy1>;
> + dr_mode = "host";
> + status = "disabled";
> + };
> +
> ftm: ftm at 400b8000 {
> compatible = "fsl,ftm-timer";
> reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
> --
> 2.0.1
>
^ permalink raw reply
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Chanwoo Choi @ 2014-07-22 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4966271.WeZIcVN3eT@wuerfel>
Hi Arnd,
On 07/21/2014 05:58 PM, Arnd Bergmann wrote:
> On Monday 21 July 2014 17:17:44 Chanwoo Choi wrote:
>> On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
>>> On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
>>>> On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
>>>>>
>>>>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>>>>> Exynos3250 has additional special clock for ADC IP.
>>>>>
>>>>> Changes from v6:
>>>>> - Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
>>>>> - Use "sclk" clock name instead of "sclk_adc"
>>>>> - Remove un-necessary macro for exyno-adc-data-v2 structure.
>>>>> - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
>>>>> - Change the number of ADC channels (Exynos3250 has only two channels for ADC)
>>>>>
>>>>
>>>> Looks good to me. Two small requests:
>>>>
>>>> a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx to
>>>> your series, adding your Signed-off-by line in addition to mine? I think
>>>> that one was noncontroversial, while the second patch (2/2) need some more
>>>> work to address the comments and do testing.
>>>
>>> OK, I'll add this patch.
>>> But, I have a question.
>>>
>>> Your patch add following compatible string.
>>> "s3c64100-adc" is right?
>>>
>>> static const struct of_device_id exynos_adc_match[] = {
>>> {
>>> + .compatible = "samsung,s3c64100-adc",
>>> + .data = &exynos_adc_s3c64xx_data,
>>> + }, {
>>
>> Additionally,
>> Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
>> "samsung,s3c6410-adc" compatible string. Should I add this string in exynos-adc.txt?
>>
>> drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
>> Should I add this compatible string on exynos-adc.c?
>>
>> + Must be "samsung,s3c2410-adc" for
>> + the ADC in s3c2410 and compatibles
>> + Must be "samsung,s3c2416-adc" for
>> + the ADC in s3c2416 and compatibles
>> + Must be "samsung,s3c2440-adc" for
>> + the ADC in s3c2440 and compatibles
>> + Must be "samsung,s3c2440-adc" for
>> + the ADC in s3c2440 and compatibles
>> + Must be "samsung,s3c2443-adc" for
>> + the ADC in s3c2443 and compatibles
>>
>
>
> Yes, please.
I send following patchset[1] to support s3c24xx/s3c64xx ADC.
[1] http://www.spinics.net/lists/kernel/msg1791305.html
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCH 5/6] usb: phy: mxs: Add VF610 USB PHY support
From: Shawn Guo @ 2014-07-22 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af194168fadd80c26f94da740f1e61ce6603225a.1405702442.git.stefan@agner.ch>
On Fri, Jul 18, 2014 at 07:01:41PM +0200, Stefan Agner wrote:
> This adds support for the USB PHY in Vybrid VF610. We assume that
> the disconnection without VBUS is also needed for Vybrid. For all
> other flags, the presumption of innocence applies.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/usb/phy/phy-mxs-usb.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index c42bdf0..207946b 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -125,10 +125,15 @@ static const struct mxs_phy_data imx6sl_phy_data = {
> MXS_PHY_NEED_IP_FIX,
> };
>
> +static const struct mxs_phy_data vf610_phy_data = {
> + .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
> +};
> +
> static const struct of_device_id mxs_phy_dt_ids[] = {
> { .compatible = "fsl,imx6sl-usbphy", .data = &imx6sl_phy_data, },
> { .compatible = "fsl,imx6q-usbphy", .data = &imx6q_phy_data, },
> { .compatible = "fsl,imx23-usbphy", .data = &imx23_phy_data, },
> + { .compatible = "fsl,vf610-usbphy", .data = &vf610_phy_data, },
This new compatible string should be documented in
Documentation/devicetree/bindings/usb/mxs-phy.txt.
Shawn
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
> --
> 2.0.1
>
^ permalink raw reply
* [PATCH] ARM: dts: vf610-colibri: split device tree for carrier boards
From: Shawn Guo @ 2014-07-22 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405693518-28293-1-git-send-email-stefan@agner.ch>
On Fri, Jul 18, 2014 at 04:25:18PM +0200, Stefan Agner wrote:
> The Colibri VF61 is a module which needs a carrier board to actually
> run. Different carrier board have different hardware support, hence
> we should reflect this in the device tree files. This patch adds the
> Colibri Evaluation Board, which supports almost all peripherals
> defined in the Colibri standard.
>
> Also align the compatible naming, file splitting and file naming with
> the scheme which was choosen for the Tegra based modules.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: mxs: Fix the RTC compatible prop on M28EVK
From: Marek Vasut @ 2014-07-22 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140221033102.GS3010@S2101-09.ap.freescale.net>
On Friday, February 21, 2014 at 04:31:06 AM, Shawn Guo wrote:
> On Fri, Feb 21, 2014 at 04:14:00AM +0100, Marek Vasut wrote:
> > On Friday, February 21, 2014 at 03:09:16 AM, Shawn Guo wrote:
> > > On Thu, Feb 20, 2014 at 01:31:37PM +0100, Marek Vasut wrote:
> > > > On Friday, January 24, 2014 at 12:23:36 AM, Marek Vasut wrote:
> > > > > The compatible property should be m41t62, not mt41t62, so fix this.
> > > > >
> > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > >
> > > > Bump ?
> > >
> > > Applied. Sorry for the delay.
> >
> > Sure, no problem. Thanks. Shall I submit this for -stable too ?
>
> Oh, at this time which already passes -rc3, I didn't categorize it as a
> critical fix (build error, kernel dumps, system hang) that we should
> send right away for 3.14 and -stable. If you do, you can try to resend
> it to arm-soc folks with my ACK.
Is there anything special to get this into 3.14-stable now or shall I just
follow the general stable submission guidelines ?
Best regards,
Marek Vasut
^ 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