Re: [PATCH v7 26/50] powerpc/powernv: Create PEs at PCI hot plugging time
On 11/05/2015 12:12 AM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those used by SRIOV VFs. The
function is called for once after PCI probing and resources
assignment is completed. So it isn't hotplug friendly.
This creates PEs dynamically by ppc_md.pcibios_setup_bridge(), which
is called on the event during system bootup and PCI hotplug: updating
PCI bridge's windows after resource assignment/reassignment are done.
For partial hotplug case, where not all PCI devices belonging to the
PE are unplugged and plugged again, we just need unbinding/binding
the affected PCI devices with the corresponding PE without creating
new one.
As there is no upstream bridge for root bus that needs to be covered
by PE,
Does "that needs" part relate to a root bus or a an upstream bridge?
we have to create PE for root bus in ppc_md.pcibios_setup_bridge()
before any other PEs can be created, as PE for root bus is the ancestor
to anyone else.
On the other hand, the windows of root port or the upstream port
s/On the other hand, /Also/ ?
of PCIe switch behind root port are extended to be PHB's aperatuses
apertures?
to accommodate the additonal resources needed by newly plugged devices
s/additonal/additional
based on the fact: hotpluggable slot is behind root port or downstream
port of the PCIe switch behind root port. The extension for those
PCI brdiges' windows is done in ppc_md.pcibios_setup_bridge() as
well.
I find it quite difficult to separate "cut-n-paste" changes from functional
changes... May be it is just me.
I would suggest splitting this patch into several. First define the
setup_bridge() callback, then rework pnv_pci_ioda_setup_PEs(),
pnv_pci_ioda_setup_seg(), pnv_pci_ioda_setup_DMA(), and then add "partial
hotplug" handling may be.
Or just get "reviewed-by" from Ben :)
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 240 +-
arch/powerpc/platforms/powernv/pci.h | 1 +
2 files changed, 138 insertions(+), 103 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5e6745f..0bb0056 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -975,6 +975,15 @@ static void pnv_ioda_setup_same_PE(struct pci_bus *bus,
struct pnv_ioda_pe *pe)
pci_name(dev));
continue;
}
+
+ /*
+* In partial hotplug case, the PCI device might be still
+* associated with the PE and needn't be attached to the
+* PE again.
+*/
+ if (pdn->pe_number != IODA_INVALID_PE)
+ continue;
+
pdn->pe_number = pe->pe_number;
if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
pnv_ioda_setup_same_PE(dev->subordinate, pe);
@@ -992,9 +1001,26 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct
pci_bus *bus, bool all)
struct pci_controller *hose = pci_bus_to_host(bus);
struct pnv_phb *phb = hose->private_data;
struct pnv_ioda_pe *pe = NULL;
+ int pe_num;
+
+ /*
+* In partial hotplug case, the PE instance might be still alive.
+* We should reuse it instead of allocating a new one.
+*/
+ pe_num = phb->ioda.pe_rmap[bus->number << 8];
+ if (pe_num != IODA_INVALID_PE) {
+ pe = &phb->ioda.pe_array[pe_num];
+ pnv_ioda_setup_same_PE(bus, pe);
+ return NULL;
+ }
+
+ /* PE number for root bus should have been reserved */
+ if (pci_is_root_bus(bus) &&
+ phb->ioda.root_pe_idx != IODA_INVALID_PE)
+ pe = &phb->ioda.pe_array[phb->ioda.root_pe_idx];
/* Check if PE is determined by M64 */
- if (phb->pick_m64_pe)
+ if (!pe && phb->pick_m64_pe)
pe = phb->pick_m64_pe(bus, all);
/* The PE number isn't pinned by M64 */
@@ -1036,46 +1062,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct
pci_bus *bus, bool all)
return pe;
}
-static void pnv_ioda_setup_PEs(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- pnv_ioda_setup_bus_PE(bus, false);
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->subordinate) {
- if (pci_pcie_type(dev) == PCI_EXP_TYPE_PCI_BRIDGE)
- pnv_ioda_setup_bus_PE(dev->subordinate, true);
- else
- pnv_ioda_setup_PEs(dev->subordinate);
- }
- }
-}
-
-/*
- * Configure PEs so that the downstream PCI buses and devices
- * could have their associated PE#. Unfortunately, we didn't
- * figure out the way to identify the PLX bridge yet. So we
- * simply put the
Re: [PATCH v8 2/8] ARM: dt: Binding documentation for imx25 GCQ
On Monday 16 November 2015 09:12:55 Rob Herring wrote:
> On Mon, Nov 16, 2015 at 01:01:03PM +0100, Markus Pargmann wrote:
> > The documentation describes the bindings for the imx25 GCQ unit which is
> > essentially a generic conversion queue using the imx25 ADC.
> >
> > Signed-off-by: Markus Pargmann
> > ---
> >
> > Notes:
> > Changes in v6:
> > - Changed bindings to use adc-refp and adc-refn. Also a bit of cleanup
> > in the
> >setup routine.
> >
> > Changes in v5:
> > - Fixed locking
> > - Removed module owner
> >
> > .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 58
> > ++
> > 1 file changed, 58 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> > b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
> > new file mode 100644
> > index ..b0866d36a307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>
>
> > +Optional properties for subnodes:
> > + - fsl,adc-refp: specifies the positive reference input as defined in
> > +
> > + - fsl,adc-refn: specifies the negative reference input as defined in
> > +
>
> This header should be part of this commit.
Thanks, will fix that.
Best Regards,
Markus
>
> > +
> > +Example:
> > +
> > + adc: adc@50030800 {
> > + compatible = "fsl,imx25-gcq";
> > + reg = <0x50030800 0x60>;
> > + interrupt-parent = <&tscadc>;
> > + interrupts = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + inaux@5 {
> > + reg = <5>;
> > + fsl,adc-refp = ;
> > + fsl,adc-refn = ;
> > + };
> > + };
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Hi Brian, On 11/13/2015 09:35 PM, Cyrille Pitchen wrote: [...] > > In September I've sent a series of patches to enhance the support of QSPI > flash > memories. Patch 4 was dedicated to the m25p80 driver and set the > rx_nbits / tx_nbits fields of spi_transfer struct(s) in order to configure the > number of I/O lines independently for the opcode, address and data parts. > The work was done for m25p80_read() but also for _read_reg(), _write_reg() and > _write(). > The patched m25p80 driver was then tested with an at25 memory to check non- > regression. > > This series of patches also added 4 enum spi_protocol fields inside struct > spi_nor so the spi-nor framework can tell the (Q)SPI controller driver what > SPI > protocol should be use for erase, read, write and register read/write > operations, depending on the memory manufacturer and the command opcode. > This was done to better support Micron, Spansion and Macronix QSPI memories. > > I have tested the series with Micron QSPI memories and Atmel QSPI controller > and I guess Marek also tested it on his side with Spansion QSPI memories and > another QSPI controller. > > So if it can help other developers to develop QSPI controller drivers, the > series is still available there: > > for the whole series: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371170.html > > for patch 4 (depends on patch 2 for enum spi_protocol): > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371173.html > Should I rebase my next version on top of above patches by Cyrille or shall I post on top of 4.4-rc1? -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
Hi,
On Monday 09 November 2015 10:56 AM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> This patch introduces Exynos UFS PHY driver. This driver
> supports to deal with phy calibration and power control
> according to UFS host driver's behavior.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> Cc: Kishon Vijay Abraham I
> ---
> drivers/phy/Kconfig|7 ++
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos-ufs.c | 241
>
> drivers/phy/phy-exynos-ufs.h | 85 +
> drivers/phy/phy-exynos7-ufs.h | 89 +
> include/linux/phy/phy-exynos-ufs.h | 85 +
> 6 files changed, 508 insertions(+)
> create mode 100644 drivers/phy/phy-exynos-ufs.c
> create mode 100644 drivers/phy/phy-exynos-ufs.h
> create mode 100644 drivers/phy/phy-exynos7-ufs.h
> create mode 100644 include/linux/phy/phy-exynos-ufs.h
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859dd035..7d38a92e0297 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -389,4 +389,11 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>
> +config PHY_EXYNOS_UFS
> + tristate "EXYNOS SoC series UFS PHY driver"
> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
> + select GENERIC_PHY
> + help
> + Support for UFS PHY on Samsung EXYNOS chipsets.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a81aa5..9bec4d1a89e1 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) +=
> phy-armada375-usb2.o
> obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
> obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
> obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o
> obj-$(CONFIG_PHY_PXA_28NM_USB2) += phy-pxa-28nm-usb2.o
> obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
> new file mode 100644
> index ..cb1aeaa3d4eb
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-ufs.c
> @@ -0,0 +1,241 @@
> +/*
> + * UFS PHY driver for Samsung EXYNOS SoC
> + *
> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
> + * Author: Seungwon Jeon
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "phy-exynos-ufs.h"
> +
> +#define for_each_phy_lane(phy, i) \
> + for (i = 0; i < (phy)->lane_cnt; i++)
> +#define for_each_phy_cfg(cfg) \
> + for (; (cfg)->id; (cfg)++)
> +
> +#define PHY_DEF_LANE_CNT 1
> +
> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
> +{
> + enum {LANE_0, LANE_1}; /* lane index */
> +
> + switch (lane) {
> + case LANE_0:
> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
> + break;
> + case LANE_1:
> + if (cfg->id == PHY_TRSV_BLK)
> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
> + break;
> + }
> +}
> +
> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
> +{
> + if (IS_PWR_MODE_ANY(desc))
> + return true;
> +
> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
> + return true;
> +
> + if (COMP_PWR_MODE(required_pwr, desc))
> + return true;
> +
> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
> + COMP_PWR_MODE_SER(required_pwr, desc))
> + return true;
> +
> + return false;
> +}
> +
> +int exynos_ufs_phy_calibrate(struct phy *phy,
> + enum phy_cfg_tag tag, u8 pwr)
This is similar to the first version of your patch without EXPORT_SYMBOL.
I think you have to create a new generic PHY_OPS for calibrate PHY while making
sure that it is as generic as possible (which means calibrate_phy shouldn't
have tag and pwr arguments or a strong justification as to why those arguments
are required in a generic API).
> +{
> + struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
> + struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
> + const struct exynos_ufs_phy_cfg *cfg;
> + int i;
> +
> + if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
> +
Re: [PATCHv2 2/3] staging: ion: Add files for parsing the devicetree
On Mon, Nov 16, 2015 at 04:57:34PM -0800, Laura Abbott wrote:
> + for_each_available_child_of_node(dt_node, node) {
> + struct platform_device *heap_pdev;
> +
> + ret = ion_parse_dt_heap_common(node, &heaps[i], compatible);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + heap_pdev = of_platform_device_create(node, heaps[i].name,
> + &pdev->dev);
We should free these if something fails later in the function.
> + if (!pdev)
> + return ERR_PTR(-ENOMEM);
> + heap_pdev->dev.platform_data = &heaps[i];
> +
> + heaps[i].priv = &heap_pdev->dev;
> +
> + ret = ion_setup_heap_common(pdev, node, &heaps[i]);
> + if (ret)
> + return ERR_PTR(ret);
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 25/50] powerpc/powernv: Reserve PE for root bus
On 11/05/2015 12:12 AM, Gavin Shan wrote:
We're going to reserve/assign PEs when pcibios_setup_bridge() is
called. The function won't be called for root bus as it doesn't
have parent bridge. However, the root bus still needs a PE to be
covered.
This reserves PE numbers that are adjacent to the reserved one
for root buses.
Somewhere in the patchset you need to describe why you need a separate PE
for a root bus and why reserved_pe_idx is not enough for this.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 33 ++-
arch/powerpc/platforms/powernv/pci.h | 1 +
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index eea1c96..5e6745f 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -207,14 +207,14 @@ static int pnv_ioda2_init_m64(struct pnv_phb *phb)
set_bit(phb->ioda.m64_bar_idx, &phb->ioda.m64_bar_alloc);
/*
-* Strip off the segment used by the reserved PE, which is
-* expected to be 0 or last one of PE capabicity.
+* Exclude the segments for reserved and root bus PE, which
+* are first or last two PEs.
*/
r = &phb->hose->mem_resources[1];
if (phb->ioda.reserved_pe_idx == 0)
- r->start += phb->ioda.m64_segsize;
+ r->start += (2 * phb->ioda.m64_segsize);
else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
- r->end -= phb->ioda.m64_segsize;
+ r->end -= (2 * phb->ioda.m64_segsize);
else
pr_warn(" Cannot strip M64 segment for reserved PE#%d\n",
phb->ioda.reserved_pe_idx);
@@ -294,14 +294,14 @@ static int pnv_ioda1_init_m64(struct pnv_phb *phb)
}
/*
-* Exclude the segment used by the reserved PE, which
-* is expected to be 0 or last supported PE#.
+* Exclude the segments for reserved and root bus PE, which
+* are first or last two PEs.
*/
r = &phb->hose->mem_resources[1];
if (phb->ioda.reserved_pe_idx == 0)
- r->start += phb->ioda.m64_segsize;
+ r->start += (2 * phb->ioda.m64_segsize);
else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
- r->end -= phb->ioda.m64_segsize;
+ r->end -= (2 * phb->ioda.m64_segsize);
else
pr_warn(" Cannot cut M64 segment for reserved PE#%d\n",
phb->ioda.reserved_pe_idx);
@@ -3231,7 +3231,22 @@ static void __init pnv_pci_init_ioda_phb(struct
device_node *np,
phb->ioda.dma32_segmap[i] = IODA_INVALID_PE;
}
phb->ioda.pe_array = aux + pemap_off;
- set_bit(phb->ioda.reserved_pe_idx, phb->ioda.pe_alloc);
+
+ /*
+* Choose PE number for root bus, which shouldn't have
+* M64 resources consumed by its child devices. To pick
+* the PE number adjacent to the reserved one if possible.
+*/
+ pnv_ioda_reserve_pe(phb, phb->ioda.reserved_pe_idx);
+ if (phb->ioda.reserved_pe_idx == 0) {
+ phb->ioda.root_pe_idx = 1;
+ pnv_ioda_reserve_pe(phb, phb->ioda.root_pe_idx);
+ } else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1)) {
+ phb->ioda.root_pe_idx = phb->ioda.reserved_pe_idx - 1;
+ pnv_ioda_reserve_pe(phb, phb->ioda.root_pe_idx);
+ } else {
+ phb->ioda.root_pe_idx = IODA_INVALID_PE;
+ }
INIT_LIST_HEAD(&phb->ioda.pe_list);
mutex_init(&phb->ioda.pe_list_mutex);
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index e55ab0e..a8ba97f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -120,6 +120,7 @@ struct pnv_phb {
/* Global bridge info */
unsigned inttotal_pe_num;
unsigned intreserved_pe_idx;
+ unsigned introot_pe_idx;
/* 32-bit MMIO window */
unsigned intm32_size;
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/11] exynos-ufs: add support for Exynos
Hi Alim,
On Monday 16 November 2015 06:31 AM, Alim Akhtar wrote:
> Hi Kishon,
>
> Any more concern on the PHY part of this series?
Sorry for the late reply. Yes, I still have concerns. I'll comment on your
patch.
Thanks
Kishon
>
> Thanks!
>
> On Mon, Nov 9, 2015 at 10:56 AM, Alim Akhtar wrote:
>> This patch-set introduces UFS (Universal Flash Storage) host support
>> for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific
>> driver.
>> And it also contains some quirks handling for Exynos.
>>
>> NOTE: ** This series has a dependency on [4]. **
>>
>> -Changes since v4:
>> * Removed platform specific PHY ops as suggested by Kishon
>> * Rebased on the top of Yaniv Gardi's work [4]
>> * make use of newly introduce ufshcd_{get,set}_variant
>> * other small changes and improvements.
>> * rebased on the top of linux next-20151109
>>
>> -Changes since v3:
>> * Fixed compilation warrings as reported by "Kbuild Test Robot"[5].
>> * Restructure the driver to make it as a platform driver, rebased on top of
>> [4].
>> * Addressed review comments from Arnd Bergmann[5].
>> * Other misc changes and improvements.
>>
>> -Changes since v2:
>> * Addressed review comments from Kishon[1] and Rob Herring [2]
>> * Splited ufs dt binding documetation from ufs driver patch
>>
>> -Changes since v1:
>> * Addressed review comments from Alexey[3] and various review comments from
>> Amit.
>> * Updated email id of Seungwon as his samsung id is void now.
>> * Added ufs platform data
>>
>> [1]-> https://lkml.org/lkml/2015/9/18/29
>> [2]-> https://lkml.org/lkml/2015/9/21/668
>> [3]-> https://lkml.org/lkml/2015/8/23/124
>> [4]-> https://lkml.org/lkml/2015/10/28/271
>> [5]-> https://lkml.org/lkml/2015/10/1/402
>>
>> This patch set is tested on exynos7-espresso board.
>>
>>
>> Alim Akhtar (1):
>> Documentation: samsung-phy: Add dt bindings for UFS
>>
>> Seungwon Jeon (10):
>> phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
>> scsi: ufs: add quirk to contain unconformable utrd field
>> scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
>> scsi: ufs: add quirk not to allow reset of interrupt aggregation
>> scsi: ufs: add quirk to enable host controller without hce
>> scsi: ufs: add specific callback for nexus type
>> scsi: ufs: add add specific callback for hibern8
>> scsi: ufs: make ufshcd_config_pwr_mode of non-static func
>> Documentation: devicetree: ufs: Add DT bindings for exynos UFS host
>> controller
>> scsi: ufs-exynos: add UFS host support for Exynos SoCs
>>
>> .../devicetree/bindings/phy/samsung-phy.txt| 22 +
>> .../devicetree/bindings/ufs/ufs-exynos.txt | 104 ++
>> drivers/phy/Kconfig|7 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos-ufs.c | 241
>> drivers/phy/phy-exynos-ufs.h | 85 ++
>> drivers/phy/phy-exynos7-ufs.h | 89 ++
>> drivers/scsi/ufs/Kconfig | 12 +
>> drivers/scsi/ufs/Makefile |1 +
>> drivers/scsi/ufs/ufs-exynos-hw.c | 131 ++
>> drivers/scsi/ufs/ufs-exynos-hw.h | 43 +
>> drivers/scsi/ufs/ufs-exynos.c | 1304
>>
>> drivers/scsi/ufs/ufs-exynos.h | 247
>> drivers/scsi/ufs/ufshcd.c | 168 ++-
>> drivers/scsi/ufs/ufshcd.h | 54 +
>> drivers/scsi/ufs/ufshci.h | 26 +-
>> drivers/scsi/ufs/unipro.h | 47 +
>> include/linux/phy/phy-exynos-ufs.h | 85 ++
>> 18 files changed, 2647 insertions(+), 20 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
>> create mode 100644 drivers/phy/phy-exynos-ufs.c
>> create mode 100644 drivers/phy/phy-exynos-ufs.h
>> create mode 100644 drivers/phy/phy-exynos7-ufs.h
>> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
>> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
>> create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>> create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>> create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4 02/10] ata: ahci_brcmstb: add quirk for broken ncq
Hi Brian,
> On Nov 17, 2015, at 11:16 AM, Brian Norris
> wrote:
>
> Hi,
>
> On Fri, Oct 30, 2015 at 11:01:16PM +0900, Jaedon Shin wrote:
>> Add quirk for broken ncq. Some chipsets (eg. BCM7349A0, BCM7445A0,
>> BCM7445B0, and all 40nm chipsets including BCM7425) need a workaround
>> disabling NCQ.
>>
>> Signed-off-by: Jaedon Shin
>> ---
>> drivers/ata/ahci_brcmstb.c | 46
>> ++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
>> index 73e3b0b2a3c2..194aeda8f14d 100644
>> --- a/drivers/ata/ahci_brcmstb.c
>> +++ b/drivers/ata/ahci_brcmstb.c
>> @@ -69,10 +69,15 @@
>> (DATA_ENDIAN << DMADESC_ENDIAN_SHIFT) | \
>> (MMIO_ENDIAN << MMIO_ENDIAN_SHIFT))
>>
>> +enum brcm_ahci_quirks {
>> +BRCM_AHCI_QUIRK_NONCQ = BIT(0),
>> +};
>> +
>> struct brcm_ahci_priv {
>> struct device *dev;
>> void __iomem *top_ctrl;
>> u32 port_mask;
>> +u32 quirks;
>> };
>>
>> static const struct ata_port_info ahci_brcm_port_info = {
>> @@ -202,6 +207,42 @@ static u32 brcm_ahci_get_portmask(struct
>> platform_device *pdev,
>> return impl;
>> }
>>
>> +static void brcm_sata_quirks(struct platform_device *pdev,
>> + struct brcm_ahci_priv *priv)
>> +{
>> +if (priv->quirks & BRCM_AHCI_QUIRK_NONCQ) {
>> +void __iomem *ctrl = priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL;
>> +void __iomem *ahci;
>> +struct resource *res;
>> +u32 reg;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> + "ahci");
>> +ahci = devm_ioremap_resource(&pdev->dev, res);
>> +if (IS_ERR(ahci))
>> +return;
>> +
>> +reg = brcm_sata_readreg(ctrl);
>> +reg |= OVERRIDE_HWINIT;
>> +brcm_sata_writereg(reg, ctrl);
>> +
>> +/* Clear out the NCQ bit so the AHCI driver will not issue
>> + * FPDMA/NCQ commands.
>> + */
>> +reg = readl(ahci + HOST_CAP);
>> +reg &= ~HOST_CAP_NCQ;
>> +writel(reg, ahci + HOST_CAP);
>
> You're using readl()/writel() to access the AHCI block, but...
>
>> +
>> +reg = brcm_sata_readreg(ctrl);
>> +reg &= ~OVERRIDE_HWINIT;
>> +brcm_sata_writereg(reg, ctrl);
>> +
>> +devm_iounmap(&pdev->dev, ahci);
>> +devm_release_mem_region(&pdev->dev, res->start,
>> +resource_size(res));
>> +}
>> +}
>> +
>> static void brcm_sata_init(struct brcm_ahci_priv *priv)
>> {
>> /* Configure endianness */
>> @@ -256,6 +297,11 @@ static int brcm_ahci_probe(struct platform_device *pdev)
>> if (IS_ERR(priv->top_ctrl))
>> return PTR_ERR(priv->top_ctrl);
>>
>> +if (of_device_is_compatible(dev->of_node, "brcm,bcm7425-ahci"))
>> +priv->quirks |= BRCM_AHCI_QUIRK_NONCQ;
>> +
>> +brcm_sata_quirks(pdev, priv);
>> +
>> brcm_sata_init(priv);
>
> ...the MMIO endianness is only configured in brcm_sata_init(). You won't
> see this problem on ARM LE, but you should on MIPS BE. Maybe
> brcm_sata_quirks() should be after brcm_sata_init()?
>
Florian already pointed out, the NCQ disabling occurs prior to initializing
the SATA controller endianness in the original BSP. Therefore I think it's
better
to change to brcm_sata_{read,write}reg() instead of {read,write}l() for
HOST_CAP overwriting.
>>
>> priv->port_mask = brcm_ahci_get_portmask(pdev, priv);
>
> Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 23/50] powerpc/powernv: Use PE instead of number during setup and release
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In current implementation, the PEs that are allocated or picked
from the reserved list are identified by PE number. The PE instance
has to be picked according to the PE number eventually. We have
same issue when PE is released.
For pnv_ioda_pick_m64_pe() and pnv_ioda_alloc_pe(), this returns
PE instance so that pnv_ioda_setup_bus_PE() can use the allocated
or reserved PE instance directly. Also, pnv_ioda_setup_bus_PE()
returns the reserved/allocated PE instance to be used in subsequent
patches. On the other hand, pnv_ioda_free_pe() uses PE instance
(not number) as its argument. No logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 81 +--
arch/powerpc/platforms/powernv/pci.h | 2 +-
2 files changed, 46 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 488e0f8..ae82df1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -152,7 +152,7 @@ static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int
pe_no)
pnv_ioda_init_pe(phb, pe_no);
}
-static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
+static struct pnv_ioda_pe *pnv_ioda_alloc_pe(struct pnv_phb *phb)
{
unsigned long pe;
@@ -160,19 +160,20 @@ static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
pe = find_next_zero_bit(phb->ioda.pe_alloc,
phb->ioda.total_pe_num, 0);
if (pe >= phb->ioda.total_pe_num)
- return IODA_INVALID_PE;
+ return NULL;
} while(test_and_set_bit(pe, phb->ioda.pe_alloc));
- pnv_ioda_init_pe(phb, pe);
- return pe;
+ return pnv_ioda_init_pe(phb, pe);
}
-static void pnv_ioda_free_pe(struct pnv_phb *phb, int pe)
+static void pnv_ioda_free_pe(struct pnv_ioda_pe *pe)
{
- WARN_ON(phb->ioda.pe_array[pe].pdev);
+ struct pnv_phb *phb = pe->phb;
+
+ WARN_ON(pe->pdev);
- memset(&phb->ioda.pe_array[pe], 0, sizeof(struct pnv_ioda_pe));
- clear_bit(pe, phb->ioda.pe_alloc);
+ memset(pe, 0, sizeof(struct pnv_ioda_pe));
+ clear_bit(pe->pe_number, phb->ioda.pe_alloc);
}
/* The default M64 BAR is shared by all PEs */
@@ -332,7 +333,7 @@ static void pnv_ioda_reserve_m64_pe(struct pci_bus *bus,
}
}
-static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool all)
+static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool all)
{
struct pci_controller *hose = pci_bus_to_host(bus);
struct pnv_phb *phb = hose->private_data;
@@ -342,7 +343,7 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool
all)
/* Root bus shouldn't use M64 */
if (pci_is_root_bus(bus))
- return IODA_INVALID_PE;
+ return NULL;
/* Allocate bitmap */
size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
@@ -350,7 +351,7 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool
all)
if (!pe_alloc) {
pr_warn("%s: Out of memory !\n",
__func__);
- return IODA_INVALID_PE;
+ return NULL;
}
/* Figure out reserved PE numbers by the PE */
@@ -363,7 +364,7 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool
all)
*/
if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num)) {
kfree(pe_alloc);
- return IODA_INVALID_PE;
+ return NULL;
}
/*
@@ -409,7 +410,7 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool
all)
}
kfree(pe_alloc);
- return master_pe->pe_number;
+ return master_pe;
}
static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb)
@@ -988,28 +989,26 @@ static void pnv_ioda_setup_same_PE(struct pci_bus *bus,
struct pnv_ioda_pe *pe)
* subordinate PCI devices and buses. The second type of PE is normally
* orgiriated by PCIe-to-PCI bridge or PLX switch downstream ports.
*/
-static void pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
+static struct pnv_ioda_pe *pnv_ioda_setup_bus_PE(struct pci_bus *bus, bool all)
{
struct pci_controller *hose = pci_bus_to_host(bus);
struct pnv_phb *phb = hose->private_data;
- struct pnv_ioda_pe *pe;
- int pe_num = IODA_INVALID_PE;
+ struct pnv_ioda_pe *pe = NULL;
/* Check if PE is determined by M64 */
if (phb->pick_m64_pe)
- pe_num = phb->pick_m64_pe(bus, all);
+ pe = phb->pick_m64_pe(bus, all);
/* The PE number isn't pinned by M64 */
- if (pe_num == IODA_INVALID_PE)
- pe_num = pnv_ioda_alloc_pe(phb);
+ if (!pe)
+ pe = pnv_ioda_alloc_pe(phb);
- if (pe_num == IODA_INVALID_PE) {
+ if (!pe)
RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
> On Wed, 11 Nov 2015 12:03:39 +0530
> Bharat Kumar Gogada wrote:
>
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >
> > Signed-off-by: Bharat Kumar Gogada
> > Signed-off-by: Ravi Kiran Gummaluri
> > ---
> > Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> > Moved MSI functionality to separate functions.
> > Changed error return values.
> > ---
> > .../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
> > drivers/pci/host/Kconfig | 16 +-
> > drivers/pci/host/Makefile |1 +
> > drivers/pci/host/pcie-xilinx-nwl.c | 1062
> >
> > 4 files changed, 1144 insertions(+), 3 deletions(-) create mode
> > 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> > create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> >
> > diff --git a/drivers/pci/host/pcie-xilinx-nwl.c
> > b/drivers/pci/host/pcie-xilinx-nwl.c
> > new file mode 100644
> > index 000..8bc509c
> > --- /dev/null
> > +++ b/drivers/pci/host/pcie-xilinx-nwl.c
>
> [...]
>
> > +static struct msi_domain_info nwl_msi_domain_info = {
> > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_MULTI_PCI_MSI),
>
> Given that you claim to support multi-MSI...
>
> [...]
>
> > +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> > + unsigned int nr_irqs, void *args) {
> > + struct nwl_pcie *pcie = domain->host_data;
> > + struct nwl_msi *msi = &pcie->msi;
> > + unsigned long bit;
> > + int i;
> > +
> > + mutex_lock(&msi->lock);
> > + for (i = 0; i < nr_irqs; i++) {
> > + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> > + if (bit < INT_PCI_MSI_NR)
> > + set_bit(bit, msi->used);
> > + else
> > + bit = -ENOSPC;
> > +
> > + if (bit < 0) {
> > + mutex_unlock(&msi->lock);
> > + return bit;
> > + }
> > +
> > + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
> > + virq = virq + 1;
> > + }
>
> I really don't see how this allocator guarantees that all hwirqs are
> contiguous.
> I already mentioned this when reviewing v7, and you still haven't got it
> right.
> So either you allocate *contiguous* hwirqs in an atomic fashion, or you drop
> support for multi-MSI.
>
Yes, I understood now there is no check for allocating contiguous hwirq, I will
address this in the next patch.
Regards,
Bharat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
> On 11/10/2015 10:33 PM, Bharat Kumar Gogada wrote:
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >
> > Signed-off-by: Bharat Kumar Gogada
> > Signed-off-by: Ravi Kiran Gummaluri
> > ---
> > Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> > Moved MSI functionality to separate functions.
> > Changed error return values.
> > +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> > + unsigned int nr_irqs, void *args) {
> > + struct nwl_pcie *pcie = domain->host_data;
> > + struct nwl_msi *msi = &pcie->msi;
> > + unsigned long bit;
> > + int i;
> > +
> > + mutex_lock(&msi->lock);
> > + for (i = 0; i < nr_irqs; i++) {
> > + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> > + if (bit < INT_PCI_MSI_NR)
> > + set_bit(bit, msi->used);
> > + else
> > + bit = -ENOSPC;
>
> Don't you get a compiler warning with this? Note bit is unsigned long and you
> assign -ENOSPC to it.
>
Ya that's a mistake, I will address these in next patch.
> > +
> > + if (bit < 0) {
>
> how can bit < 0 if it's unsigned long?
>
> > + mutex_unlock(&msi->lock);
> > + return bit;
> > + }
> > +
> > + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
>
> nit, but if you do irq_domain_set_info(domain, virq + i, ...
>
> then you can get rid of the code below.
>
> > + virq = virq + 1;
> > + }
> > + mutex_unlock(&msi->lock);
> > + return 0;
> > +}
> > +
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
> On 11/16/2015 7:14 AM, Marc Zyngier wrote:
> > On 11/11/15 06:33, Bharat Kumar Gogada wrote:
> >> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >>
> >> Signed-off-by: Bharat Kumar Gogada
> >> Signed-off-by: Ravi Kiran Gummaluri
> >> ---
> >> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc
> function.
> >> Moved MSI functionality to separate functions.
> >> Changed error return values.
> >> ---
> >> .../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
> >> drivers/pci/host/Kconfig | 16 +-
> >> drivers/pci/host/Makefile |1 +
> >> drivers/pci/host/pcie-xilinx-nwl.c | 1062
>
> >> 4 files changed, 1144 insertions(+), 3 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-
> pcie.txt
> >> create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> >>
> >
> > [...]
> >
> >> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> >> +*bus) {
> >> + struct platform_device *pdev = to_platform_device(pcie->dev);
> >> + struct nwl_msi *msi = &pcie->msi;
> >> + unsigned long base;
> >> + int ret;
> >> +
> >> + mutex_init(&msi->lock);
> >> +
> >> + /* Check for msii_present bit */
> >> + ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & MSII_PRESENT;
> >> + if (!ret) {
> >> + dev_err(pcie->dev, "MSI not present\n");
> >> + ret = -EIO;
> >> + goto err;
> >> + }
> >> +
> >> + /* Enable MSII */
> >> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> >> +MSII_ENABLE, I_MSII_CONTROL);
> >> +
> >> + /* Enable MSII status */
> >> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> >> +MSII_STATUS_ENABLE, I_MSII_CONTROL);
> >> +
> >> + /* setup AFI/FPCI range */
> >> + msi->pages = __get_free_pages(GFP_KERNEL, 0);
> >> + base = virt_to_phys((void *)msi->pages);
> >> + nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> >> + nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
> >
> > BTW, you still haven't answered my question as to why you need to
> > waste a page of memory here, and why putting a device address doesn't
> work.
> >
> > As this is (to the best of my knowledge) the only driver doing so, I'd
> > really like you to explain the rational behind this.
>
> Might not be the only driver doing so after I start sending out patches for
> the
> iProc MSI support (soon), :)
>
> I'm not sure how it works for the Xilinx NWL controller, which Bharat should
> be able to help to explain. But for the iProc MSI controller, there's no
> device
> I/O memory reserved for MSI posted writes in the ASIC.
> Therefore one needs to reserve host memory for these writes.
> >
Our SoC doesn't reserve any memory for MSI, hence we need to assign a memory
space for it out of RAM.
Regards,
Bharat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On 11/17/2015 02:04 PM, Gavin Shan wrote: On Tue, Nov 17, 2015 at 01:37:22PM +1100, Alexey Kardashevskiy wrote: On 11/17/2015 12:42 PM, Gavin Shan wrote: On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote: On 11/05/2015 12:12 AM, Gavin Shan wrote: This enables M64 window on P7IOC, which has been enabled on PHB3. Different from PHB3 where 16 M64 BARs are supported and each of them can be owned by one particular PE# exclusively or divided evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each of them are divided to 8 segments. So every P7IOC PHB supports 128 M64 segments in total. P7IOC has M64DT, which helps mapping one particular M64 segment# to arbitrary PE#. PHB3 doesn't have M64DT, indicating that one M64 segment can only be pinned to the fixed PE#. In order to have same code to support M64 on P7IOC and PHB3, we just provide 128 M64 segments on every P7IOC PHB and each of them is pinned to the fixed PE# by bypassing the function of M64DT. In turn, we just need different phb->init_m64() for P7IOC and PHB3 to support M64. I thought we decided (Ben suggested?) not to push P7IOC code now (or ever) as there is no user for it, has this changed? Remember that the code is mixed for P7IOC/PHB3. It's not harmful to support M64 window on P7IOC, which is much larger than M32. The patchset starts with removing dead code and then adds more dead code. This is not right... Sorry, you mean it's fine to break the code on P7IOC as it's going to be dead. I am saying that the _new_ code which implements PCI hotplug on P7IOC is dead, not the existing P7IOC support which needs to keep working. Reworks you make should keep P7IOC alive but they do not have to add hotplug. imho it is more likely that we drop P7IOC support in the mainline kernel in next 5 years than someone plugs a PCI device to a running P7IOC machine anywhere. But I'm curious when it's going happen, any idea about that? btw please put ioda1/ioda2/p7ioc/etc to the subject line to make it easier to see how much work is there about particular PHB type. You rename quite many functions and I generally want to ask you to group all renaming patches first but it would also make sense to keep them close to (for example) p7ioc-related patches so having more descriptive subject lines may help. Thanks. As the code is mixed for P7IOC/PHB3, I'm not following the line (IODA1/IODA2/p7ioc/phb3) in this patchset. But you should draw the bold line between PHB types imho. Instead, the sequence of patchset is order related to: cod refactoring, IO/M32/M64, DMA, PE allocation/releaseing. Some patches from this patchset are about P7IOC only. All I am asking is to say specifically in the subject line what the patch touches - IODA1/IODA2/p7ioc/phb3/all_of_them. Or I can walk through all of them, pick P7IOC's ones, evaluate the amount of code and entropy they actually add and then ask Ben what we do about it, it will just take longer rather than if you did it. Please give me a clear command what key words you need in the subject in next revision. What I understood is you want to see one of them: powerpc/powernv/ioda1: Yes, looks good. powerpc/powernv/ioda2: Yes. powerpc/powernv/all: Just "powerpc/powernv". -- Alexey -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] cpufreq: arm_big_little: Add support to register a cpufreq cooling device
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal
> Acked-by: Viresh Kumar
Remind me when did I Ack this version of your patch ..
> Cc: Sudeep Holla
> Cc: Eduardo Valentin
> ---
> drivers/cpufreq/Kconfig.arm | 2 ++
> drivers/cpufreq/arm_big_little.c | 35 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1582c1c..0e0052e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -6,6 +6,8 @@
> config ARM_BIG_LITTLE_CPUFREQ
> tristate "Generic ARM big LITTLE CPUfreq driver"
> depends on (ARM_CPU_TOPOLOGY || ARM64) && HAVE_CLK
> + # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot
> be =y
> + depends on !CPU_THERMAL || THERMAL
> select PM_OPP
> help
> This enables the Generic CPUfreq driver for ARM big.LITTLE
> platforms.
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index c5d256c..60d09c0 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -55,6 +56,7 @@ static bool bL_switching_enabled;
> #define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 :
> freq)
> #define VIRT_FREQ(cluster, freq)((cluster == A7_CLUSTER) ? freq >> 1 :
> freq)
>
> +static struct thermal_cooling_device *cdev[MAX_CLUSTERS];
> static struct cpufreq_arm_bL_ops *arm_bL_ops;
> static struct clk *clk[MAX_CLUSTERS];
> static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
> @@ -493,6 +495,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> static int bL_cpufreq_exit(struct cpufreq_policy *policy)
> {
> struct device *cpu_dev;
> + int domain;
>
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> @@ -501,12 +504,43 @@ static int bL_cpufreq_exit(struct cpufreq_policy
> *policy)
> return -ENODEV;
> }
>
> + domain = topology_physical_package_id(cpu_dev->id);
And this is broken.
Have you tested this for IKS ? That's what the primary use-case of
this driver is.
And yeah, I would like to migrate the bL usecase to cpufreq-dt, now that it can
support multiple clusters.
This is broken, because exit() might get called for a CPU from big
cluster, while
read() was called for a CPU on little cluster.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] devicetree: bindings: Add optional dynamic-power-coefficient property
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal wrote:
> The dynamic power consumption of a device is proportional to the
> square of voltage (V) and the clock frequency (f). It can be expressed as
>
> Pdyn = dynamic-power-coefficient * V^2 * f.
>
> The coefficient represents the running time dynamic power consumption in
> units of mw/MHz/uVolt^2 and can be used in the above formula to
> calculate the dynamic power in mW.
>
> Signed-off-by: Punit Agrawal
> Cc: Rob Herring
> Cc: Mark Rutland
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..6aca64f 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -242,6 +242,23 @@ nodes to be present and contain the properties described
> below.
> Definition: Specifies the syscon node controlling the cpu core
> power domains.
>
> + - dynamic-power-coefficient
> + Usage: optional
> + Value type:
> + Definition: A u32 value that represents the running time
> dynamic
> + power coefficient in units of mW/MHz/uVolt^2. The
> + coefficient can either be calculated from power
> + measurements or derived by analysis.
> +
> + The dynamic power consumption of the CPU is
> + proportional to the square of the Voltage (V) and
> + the clock frequency (f). The coefficient is used
> to
> + calculate the dynamic power as below -
> +
> + Pdyn = dynamic-power-coefficient * V^2 * f
> +
> + where voltage is in uV, frequency is in MHz.
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
Reviewed-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] Dynamic power model from device tree
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal wrote: > Hi, > > This patchset adds support to build a single-coefficient dynamic power > model for a CPU. The model is used by the CPU cooling device to > provide an estimate of power consumption and also translate allocated > power to performance cap. > > Changes from previous posting - > > v3 -> v4: > arm_big_little: Migrated to using static arrays > arm_big_little: Updated Kconfig to support building thermal as module > > Patch 1 extends the CPU nodes binding to provide an optional dynamic > power coefficient which can be used to create a dynamic power model > for the CPUs. This model is used to constrain device power consumption > (using power_allocator governor) when the system is thermally > constrained. > > Patches 2-3 extends the cpufreq-dt and arm_big_little driver to > register cpu cooling devices with the dynamic coefficient when > provided. > > The patches were previously posted at [0][1][2]. Mediatek platform > 8173 builds on these bindings to build the power model. > > If there are no objections, I'd appreciate Acks from device tree > bindings maintainers. You forgot to cc cpufreq maintainers for this and there are good chances that I may completely miss the series some times.. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] dt-bindings: simplefb: Support regulator supply properties
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
.../devicetree/bindings/display/simple-framebuffer.txt | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/2] simplefb: Claim and enable regulators
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai
Acked-by: Mark Brown
---
drivers/video/fbdev/simplefb.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(&pdev->dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void s
[PATCH v5 0/2] simplefb: Add regulator handling support
Hi everyone, This is v5 of the simplefb regulator support series. This series adds regulator claiming and enabling support for simplefb. Hans, I dropped your Reviewed-by tag from patch 2 since v4. Changes since v5: - Rebased onto v4.4-rc1 - Dropped dts patches (merged) Changes since v4: - Fixed inverted logic when testing the property name. - Fixed regulator supply name string copy length off by 1. - Added real world user, MSI Primo 81 dts patches. Changes since v3: - Dropped extra "if" which is always true, leftover from v1. - Updated commit message of patch 1 Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. The binding supports any named regulator supplies under its device node. The driver will look through its properties, and claim any regulators by matching "*-supply", as Mark suggested. I've not done a generic helper in the regulator core yet, instead doing the regulator property handling in the simplefb code for now. Patch 1 adds the regulator properties to the DT binding. Patch 2 adds code to the simplefb driver to claim and enable regulators. Regards ChenYu Chen-Yu Tsai (2): dt-bindings: simplefb: Support regulator supply properties simplefb: Claim and enable regulators .../bindings/display/simple-framebuffer.txt| 13 ++- drivers/video/fbdev/simplefb.c | 120 - 2 files changed, 128 insertions(+), 5 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] misc: eeprom: 93xx46: Add DT binding for Atmel AT93C46D devices.
This commit adds a compatible string to the eeprom_93xx46 devicetree bindings in support of Atmel AT93C46D devices. Signed-off-by: Cory Tusar --- Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt index ba493a8..34a0cc2 100644 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt @@ -1,7 +1,7 @@ EEPROMs (SPI) compatible with Microchip Technology 93xx46 family. Required properties: -- compatible : "eeprom-93xx46" +- compatible : "eeprom-93xx46", "atmel,at93c46d" - data-size : number of data bits per word (either 8 or 16) Optional properties: -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] misc: eeprom: 93xx46: Add quirks to support Atmel AT93C46D device.
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.
This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.
Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2. The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.
Signed-off-by: Cory Tusar
---
drivers/misc/eeprom/eeprom_93xx46.c | 128 ++--
include/linux/eeprom_93xx46.h | 6 ++
2 files changed, 98 insertions(+), 36 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index 1f29d9a..0386b03 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
#define ADDR_ERAL 0x20
#define ADDR_EWEN 0x30
+struct eeprom_93xx46_devtype_data {
+ unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+ .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
};
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+ return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ);
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+ return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH);
+}
+
static ssize_t
eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
{
struct eeprom_93xx46_dev *edev;
struct device *dev;
- struct spi_message m;
- struct spi_transfer t[2];
- int bits, ret;
- u16 cmd_addr;
+ ssize_t ret = 0;
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
- cmd_addr = OP_READ << edev->addrlen;
+ mutex_lock(&edev->lock);
- if (edev->addrlen == 7) {
- cmd_addr |= off & 0x7f;
- bits = 10;
- } else {
- cmd_addr |= (off >> 1) & 0x3f;
- bits = 9;
- }
+ if (edev->pdata->prepare)
+ edev->pdata->prepare(edev);
- dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
- cmd_addr, edev->spi->max_speed_hz);
+ while (count) {
+ struct spi_message m;
+ struct spi_transfer t[2] = { { 0 } };
+ u16 cmd_addr = OP_READ << edev->addrlen;
+ size_t nbytes = count;
+ int bits;
+ int err;
+
+ if (edev->addrlen == 7) {
+ cmd_addr |= off & 0x7f;
+ bits = 10;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 1;
+ } else {
+ cmd_addr |= (off >> 1) & 0x3f;
+ bits = 9;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 2;
+ }
- spi_message_init(&m);
- memset(t, 0, sizeof(t));
+ dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
+ cmd_addr, edev->spi->max_speed_hz);
- t[0].tx_buf = (char *)&cmd_addr;
- t[0].len = 2;
- t[0].bits_per_word = bits;
- spi_message_add_tail(&t[0], &m);
+ spi_message_init(&m);
- t[1].rx_buf = buf;
- t[1].len = count;
- t[1].bits_per_word = 8;
- spi_message_add_tail(&t[1], &m);
+ t[0].tx_buf = (char *)&cmd_addr;
+ t[0].len = 2;
+ t[0].bits_per_word = bits;
+ spi_message_add_tail(&t[0], &m);
- mutex_lock(&edev->lock);
+ t[1].rx_buf = buf;
+ t[1].len = count;
+ t[1].bits_per_word = 8;
+ spi_message_add_tail(&t[1], &m);
- if (edev->pdata->prepare)
- edev->pdata->prepare(edev);
+ err = spi_sync(edev->spi, &m);
+ /* have to wait at least Tcsl ns */
+ ndelay(250);
- ret = spi_sync(edev->spi, &m);
- /* have to wait at least Tcsl ns */
- ndelay(250);
- if (ret) {
- dev_err(&edev->spi->dev, "read %zu bytes at %d: err. %d\n",
- count, (int)off, ret);
+ if (err) {
+ dev_err(&edev->spi->dev, "read %zu bytes at %d: err.
%d\
[PATCH 6/7] misc: eeprom: 93xx46: Add DT binding for a GPIO 'select' line.
This commit documents an additional devicetree binding in the eeprom_93x46 driver allowing a GPIO line to function as a 'select' or 'enable' signal prior to accessing the EEPROM. Signed-off-by: Cory Tusar --- Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt index 34a0cc2..75b16f4 100644 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt @@ -6,6 +6,8 @@ Required properties: Optional properties: - read-only : parameter-less property which disables writes to the EEPROM +- select-gpio : if present, specifies the GPIO that will be asserted prior to + each access to the EEPROM (e.g. for SPI bus multiplexing) Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt apply. In particular, "reg" and "spi-max-frequency" properties must be given. @@ -17,4 +19,5 @@ Example: spi-max-frequency = <100>; spi-cs-high; data-size = <8>; + select-gpio = <&gpio4 4 GPIO_ACTIVE_HIGH>; }; -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] misc: eeprom: 93xx46: Implement eeprom_93xx46 DT bindings.
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.
Signed-off-by: Cory Tusar
---
drivers/misc/eeprom/eeprom_93xx46.c | 62 +
1 file changed, 62 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..1f29d9a 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -294,12 +296,71 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+#ifdef CONFIG_OF
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+ { .compatible = "eeprom-93xx46", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+ struct device_node *np = spi->dev.of_node;
+ struct eeprom_93xx46_platform_data *pd;
+ u32 tmp;
+ int ret;
+
+ if (!of_match_device(eeprom_93xx46_of_table, &spi->dev))
+ return 0;
+
+ pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "data-size", &tmp);
+ if (ret < 0) {
+ dev_err(&spi->dev, "data-size property not found\n");
+ goto error_free;
+ }
+
+ if (tmp == 8) {
+ pd->flags |= EE_ADDR8;
+ } else if (tmp == 16) {
+ pd->flags |= EE_ADDR16;
+ } else {
+ dev_err(&spi->dev, "invalid data-size (%d)\n", tmp);
+ goto error_free;
+ }
+
+ if (of_property_read_bool(np, "read-only"))
+ pd->flags |= EE_READONLY;
+
+ spi->dev.platform_data = pd;
+
+ return 1;
+
+error_free:
+ devm_kfree(&spi->dev, pd);
+ return ret;
+}
+
+#else
+static inline int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+ return 0;
+}
+#endif
+
static int eeprom_93xx46_probe(struct spi_device *spi)
{
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
+ err = eeprom_93xx46_probe_dt(spi);
+ if (err < 0)
+ return err;
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(&spi->dev, "missing platform data\n");
@@ -370,6 +431,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name = "93xx46",
+ .of_match_table = eeprom_93xx46_of_table,
},
.probe = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
--
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] misc: eeprom: 93xx46: Fix 16-bit read and write accesses.
Compatible at93xx46 devices from both Microchip and Atmel expect a
word-based address, regardless of whether the device is strapped for 8-
or 16-bit operation. However, the offset parameter passed in when
reading or writing at a specific location is always specified in terms
of bytes.
This commit fixes 16-bit read and write accesses by shifting the offset
parameter to account for this difference between a byte offset and a
word-based address.
Signed-off-by: Cory Tusar
---
drivers/misc/eeprom/eeprom_93xx46.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index ff63f05..e1bf0a5 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -54,7 +54,7 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
cmd_addr |= off & 0x7f;
bits = 10;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
}
@@ -155,7 +155,7 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
bits = 10;
data_len = 1;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
data_len = 2;
}
--
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] misc: eeprom: 93xx46: Add DT bindings to eeprom_93xx46 driver.
This commit documents bindings to be added to the eeprom_93xx46 driver
which allow device word size and read-only attributes to be specified
via devicetree.
Currently the only supported device is a generic "eeprom-93xx46", which
mirrors the configuration options previously available as a platform
device.
Signed-off-by: Cory Tusar
---
.../devicetree/bindings/misc/eeprom-93xx46.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..ba493a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,20 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : "eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+ 93c46c@0 {
+ compatible = "eeprom-93xx46";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cs-high;
+ data-size = <8>;
+ };
--
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] misc: eeprom: 93xx46: Add support for a GPIO 'select' line.
This commit adds support to the eeprom_93x46 driver allowing a GPIO line
to function as a 'select' or 'enable' signal prior to accessing the
EEPROM.
Signed-off-by: Cory Tusar
---
drivers/misc/eeprom/eeprom_93xx46.c | 26 ++
include/linux/eeprom_93xx46.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index 0386b03..3f41696 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -10,11 +10,14 @@
#include
#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -344,6 +347,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
#ifdef CONFIG_OF
+static void select_assert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);
+}
+
+static void select_deassert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 0);
+}
+
static const struct of_device_id eeprom_93xx46_of_table[] = {
{ .compatible = "eeprom-93xx46", },
{ .compatible = "atmel,at93c46d", .data = &atmel_at93c46d_data, },
@@ -385,6 +402,15 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
if (of_property_read_bool(np, "read-only"))
pd->flags |= EE_READONLY;
+ ret = of_get_named_gpio(np, "select-gpio", 0);
+ if (ret < 0) {
+ pd->select_gpio = -1;
+ } else {
+ pd->select_gpio = ret;
+ pd->prepare = select_assert;
+ pd->finish = select_deassert;
+ }
+
if (of_id->data) {
const struct eeprom_93xx46_devtype_data *data = of_id->data;
diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
index 92fa4c3..aa472c7 100644
--- a/include/linux/eeprom_93xx46.h
+++ b/include/linux/eeprom_93xx46.h
@@ -21,4 +21,5 @@ struct eeprom_93xx46_platform_data {
*/
void (*prepare)(void *);
void (*finish)(void *);
+ unsigned int select_gpio;
};
--
2.4.10
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Devicetree support for misc/eeprom/eeprom_93xx46.
This series of patches adds an initial set of devicetree bindings to the eeprom_93xx46 driver which mirror the configuration options previously available as a platform device. These bindings are then extended to include support for specific Atmel devices in this family and also to support GPIO-based selection of the device (e.g. for use with an SPI bus mux). Additionally, an address aliasing issue with 16-bit read and write accesses in the eeprom_93xx46 driver discovered during testing is fixed. Cory Tusar (7): misc: eeprom: 93xx46: Fix 16-bit read and write accesses. misc: eeprom: 93xx46: Add DT bindings to eeprom_93xx46 driver. misc: eeprom: 93xx46: Implement eeprom_93xx46 DT bindings. misc: eeprom: 93xx46: Add DT binding for Atmel AT93C46D devices. misc: eeprom: 93xx46: Add quirks to support Atmel AT93C46D device. misc: eeprom: 93xx46: Add DT binding for a GPIO 'select' line. misc: eeprom: 93xx46: Add support for a GPIO 'select' line. .../devicetree/bindings/misc/eeprom-93xx46.txt | 23 +++ drivers/misc/eeprom/eeprom_93xx46.c| 216 + include/linux/eeprom_93xx46.h | 7 + 3 files changed, 210 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] clk: rockchip: set an ID for crypto clk
Set an ID for crypto clk, so that it can be called in other part.
Signed-off-by: Zain Wang
Acked-by: Michael Turquette
Tested-by: Heiko Stuebner
---
Changed in v4:
- None
Changed in v3:
- None
Changed in v2:
- None
Changed in v1:
- define SCLK_CRYPTO in rk3288-cru.h
- use SCLK_CRYPTO instead of SRST_CRYPTO
drivers/clk/rockchip/clk-rk3288.c | 2 +-
include/dt-bindings/clock/rk3288-cru.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
- COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+ COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
#define SCLK_USBPHY480M_SRC122
#define SCLK_PVTM_CORE 123
#define SCLK_PVTM_GPU 124
+#define SCLK_CRYPTO125
#define SCLK_MAC 151
#define SCLK_MACREF_OUT152
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] crypto: add crypto accelerator support for rk3288
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc), and the more algorithms and new hash drivers will be added later on. Changed in v4: - modify irq function - add devm_add_action in probe - fix some minor mistakes Changed in v3: - add OF depended in Kconfig - rename some variate - add reset property - remove crypto_p variate Changed in v2: - remove some part about hash - add weak key detection - changed some variate's type Changed in v1: - modify some variate's name - modify some variate's type - modify some return value - remove or modify some print info - use more dev_xxx in probe - modify the prio of cipher - add Kconfig Zain Wang (4): crypto: rockchip/crypto - add DT bindings documentation clk: rockchip: set an ID for crypto clk Crypto: rockchip/crypto - add crypto driver for rk3288 ARM: dts: rockchip: Add Crypto node for rk3288 .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++ arch/arm/boot/dts/rk3288.dtsi | 12 + drivers/clk/rockchip/clk-rk3288.c | 2 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/rockchip/Makefile | 3 + drivers/crypto/rockchip/rk3288_crypto.c| 396 + drivers/crypto/rockchip/rk3288_crypto.h| 216 + drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 489 + include/dt-bindings/clock/rk3288-cru.h | 1 + 10 files changed, 1159 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt create mode 100644 drivers/crypto/rockchip/Makefile create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] ARM: dts: rockchip: Add Crypto node for rk3288
Add Crypto node for rk3288 including crypto controller and dma clk.
Signed-off-by: Zain Wang
Tested-by: Heiko Stuebner
---
Changed in v4:
- None
Changed in v3:
- add reset property
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
arch/arm/boot/dts/rk3288.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..f0d1217 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -778,6 +778,18 @@
status = "disabled";
};
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+ clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ resets = <&cru SRST_CRYPTO>;
+ reset-names = "crypto-rst";
+ status = "okay";
+ };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288
Crypto driver support:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.
And other algorithms and platforms will be added later on.
Signed-off-by: Zain Wang
Tested-by: Heiko Stuebner
---
Changed in v4:
- modify irq function
- add devm_add_action in probe
- fix some minor mistakes
Changed in v3:
- add OF depended in Kconfig
- rename some variate
- add reset property
- remove crypto_p variate
Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type
Changed in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
- add Kconfig
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile| 1 +
drivers/crypto/rockchip/Makefile | 3 +
drivers/crypto/rockchip/rk3288_crypto.c| 396 +
drivers/crypto/rockchip/rk3288_crypto.h| 216 +
drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 489 +
6 files changed, 1116 insertions(+)
create mode 100644 drivers/crypto/rockchip/Makefile
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..e5451b6 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_ROCKCHIP
+ tristate "Rockchip's Cryptographic Engine driver"
+ depends on OF && ARCH_ROCKCHIP
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+
+ help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..3c79902
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,396 @@
+/*
+ * Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int rk_crypto_enable_clk(struct rk_crypto_info *dev)
+{
+ int err;
+
+ err = clk_prepare_enable(dev->sclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock sclk\n",
+ __func__, __LINE__);
+ goto err_return;
+ }
+ err = clk_prepare_enable(dev->aclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock aclk\n",
+ __func__, __LINE__);
+ goto err_aclk;
+ }
+ err = clk_prepare_enable(dev->hclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock hclk\n",
+ __func__, __LINE__);
+ goto err_hclk;
+ }
+ err = clk_prepare_enable(dev->dmaclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock dmaclk\n",
+ __func__, __LINE__);
+ goto err_dmaclk;
+ }
+ return err;
+err_dmaclk:
+ clk_disable_unprepare(dev->hclk);
+err_hclk:
+ clk_disable_unprepare(dev->aclk);
+err_aclk:
+ clk_disable_unprepare(dev->sclk);
+err_return:
+ return err;
+}
+
+static void rk_crypto_disable_clk(struct rk_crypto_info *dev)
+{
+ clk_disable_unprepare(dev->dmaclk);
+ clk_disable_unprepare(dev->hclk);
+ clk_disable_unprepare(dev->ac
[PATCH v4 1/4] crypto: rockchip/crypto - add DT bindings documentation
Add DT bindings documentation for the rk3288 crypto drivers.
Signed-off-by: Zain Wang
Acked-by: Rob Herring
Tested-by: Heiko Stuebner
---
Changed in v4:
- None
Changed in v3:
- add reset property
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
- remove the description of status
.../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..096df34
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: Base physical address of the engine and length of memory mapped
+ region
+- interrupts: Interrupt number
+- clocks: Reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+ "hclk" used to clock data
+ "sclk" used to clock crypto accelerator
+ "apb_pclk" used to clock dma
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the name "crypto-rst".
+
+Examples:
+
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+ clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ resets = <&cru SRST_CRYPTO>;
+ reset-names = "crypto-rst";
+ status = "okay";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs
From: Magnus Damm
Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
IPMMU DT binding documentation. The example is also updated to show
how the generic compatible string may be used as fallback.
Signed-off-by: Magnus Damm
---
Changes since V1:
- Updated compat string section to the following:
"Must contain SoC-specific and generic entries from below."
Thanks to Laurent for feedback!
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 12
--
1 file changed, 10 insertions(+), 2 deletions(-)
--- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
+++ work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
2015-11-17 12:45:26.080513000 +0900
@@ -7,7 +7,15 @@ connected to the IPMMU through a port ca
Required Properties:
- - compatible: Must contain "renesas,ipmmu-vmsa".
+ - compatible: Must contain SoC-specific and generic entries from below.
+
+- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
+- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
+- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
+- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
+- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
+- "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
+
- reg: Base address and size of the IPMMU registers.
- interrupts: Specifiers for the MMU fault interrupts. For instances that
support secure mode two interrupts must be specified, for non-secure and
@@ -27,7 +35,7 @@ node with the following property:
Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
ipmmu_mx: mmu@fe951000 {
- compatible = "renasas,ipmmu-vmsa";
+ compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
reg = <0 0xfe951000 0 0x1000>;
interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
<0 221 IRQ_TYPE_LEVEL_HIGH>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Tue, 2015-11-17 at 14:04 +1100, Gavin Shan wrote: > > Sorry, you mean it's fine to break the code on P7IOC as it's going to be dead. > But I'm curious when it's going happen, any idea about that? Is it ? I think it's ok to not add support for M64, hotpug etc for IODA1, but we can do that without *breaking* basic function that we have today. It's not completely dead, there are still a number of machines inside of IBM with P7 that we can support for a little while longer (including a few inside ozlabs). Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Tue, Nov 17, 2015 at 01:37:22PM +1100, Alexey Kardashevskiy wrote: >On 11/17/2015 12:42 PM, Gavin Shan wrote: >>On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote: >>>On 11/05/2015 12:12 AM, Gavin Shan wrote: This enables M64 window on P7IOC, which has been enabled on PHB3. Different from PHB3 where 16 M64 BARs are supported and each of them can be owned by one particular PE# exclusively or divided evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each of them are divided to 8 segments. So every P7IOC PHB supports 128 M64 segments in total. P7IOC has M64DT, which helps mapping one particular M64 segment# to arbitrary PE#. PHB3 doesn't have M64DT, indicating that one M64 segment can only be pinned to the fixed PE#. In order to have same code to support M64 on P7IOC and PHB3, we just provide 128 M64 segments on every P7IOC PHB and each of them is pinned to the fixed PE# by bypassing the function of M64DT. In turn, we just need different phb->init_m64() for P7IOC and PHB3 to support M64. >>> >>>I thought we decided (Ben suggested?) not to push P7IOC code now (or ever) as >>>there is no user for it, has this changed? >>> >> >>Remember that the code is mixed for P7IOC/PHB3. It's not harmful to support >>M64 window on P7IOC, which is much larger than M32. > > >The patchset starts with removing dead code and then adds more dead code. >This is not right... > Sorry, you mean it's fine to break the code on P7IOC as it's going to be dead. But I'm curious when it's going happen, any idea about that? >>>btw please put ioda1/ioda2/p7ioc/etc to the subject line to make it easier to >>>see how much work is there about particular PHB type. You rename quite many >>>functions and I generally want to ask you to group all renaming patches first >>>but it would also make sense to keep them close to (for example) >>>p7ioc-related patches so having more descriptive subject lines may help. >>>Thanks. >>> >> >>As the code is mixed for P7IOC/PHB3, I'm not following the line >>(IODA1/IODA2/p7ioc/phb3) >>in this patchset. > >But you should draw the bold line between PHB types imho. > >>Instead, the sequence of patchset is order related to: cod refactoring, >>IO/M32/M64, DMA, PE allocation/releaseing. > > >Some patches from this patchset are about P7IOC only. All I am asking is to >say specifically in the subject line what the patch touches - >IODA1/IODA2/p7ioc/phb3/all_of_them. Or I can walk through all of them, pick >P7IOC's ones, evaluate the amount of code and entropy they actually add and >then ask Ben what we do about it, it will just take longer rather than if you >did it. > Please give me a clear command what key words you need in the subject in next revision. What I understood is you want to see one of them: powerpc/powernv/ioda1: powerpc/powernv/ioda2: powerpc/powernv/all: Thanks, Gavin > >-- >Alexey > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 22/50] powerpc/powernv: Introduce pnv_ioda_init_pe()
On Tue, Nov 17, 2015 at 01:37:33PM +1100, Alexey Kardashevskiy wrote:
>On 11/17/2015 12:58 PM, Gavin Shan wrote:
>>On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
>>>Gavin Shan writes:
>>>
This introduces pnv_ioda_init_pe() to initialize the specified PE
instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
and pnv_ioda_reserve_pe(). No logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ef93a01..488e0f8 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -129,6 +129,14 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned
long flags)
(IORESOURCE_MEM_64 | IORESOURCE_PREFETCH));
}
+static struct pnv_ioda_pe *pnv_ioda_init_pe(struct pnv_phb *phb, int pe_no)
+{
+ phb->ioda.pe_array[pe_no].phb = phb;
+ phb->ioda.pe_array[pe_no].pe_number = pe_no;
+
+ return &phb->ioda.pe_array[pe_no];
>>>You have the function returning the newly initalized PE here...
>>>
+}
+
static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
{
if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
@@ -141,8 +149,7 @@ static void pnv_ioda_reserve_pe(struct pnv_phb *phb,
int pe_no)
pr_debug("%s: PE %d was reserved on PHB#%x\n",
__func__, pe_no, phb->hose->global_number);
- phb->ioda.pe_array[pe_no].phb = phb;
- phb->ioda.pe_array[pe_no].pe_number = pe_no;
+ pnv_ioda_init_pe(phb, pe_no);
>>>... but then you ignore the result here and in the other function you've
>>>modified.
>>>
>>>It looks like you're using the result in the next patch though, so I
>>>wonder if you would be better to merge this patch with the next
>>>one. However, as I said before I'll defer to Alexey on decisions about
>>>how to split the patch series if he has a different opinion.
>>>
>>
>>I'd like to keep this separate when thinking about the rule I was told before:
>>one patch does one thing if it can. Also, merging it to next one will make
>>next one harder to be reiview.
>
>This patch merged into the next one will make the next one easier to review
>because you won't have to change there the code which you just added in this
>patch (which is always good).
>
Ok & will do in next revision.
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Tue, Nov 17, 2015 at 01:11:56PM +1100, Alexey Kardashevskiy wrote:
>On 11/17/2015 12:38 PM, Gavin Shan wrote:
>>On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
>>>On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each
of them are divided to 8 segments. So every P7IOC PHB supports
128 M64 segments in total. P7IOC has M64DT, which helps mapping
one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
M64DT, indicating that one M64 segment can only be pinned to the
fixed PE#. In order to have same code to support M64 on P7IOC and
PHB3, we just provide 128 M64 segments on every P7IOC PHB and each
of them is pinned to the fixed PE# by bypassing the function of
M64DT. In turn, we just need different phb->init_m64() for P7IOC
and PHB3 to support M64.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 86
+--
arch/powerpc/platforms/powernv/pci.h | 3 ++
2 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1f7d985..bfe69f1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -256,6 +256,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev
*pdev,
}
}
+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
+{
+ struct resource *r;
+ int index;
+
+ /*
+* There are 16 M64 BARs, each of which has 8 segments. So
+* there are as many M64 segments as the maximum number of
+* PEs, which is 128.
+*/
+ for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
+ unsigned long base, segsz = phb->ioda.m64_segsize;
+ int64_t rc;
+
+ base = phb->ioda.m64_base +
+ index * PNV_IODA1_M64_SEGS * segsz;
+ rc = opal_pci_set_phb_mem_window(phb->opal_id,
+ OPAL_M64_WINDOW_TYPE, index, base, 0,
+ PNV_IODA1_M64_SEGS * segsz);
+ if (rc != OPAL_SUCCESS) {
+ pr_warn(" Error %lld setting M64 PHB#%d-BAR#%d\n",
+ rc, phb->hose->global_number, index);
+ goto fail;
+ }
+
+ rc = opal_pci_phb_mmio_enable(phb->opal_id,
+ OPAL_M64_WINDOW_TYPE, index,
+ OPAL_ENABLE_M64_SPLIT);
+ if (rc != OPAL_SUCCESS) {
+ pr_warn(" Error %lld enabling M64 PHB#%d-BAR#%d\n",
+ rc, phb->hose->global_number, index);
+ goto fail;
+ }
+ }
+
+ /*
+* Exclude the segment used by the reserved PE, which
+* is expected to be 0 or last supported PE#.
+*/
+ r = &phb->hose->mem_resources[1];
>>>
>>>
>>>What does "1" mean here? A bridge's 64bit prefetchable window?
>>>
>>
>>It's PHB's M64 window.
>
>mem_resources[] of a hose are not windows of the root PCI bridge?
>
No. They're windows for root bus, but not for root PCI bridge.
>>
>>>
+ if (phb->ioda.reserved_pe_idx == 0)
+ r->start += phb->ioda.m64_segsize;
+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
+ r->end -= phb->ioda.m64_segsize;
+ else
+ pr_warn(" Cannot cut M64 segment for reserved PE#%d\n",
+ phb->ioda.reserved_pe_idx);
+
>>
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 22/50] powerpc/powernv: Introduce pnv_ioda_init_pe()
On 11/17/2015 12:58 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
Gavin Shan writes:
This introduces pnv_ioda_init_pe() to initialize the specified PE
instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
and pnv_ioda_reserve_pe(). No logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ef93a01..488e0f8 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -129,6 +129,14 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
flags)
(IORESOURCE_MEM_64 | IORESOURCE_PREFETCH));
}
+static struct pnv_ioda_pe *pnv_ioda_init_pe(struct pnv_phb *phb, int pe_no)
+{
+ phb->ioda.pe_array[pe_no].phb = phb;
+ phb->ioda.pe_array[pe_no].pe_number = pe_no;
+
+ return &phb->ioda.pe_array[pe_no];
You have the function returning the newly initalized PE here...
+}
+
static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
{
if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
@@ -141,8 +149,7 @@ static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int
pe_no)
pr_debug("%s: PE %d was reserved on PHB#%x\n",
__func__, pe_no, phb->hose->global_number);
- phb->ioda.pe_array[pe_no].phb = phb;
- phb->ioda.pe_array[pe_no].pe_number = pe_no;
+ pnv_ioda_init_pe(phb, pe_no);
... but then you ignore the result here and in the other function you've
modified.
It looks like you're using the result in the next patch though, so I
wonder if you would be better to merge this patch with the next
one. However, as I said before I'll defer to Alexey on decisions about
how to split the patch series if he has a different opinion.
I'd like to keep this separate when thinking about the rule I was told before:
one patch does one thing if it can. Also, merging it to next one will make
next one harder to be reiview.
This patch merged into the next one will make the next one easier to review
because you won't have to change there the code which you just added in
this patch (which is always good).
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On 11/17/2015 12:42 PM, Gavin Shan wrote: On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote: On 11/05/2015 12:12 AM, Gavin Shan wrote: This enables M64 window on P7IOC, which has been enabled on PHB3. Different from PHB3 where 16 M64 BARs are supported and each of them can be owned by one particular PE# exclusively or divided evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each of them are divided to 8 segments. So every P7IOC PHB supports 128 M64 segments in total. P7IOC has M64DT, which helps mapping one particular M64 segment# to arbitrary PE#. PHB3 doesn't have M64DT, indicating that one M64 segment can only be pinned to the fixed PE#. In order to have same code to support M64 on P7IOC and PHB3, we just provide 128 M64 segments on every P7IOC PHB and each of them is pinned to the fixed PE# by bypassing the function of M64DT. In turn, we just need different phb->init_m64() for P7IOC and PHB3 to support M64. I thought we decided (Ben suggested?) not to push P7IOC code now (or ever) as there is no user for it, has this changed? Remember that the code is mixed for P7IOC/PHB3. It's not harmful to support M64 window on P7IOC, which is much larger than M32. The patchset starts with removing dead code and then adds more dead code. This is not right... btw please put ioda1/ioda2/p7ioc/etc to the subject line to make it easier to see how much work is there about particular PHB type. You rename quite many functions and I generally want to ask you to group all renaming patches first but it would also make sense to keep them close to (for example) p7ioc-related patches so having more descriptive subject lines may help. Thanks. As the code is mixed for P7IOC/PHB3, I'm not following the line (IODA1/IODA2/p7ioc/phb3) in this patchset. But you should draw the bold line between PHB types imho. Instead, the sequence of patchset is order related to: cod refactoring, IO/M32/M64, DMA, PE allocation/releaseing. Some patches from this patchset are about P7IOC only. All I am asking is to say specifically in the subject line what the patch touches - IODA1/IODA2/p7ioc/phb3/all_of_them. Or I can walk through all of them, pick P7IOC's ones, evaluate the amount of code and entropy they actually add and then ask Ben what we do about it, it will just take longer rather than if you did it. -- Alexey -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Documentation: dt: binding: fsl: add devicetree binding for describing RCPM
On Mon, 2015-11-16 at 11:26 -0600, Rob Herring wrote: > +Sudeep > > On Mon, Oct 26, 2015 at 02:44:12PM +0800, Dongsheng Wang wrote: > > From: Wang Dongsheng > > > > RCPM is the Run Control and Power Management module performs all > > device-level tasks associated with device run control and power > > management. > > > > Add this for freescale powerpc platform and layerscape platform. > > [...] > > > @@ -0,0 +1,64 @@ > > +* Run Control and Power Management > > +--- > > +The RCPM performs all device-level tasks associated with device run > > control > > +and power management. > > + > > +Required properites: > > + - reg : Offset and length of the register set of the RCPM block. > > + - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in > > the > > + fsl,rcpm-wakeup property. > > [...] > > > +* Freescale RCPM Wakeup Source Device Tree Bindings > > +--- > > +Required fsl,rcpm-wakeup property should be added to a device node if the > > device > > +can be used as a wakeup source. > > + > > + - fsl,rcpm-wakeup: Consists of a pointer to the rcpm node and the > > IPPDEXPCR > > + register cells. The number of IPPDEXPCR register cells is defined > > in > > + "fsl,#rcpm-wakeup-cells" in the rcpm node. The first register > > cell is > > + the bit mask that should be set in IPPDEXPCR0, and the second > > register > > + cell is for IPPDEXPCR1, and so on. > > We just merged a common wakeup source binding[1]. It doesn't really work > in a similar way to what you have done, but I'd like to see something > common here. How exactly wakeup is done tends to depend on whether > interrupts are also wakeup signals or wake-up signally is completely > separate from interrupts. Depending on that, I think there are 2 options > here: > > - Use the common binding and implement a stacked irqdomain for the > wakeup controller. I'm not sure what a stacked irqdomain is, but the mechanism described here isn't about interrupts at all. It's about controlling whether certain devices are kept awake in order to have the possibility of generating a wakeup. I believe the actual wakeup comes via the ordinary device interrupt. > - Extend the common binding to allow a phandle+args value to point to > the wakeup controller. Possibly, but the description in the common binding would have to be fairly vague to make the semantics fit. The current common binding is also a bit confusing by saying that the presence of the property means that all of the device's interrupts can be used as wakeup events, but then saying that there can also be a dedicated wakeup but not making it clear how to represent that... Overloading it with device power control might muddy things even further. -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4 00/10] add support SATA for BMIPS_GENERIC
On Fri, Oct 30, 2015 at 11:01:14PM +0900, Jaedon Shin wrote:
> Hi all,
>
> This patch series add support SATA for BMIPS_GENERIC.
>
> Changes in v4:
> - remove unused properties from bcm{7425,7342,7362}.dtsi
>
> Changes in v3:
> - fix typo quirk instead of quick
> - disable NCQ before initialzing SATA controller endianness
> - fix misnomer controlling phy interface
> - remove brcm,broken-ncq and brcm,broken-phy properties from devicetree
> - use compatible string for quirks
> - use list for compatible strings
> - add "Acked-by:" tags
>
> Changes in v2:
> - adds quirk for ncq
> - adds quirk for phy interface control
> - remove unused definitions in ahci_brcmstb
> - combines compatible string
For the drivers portions (including patch 2, if you fix the error I
pointed out):
Acked-by: Brian Norris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4 02/10] ata: ahci_brcmstb: add quirk for broken ncq
Hi,
On Fri, Oct 30, 2015 at 11:01:16PM +0900, Jaedon Shin wrote:
> Add quirk for broken ncq. Some chipsets (eg. BCM7349A0, BCM7445A0,
> BCM7445B0, and all 40nm chipsets including BCM7425) need a workaround
> disabling NCQ.
>
> Signed-off-by: Jaedon Shin
> ---
> drivers/ata/ahci_brcmstb.c | 46
> ++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
> index 73e3b0b2a3c2..194aeda8f14d 100644
> --- a/drivers/ata/ahci_brcmstb.c
> +++ b/drivers/ata/ahci_brcmstb.c
> @@ -69,10 +69,15 @@
> (DATA_ENDIAN << DMADESC_ENDIAN_SHIFT) | \
> (MMIO_ENDIAN << MMIO_ENDIAN_SHIFT))
>
> +enum brcm_ahci_quirks {
> + BRCM_AHCI_QUIRK_NONCQ = BIT(0),
> +};
> +
> struct brcm_ahci_priv {
> struct device *dev;
> void __iomem *top_ctrl;
> u32 port_mask;
> + u32 quirks;
> };
>
> static const struct ata_port_info ahci_brcm_port_info = {
> @@ -202,6 +207,42 @@ static u32 brcm_ahci_get_portmask(struct platform_device
> *pdev,
> return impl;
> }
>
> +static void brcm_sata_quirks(struct platform_device *pdev,
> + struct brcm_ahci_priv *priv)
> +{
> + if (priv->quirks & BRCM_AHCI_QUIRK_NONCQ) {
> + void __iomem *ctrl = priv->top_ctrl + SATA_TOP_CTRL_BUS_CTRL;
> + void __iomem *ahci;
> + struct resource *res;
> + u32 reg;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +"ahci");
> + ahci = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(ahci))
> + return;
> +
> + reg = brcm_sata_readreg(ctrl);
> + reg |= OVERRIDE_HWINIT;
> + brcm_sata_writereg(reg, ctrl);
> +
> + /* Clear out the NCQ bit so the AHCI driver will not issue
> + * FPDMA/NCQ commands.
> + */
> + reg = readl(ahci + HOST_CAP);
> + reg &= ~HOST_CAP_NCQ;
> + writel(reg, ahci + HOST_CAP);
You're using readl()/writel() to access the AHCI block, but...
> +
> + reg = brcm_sata_readreg(ctrl);
> + reg &= ~OVERRIDE_HWINIT;
> + brcm_sata_writereg(reg, ctrl);
> +
> + devm_iounmap(&pdev->dev, ahci);
> + devm_release_mem_region(&pdev->dev, res->start,
> + resource_size(res));
> + }
> +}
> +
> static void brcm_sata_init(struct brcm_ahci_priv *priv)
> {
> /* Configure endianness */
> @@ -256,6 +297,11 @@ static int brcm_ahci_probe(struct platform_device *pdev)
> if (IS_ERR(priv->top_ctrl))
> return PTR_ERR(priv->top_ctrl);
>
> + if (of_device_is_compatible(dev->of_node, "brcm,bcm7425-ahci"))
> + priv->quirks |= BRCM_AHCI_QUIRK_NONCQ;
> +
> + brcm_sata_quirks(pdev, priv);
> +
> brcm_sata_init(priv);
...the MMIO endianness is only configured in brcm_sata_init(). You won't
see this problem on ARM LE, but you should on MIPS BE. Maybe
brcm_sata_quirks() should be after brcm_sata_init()?
>
> priv->port_mask = brcm_ahci_get_portmask(pdev, priv);
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On 11/17/2015 12:38 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each
of them are divided to 8 segments. So every P7IOC PHB supports
128 M64 segments in total. P7IOC has M64DT, which helps mapping
one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
M64DT, indicating that one M64 segment can only be pinned to the
fixed PE#. In order to have same code to support M64 on P7IOC and
PHB3, we just provide 128 M64 segments on every P7IOC PHB and each
of them is pinned to the fixed PE# by bypassing the function of
M64DT. In turn, we just need different phb->init_m64() for P7IOC
and PHB3 to support M64.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 86 +--
arch/powerpc/platforms/powernv/pci.h | 3 ++
2 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1f7d985..bfe69f1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -256,6 +256,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev
*pdev,
}
}
+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
+{
+ struct resource *r;
+ int index;
+
+ /*
+* There are 16 M64 BARs, each of which has 8 segments. So
+* there are as many M64 segments as the maximum number of
+* PEs, which is 128.
+*/
+ for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
+ unsigned long base, segsz = phb->ioda.m64_segsize;
+ int64_t rc;
+
+ base = phb->ioda.m64_base +
+ index * PNV_IODA1_M64_SEGS * segsz;
+ rc = opal_pci_set_phb_mem_window(phb->opal_id,
+ OPAL_M64_WINDOW_TYPE, index, base, 0,
+ PNV_IODA1_M64_SEGS * segsz);
+ if (rc != OPAL_SUCCESS) {
+ pr_warn(" Error %lld setting M64 PHB#%d-BAR#%d\n",
+ rc, phb->hose->global_number, index);
+ goto fail;
+ }
+
+ rc = opal_pci_phb_mmio_enable(phb->opal_id,
+ OPAL_M64_WINDOW_TYPE, index,
+ OPAL_ENABLE_M64_SPLIT);
+ if (rc != OPAL_SUCCESS) {
+ pr_warn(" Error %lld enabling M64 PHB#%d-BAR#%d\n",
+ rc, phb->hose->global_number, index);
+ goto fail;
+ }
+ }
+
+ /*
+* Exclude the segment used by the reserved PE, which
+* is expected to be 0 or last supported PE#.
+*/
+ r = &phb->hose->mem_resources[1];
What does "1" mean here? A bridge's 64bit prefetchable window?
It's PHB's M64 window.
mem_resources[] of a hose are not windows of the root PCI bridge?
+ if (phb->ioda.reserved_pe_idx == 0)
+ r->start += phb->ioda.m64_segsize;
+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
+ r->end -= phb->ioda.m64_segsize;
+ else
+ pr_warn(" Cannot cut M64 segment for reserved PE#%d\n",
+ phb->ioda.reserved_pe_idx);
+
Thanks,
Gavin
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 18/50] powerpc/powernv: Remove DMA32 PE list
On Tue, Nov 17, 2015 at 12:54:04PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
>>to their DMA32 weight. The PEs on the list are iterated to setup
>>their TCE32 tables at system booting time. The list is used for
>>once and there is no good reason for it to survive.
>
>From the above I concluded that you need a list, just do not need to keep
>after the configuration is done but in fact you remove the list completely so
>just remove "to survive" (s/for it to survive/for keep having it/) :)
>
Thanks & will change it accordingly in next revision :)
>>
>>This moves the logic calculating DMA32 weight of PHB and PE to
>>pnv_pci_ioda1_setup_dma() to drop PHB's DMA32 list.
>>
>>Signed-off-by: Gavin Shan
>>---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 150
>> ++
>> arch/powerpc/platforms/powernv/pci.h | 19
>> 2 files changed, 68 insertions(+), 101 deletions(-)
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>>b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index 4c2e023..20ebe6e 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -891,44 +891,6 @@ out:
>> return 0;
>> }
>>
>>-static void pnv_ioda_link_pe_by_weight(struct pnv_phb *phb,
>>-struct pnv_ioda_pe *pe)
>>-{
>>- struct pnv_ioda_pe *lpe;
>>-
>>- list_for_each_entry(lpe, &phb->ioda.pe_dma_list, dma_link) {
>>- if (lpe->dma_weight < pe->dma_weight) {
>>- list_add_tail(&pe->dma_link, &lpe->dma_link);
>>- return;
>>- }
>>- }
>>- list_add_tail(&pe->dma_link, &phb->ioda.pe_dma_list);
>>-}
>>-
>>-static unsigned int pnv_ioda_dma_weight(struct pci_dev *dev)
>>-{
>>- /* This is quite simplistic. The "base" weight of a device
>>- * is 10. 0 means no DMA is to be accounted for it.
>>- */
>>-
>>- /* If it's a bridge, no DMA */
>>- if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL)
>>- return 0;
>>-
>>- /* Reduce the weight of slow USB controllers */
>>- if (dev->class == PCI_CLASS_SERIAL_USB_UHCI ||
>>- dev->class == PCI_CLASS_SERIAL_USB_OHCI ||
>>- dev->class == PCI_CLASS_SERIAL_USB_EHCI)
>>- return 3;
>>-
>>- /* Increase the weight of RAID (includes Obsidian) */
>>- if ((dev->class >> 8) == PCI_CLASS_STORAGE_RAID)
>>- return 15;
>>-
>>- /* Default */
>>- return 10;
>>-}
>>-
>> #ifdef CONFIG_PCI_IOV
>> static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
>> {
>>@@ -1009,7 +971,6 @@ static void pnv_ioda_setup_same_PE(struct pci_bus *bus,
>>struct pnv_ioda_pe *pe)
>> continue;
>> }
>> pdn->pe_number = pe->pe_number;
>>- pe->dma_weight += pnv_ioda_dma_weight(dev);
>> if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
>> pnv_ioda_setup_same_PE(dev->subordinate, pe);
>> }
>>@@ -1046,10 +1007,8 @@ static void pnv_ioda_setup_bus_PE(struct pci_bus *bus,
>>bool all)
>> pe->flags |= (all ? PNV_IODA_PE_BUS_ALL : PNV_IODA_PE_BUS);
>> pe->pbus = bus;
>> pe->pdev = NULL;
>>- pe->tce32_seg = -1;
>> pe->mve_number = -1;
>> pe->rid = bus->busn_res.start << 8;
>>- pe->dma_weight = 0;
>>
>> if (all)
>> pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
>>@@ -1071,17 +1030,6 @@ static void pnv_ioda_setup_bus_PE(struct pci_bus *bus,
>>bool all)
>>
>> /* Put PE to the list */
>> list_add_tail(&pe->list, &phb->ioda.pe_list);
>>-
>>- /* Account for one DMA PE if at least one DMA capable device exist
>>- * below the bridge
>>- */
>>- if (pe->dma_weight != 0) {
>>- phb->ioda.dma_weight += pe->dma_weight;
>>- phb->ioda.dma_pe_count++;
>>- }
>>-
>>- /* Link the PE */
>>- pnv_ioda_link_pe_by_weight(phb, pe);
>> }
>>
>> static void pnv_ioda_setup_PEs(struct pci_bus *bus)
>>@@ -1389,7 +1337,6 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev,
>>u16 num_vfs)
>> pe->flags = PNV_IODA_PE_VF;
>> pe->pbus = NULL;
>> pe->parent_dev = pdev;
>>- pe->tce32_seg = -1;
>> pe->mve_number = -1;
>> pe->rid = (pci_iov_virtfn_bus(pdev, vf_index) << 8) |
>> pci_iov_virtfn_devfn(pdev, vf_index);
>>@@ -1842,6 +1789,47 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
>> .free = pnv_ioda2_table_free,
>> };
>>
>>+static int pnv_pci_ioda_dev_dma_weight(struct pci_dev *dev, void *data)
>>+{
>>+ unsigned int *weight = (unsigned int *)data;
>>+
>>+ /* This is quite simplistic. The "base" weight of a device
>>+ * is 10. 0 means no DMA is to be accounted for it.
>>+ */
>>+
>>+ if (dev->hdr_type != PCI_HEADER_
Re: [PATCH v7 22/50] powerpc/powernv: Introduce pnv_ioda_init_pe()
On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> This introduces pnv_ioda_init_pe() to initialize the specified PE
>> instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
>> and pnv_ioda_reserve_pe(). No logical changes introduced.
>>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 14 ++
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>> b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index ef93a01..488e0f8 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -129,6 +129,14 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
>> flags)
>> (IORESOURCE_MEM_64 | IORESOURCE_PREFETCH));
>> }
>>
>> +static struct pnv_ioda_pe *pnv_ioda_init_pe(struct pnv_phb *phb, int pe_no)
>> +{
>> +phb->ioda.pe_array[pe_no].phb = phb;
>> +phb->ioda.pe_array[pe_no].pe_number = pe_no;
>> +
>> +return &phb->ioda.pe_array[pe_no];
>You have the function returning the newly initalized PE here...
>
>> +}
>> +
>> static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
>> {
>> if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
>> @@ -141,8 +149,7 @@ static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int
>> pe_no)
>> pr_debug("%s: PE %d was reserved on PHB#%x\n",
>> __func__, pe_no, phb->hose->global_number);
>>
>> -phb->ioda.pe_array[pe_no].phb = phb;
>> -phb->ioda.pe_array[pe_no].pe_number = pe_no;
>> +pnv_ioda_init_pe(phb, pe_no);
>... but then you ignore the result here and in the other function you've
>modified.
>
>It looks like you're using the result in the next patch though, so I
>wonder if you would be better to merge this patch with the next
>one. However, as I said before I'll defer to Alexey on decisions about
>how to split the patch series if he has a different opinion.
>
I'd like to keep this separate when thinking about the rule I was told before:
one patch does one thing if it can. Also, merging it to next one will make
next one harder to be reiview.
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 21/50] powerpc/powernv: Increase PE# capacity
On Tue, Nov 17, 2015 at 11:29:26AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> Each PHB maintains an array helping to translate 2-bytes Request
>> ID (RID) to PE# with the assumption that PE# takes one byte, meaning
>> that we can't have more than 256 PEs. However, pci_dn->pe_number
>> already had 4-bytes for the PE#.
>>
>> This extends the PE# capacity so that each of them will be 4-bytes
>> long. Then we can reuse IODA_INVALID_PE to check the PE# stored in
>> phb->pe_rmap[] is valid or not.
>
>Just for clarity, could you make it clear in the commit message that
>you're increasing the PE# capacity _in the PHB_? I just found it a bit
>confusing the first time I read it.
>
>With that clarified I'll be happy to add my reviewed-by tag.
>
Sure, will add it and thanks for your happiness :-)
>>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 6 +-
>> arch/powerpc/platforms/powernv/pci.h | 7 ++-
>> 2 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>> b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 0e66c4d..ef93a01 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -766,7 +766,7 @@ static int pnv_ioda_deconfigure_pe(struct pnv_phb *phb,
>> struct pnv_ioda_pe *pe)
>>
>> /* Clear the reverse map */
>> for (rid = pe->rid; rid < rid_end; rid++)
>> -phb->ioda.pe_rmap[rid] = 0;
>> +phb->ioda.pe_rmap[rid] = IODA_INVALID_PE;
>>
>> /* Release from all parents PELT-V */
>> while (parent) {
>> @@ -3164,6 +3164,10 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> if (prop32)
>> phb->ioda.reserved_pe_idx = be32_to_cpup(prop32);
>>
>> +/* Invalidate RID to PE# mapping */
>> +for (i = 0; i < ARRAY_SIZE(phb->ioda.pe_rmap); ++i)
>> +phb->ioda.pe_rmap[i] = IODA_INVALID_PE;
>> +
>> /* Parse 64-bit MMIO range */
>> pnv_ioda_parse_m64_window(phb);
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci.h
>> b/arch/powerpc/platforms/powernv/pci.h
>> index 0802fcd..5df945f 100644
>> --- a/arch/powerpc/platforms/powernv/pci.h
>> +++ b/arch/powerpc/platforms/powernv/pci.h
>> @@ -162,11 +162,8 @@ struct pnv_phb {
>> struct list_headpe_list;
>> struct mutexpe_list_mutex;
>>
>> -/* Reverse map of PEs, will have to extend if
>> - * we are to support more than 256 PEs, indexed
>> - * bus { bus, devfn }
>> - */
>> -unsigned char pe_rmap[0x1];
>> +/* Reverse map of PEs, indexed by {bus, devfn} */
>> +int pe_rmap[0x1];
>>
>> /* TCE cache invalidate registers (physical and
>> * remapped)
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 19/50] powerpc/powernv: Track DMA32 segment consumption
On Tue, Nov 17, 2015 at 11:28:20AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> Similar to the mechanism tracking consumed IO/M32/M64 segments,
>> this introduces an array for each PHB to track the consumed DMA32
>> segments, which are going to be released on PCI unplugging time.
>> The index of the array is the DMA32 segment number while the value
>> stored in the element is the assigned PE number.
>>
>
>
>> +/* Setup TCE32 segment mapping */
>Do you mean DMA32 rather than TCE32?
Right, will change it to "DMA32" in next revision.
>> +for (i = base; i < base + segs; i++)
>> +phb->ioda.dma32_segmap[i] = pe->pe_number;
>> +
>I'm pretty sure this is right, but can you just confirm that you
>intended to index into the array starting at base and going to base + segs,
>and not going from 0 to segs? (i.e. not dma32_segmap[i - base]).
>
I think you're saying "I'm not pretty sure this is right". The code doesn't
have problem here: it starts from @base.
>Otherwise looks good.
>
>
>> /* Setup linux iommu table */
>> pnv_pci_setup_iommu_table(tbl, addr, tce32_segsz * segs,
>>base * PNV_IODA1_DMA32_SEGSIZE,
>> @@ -2378,13 +2382,13 @@ static void pnv_pci_ioda1_setup_dma(struct pnv_phb
>> *phb)
>> * then we assign at least one segment per PE, plus more based
>> * on the amount of devices under that PE
>> */
>> -if (dma_pe_count > phb->ioda.tce32_count)
>> +if (dma_pe_count > phb->ioda.dma32_count)
>> residual = 0;
>> else
>> -residual = phb->ioda.tce32_count - dma_pe_count;
>> +residual = phb->ioda.dma32_count - dma_pe_count;
>>
>> pr_info("PCI: Domain %04x has %ld available 32-bit DMA segments\n",
>> -hose->global_number, phb->ioda.tce32_count);
>> +hose->global_number, phb->ioda.dma32_count);
>> pr_info("PCI: %d PE# for a total weight of %d\n",
>> dma_pe_count, total_weight);
>>
>> @@ -2394,7 +2398,7 @@ static void pnv_pci_ioda1_setup_dma(struct pnv_phb
>> *phb)
>> * out one base segment plus any residual segments based on
>> * weight
>> */
>> -remaining = phb->ioda.tce32_count;
>> +remaining = phb->ioda.dma32_count;
>> base = 0;
>> list_for_each_entry(pe, &phb->ioda.pe_list, list) {
>> weight = pnv_pci_ioda_pe_dma_weight(pe);
>> @@ -3094,7 +3098,8 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> {
>> struct pci_controller *hose;
>> struct pnv_phb *phb;
>> -unsigned long size, m64map_off, m32map_off, pemap_off, iomap_off = 0;
>> +unsigned long size, m64map_off, m32map_off, pemap_off;
>> +unsigned long iomap_off = 0, dma32map_off = 0;
>> const __be64 *prop64;
>> const __be32 *prop32;
>> int i, len;
>> @@ -3177,6 +3182,10 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> phb->ioda.io_segsize = phb->ioda.io_size / phb->ioda.total_pe_num;
>> phb->ioda.io_pci_base = 0; /* XXX calculate this ? */
>>
>> +/* Calculate how many 32-bit TCE segments we have */
>> +phb->ioda.dma32_count = phb->ioda.m32_pci_base /
>> +PNV_IODA1_DMA32_SEGSIZE;
>> +
>> /* Allocate aux data & arrays. We don't have IO ports on PHB3 */
>> size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
>> m64map_off = size;
>> @@ -3186,6 +3195,9 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> if (phb->type == PNV_PHB_IODA1) {
>> iomap_off = size;
>> size += phb->ioda.total_pe_num * sizeof(phb->ioda.io_segmap[0]);
>> +dma32map_off = size;
>> +size += phb->ioda.dma32_count *
>> +sizeof(phb->ioda.dma32_segmap[0]);
>> }
>> pemap_off = size;
>> size += phb->ioda.total_pe_num * sizeof(struct pnv_ioda_pe);
>> @@ -3201,6 +3213,10 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> phb->ioda.io_segmap = aux + iomap_off;
>> for (i = 0; i < phb->ioda.total_pe_num; i++)
>> phb->ioda.io_segmap[i] = IODA_INVALID_PE;
>> +
>> +phb->ioda.dma32_segmap = aux + dma32map_off;
>> +for (i = 0; i < phb->ioda.dma32_count; i++)
>> +phb->ioda.dma32_segmap[i] = IODA_INVALID_PE;
>> }
>> phb->ioda.pe_array = aux + pemap_off;
>> set_bit(phb->ioda.reserved_pe_idx, phb->ioda.pe_alloc);
>> @@ -3208,10 +3224,6 @@ static void __init pnv_pci_init_ioda_phb(struct
>> device_node *np,
>> INIT_LIST_HEAD(&phb->ioda.pe_list);
>> mutex_init(&phb->ioda.pe_list_mutex);
>>
>> -/* Calculate how many 32-bit TCE segments we have */
>> -phb->ioda.tce32_count = phb->ioda.m32_pci_base /
>> -PNV_IODA1_DMA32_SEGSIZE;
>> -
>> #if 0 /* We should really do that ... */
>> rc = opal_pci_set_phb_mem_window(opal->phb_id,
>>
Re: [PATCH v7 18/50] powerpc/powernv: Remove DMA32 PE list
On 11/05/2015 12:12 AM, Gavin Shan wrote:
PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
to their DMA32 weight. The PEs on the list are iterated to setup
their TCE32 tables at system booting time. The list is used for
once and there is no good reason for it to survive.
From the above I concluded that you need a list, just do not need to keep
after the configuration is done but in fact you remove the list completely
so just remove "to survive" (s/for it to survive/for keep having it/) :)
This moves the logic calculating DMA32 weight of PHB and PE to
pnv_pci_ioda1_setup_dma() to drop PHB's DMA32 list.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 150 ++
arch/powerpc/platforms/powernv/pci.h | 19
2 files changed, 68 insertions(+), 101 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 4c2e023..20ebe6e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -891,44 +891,6 @@ out:
return 0;
}
-static void pnv_ioda_link_pe_by_weight(struct pnv_phb *phb,
- struct pnv_ioda_pe *pe)
-{
- struct pnv_ioda_pe *lpe;
-
- list_for_each_entry(lpe, &phb->ioda.pe_dma_list, dma_link) {
- if (lpe->dma_weight < pe->dma_weight) {
- list_add_tail(&pe->dma_link, &lpe->dma_link);
- return;
- }
- }
- list_add_tail(&pe->dma_link, &phb->ioda.pe_dma_list);
-}
-
-static unsigned int pnv_ioda_dma_weight(struct pci_dev *dev)
-{
- /* This is quite simplistic. The "base" weight of a device
-* is 10. 0 means no DMA is to be accounted for it.
-*/
-
- /* If it's a bridge, no DMA */
- if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL)
- return 0;
-
- /* Reduce the weight of slow USB controllers */
- if (dev->class == PCI_CLASS_SERIAL_USB_UHCI ||
- dev->class == PCI_CLASS_SERIAL_USB_OHCI ||
- dev->class == PCI_CLASS_SERIAL_USB_EHCI)
- return 3;
-
- /* Increase the weight of RAID (includes Obsidian) */
- if ((dev->class >> 8) == PCI_CLASS_STORAGE_RAID)
- return 15;
-
- /* Default */
- return 10;
-}
-
#ifdef CONFIG_PCI_IOV
static int pnv_pci_vf_resource_shift(struct pci_dev *dev, int offset)
{
@@ -1009,7 +971,6 @@ static void pnv_ioda_setup_same_PE(struct pci_bus *bus,
struct pnv_ioda_pe *pe)
continue;
}
pdn->pe_number = pe->pe_number;
- pe->dma_weight += pnv_ioda_dma_weight(dev);
if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
pnv_ioda_setup_same_PE(dev->subordinate, pe);
}
@@ -1046,10 +1007,8 @@ static void pnv_ioda_setup_bus_PE(struct pci_bus *bus,
bool all)
pe->flags |= (all ? PNV_IODA_PE_BUS_ALL : PNV_IODA_PE_BUS);
pe->pbus = bus;
pe->pdev = NULL;
- pe->tce32_seg = -1;
pe->mve_number = -1;
pe->rid = bus->busn_res.start << 8;
- pe->dma_weight = 0;
if (all)
pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
@@ -1071,17 +1030,6 @@ static void pnv_ioda_setup_bus_PE(struct pci_bus *bus,
bool all)
/* Put PE to the list */
list_add_tail(&pe->list, &phb->ioda.pe_list);
-
- /* Account for one DMA PE if at least one DMA capable device exist
-* below the bridge
-*/
- if (pe->dma_weight != 0) {
- phb->ioda.dma_weight += pe->dma_weight;
- phb->ioda.dma_pe_count++;
- }
-
- /* Link the PE */
- pnv_ioda_link_pe_by_weight(phb, pe);
}
static void pnv_ioda_setup_PEs(struct pci_bus *bus)
@@ -1389,7 +1337,6 @@ static void pnv_ioda_setup_vf_PE(struct pci_dev *pdev,
u16 num_vfs)
pe->flags = PNV_IODA_PE_VF;
pe->pbus = NULL;
pe->parent_dev = pdev;
- pe->tce32_seg = -1;
pe->mve_number = -1;
pe->rid = (pci_iov_virtfn_bus(pdev, vf_index) << 8) |
pci_iov_virtfn_devfn(pdev, vf_index);
@@ -1842,6 +1789,47 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
.free = pnv_ioda2_table_free,
};
+static int pnv_pci_ioda_dev_dma_weight(struct pci_dev *dev, void *data)
+{
+ unsigned int *weight = (unsigned int *)data;
+
+ /* This is quite simplistic. The "base" weight of a device
+* is 10. 0 means no DMA is to be accounted for it.
+*/
+
+ if (dev->hdr_type != PCI_HEADER_TYPE_NORMAL)
+ return 0;
+
+ if (dev->class == PCI_CLASS_SERIAL_USB_UHCI ||
+ dev->class == PCI_CLASS_SERIAL_USB_OHCI ||
+ dev->class == PCI_CLASS_SERIAL_USB_EHCI)
+ *weight += 3;
+ else if (
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote: >On 11/05/2015 12:12 AM, Gavin Shan wrote: >>This enables M64 window on P7IOC, which has been enabled on PHB3. >>Different from PHB3 where 16 M64 BARs are supported and each of >>them can be owned by one particular PE# exclusively or divided >>evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each >>of them are divided to 8 segments. So every P7IOC PHB supports >>128 M64 segments in total. P7IOC has M64DT, which helps mapping >>one particular M64 segment# to arbitrary PE#. PHB3 doesn't have >>M64DT, indicating that one M64 segment can only be pinned to the >>fixed PE#. In order to have same code to support M64 on P7IOC and >>PHB3, we just provide 128 M64 segments on every P7IOC PHB and each >>of them is pinned to the fixed PE# by bypassing the function of >>M64DT. In turn, we just need different phb->init_m64() for P7IOC >>and PHB3 to support M64. > >I thought we decided (Ben suggested?) not to push P7IOC code now (or ever) as >there is no user for it, has this changed? > Remember that the code is mixed for P7IOC/PHB3. It's not harmful to support M64 window on P7IOC, which is much larger than M32. >btw please put ioda1/ioda2/p7ioc/etc to the subject line to make it easier to >see how much work is there about particular PHB type. You rename quite many >functions and I generally want to ask you to group all renaming patches first >but it would also make sense to keep them close to (for example) >p7ioc-related patches so having more descriptive subject lines may help. >Thanks. > As the code is mixed for P7IOC/PHB3, I'm not following the line (IODA1/IODA2/p7ioc/phb3) in this patchset. Instead, the sequence of patchset is order related to: cod refactoring, IO/M32/M64, DMA, PE allocation/releaseing. Thanks, Gavin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This enables M64 window on P7IOC, which has been enabled on PHB3.
>>Different from PHB3 where 16 M64 BARs are supported and each of
>>them can be owned by one particular PE# exclusively or divided
>>evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each
>>of them are divided to 8 segments. So every P7IOC PHB supports
>>128 M64 segments in total. P7IOC has M64DT, which helps mapping
>>one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
>>M64DT, indicating that one M64 segment can only be pinned to the
>>fixed PE#. In order to have same code to support M64 on P7IOC and
>>PHB3, we just provide 128 M64 segments on every P7IOC PHB and each
>>of them is pinned to the fixed PE# by bypassing the function of
>>M64DT. In turn, we just need different phb->init_m64() for P7IOC
>>and PHB3 to support M64.
>>
>>Signed-off-by: Gavin Shan
>>---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 86
>> +--
>> arch/powerpc/platforms/powernv/pci.h | 3 ++
>> 2 files changed, 86 insertions(+), 3 deletions(-)
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>>b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index 1f7d985..bfe69f1 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -256,6 +256,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev
>>*pdev,
>> }
>> }
>>
>>+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
>>+{
>>+ struct resource *r;
>>+ int index;
>>+
>>+ /*
>>+ * There are 16 M64 BARs, each of which has 8 segments. So
>>+ * there are as many M64 segments as the maximum number of
>>+ * PEs, which is 128.
>>+ */
>>+ for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
>>+ unsigned long base, segsz = phb->ioda.m64_segsize;
>>+ int64_t rc;
>>+
>>+ base = phb->ioda.m64_base +
>>+index * PNV_IODA1_M64_SEGS * segsz;
>>+ rc = opal_pci_set_phb_mem_window(phb->opal_id,
>>+ OPAL_M64_WINDOW_TYPE, index, base, 0,
>>+ PNV_IODA1_M64_SEGS * segsz);
>>+ if (rc != OPAL_SUCCESS) {
>>+ pr_warn(" Error %lld setting M64 PHB#%d-BAR#%d\n",
>>+ rc, phb->hose->global_number, index);
>>+ goto fail;
>>+ }
>>+
>>+ rc = opal_pci_phb_mmio_enable(phb->opal_id,
>>+ OPAL_M64_WINDOW_TYPE, index,
>>+ OPAL_ENABLE_M64_SPLIT);
>>+ if (rc != OPAL_SUCCESS) {
>>+ pr_warn(" Error %lld enabling M64 PHB#%d-BAR#%d\n",
>>+ rc, phb->hose->global_number, index);
>>+ goto fail;
>>+ }
>>+ }
>>+
>>+ /*
>>+ * Exclude the segment used by the reserved PE, which
>>+ * is expected to be 0 or last supported PE#.
>>+ */
>>+ r = &phb->hose->mem_resources[1];
>
>
>What does "1" mean here? A bridge's 64bit prefetchable window?
>
It's PHB's M64 window.
>
>>+ if (phb->ioda.reserved_pe_idx == 0)
>>+ r->start += phb->ioda.m64_segsize;
>>+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
>>+ r->end -= phb->ioda.m64_segsize;
>>+ else
>>+ pr_warn(" Cannot cut M64 segment for reserved PE#%d\n",
>>+ phb->ioda.reserved_pe_idx);
>>+
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC
On Mon, Nov 16, 2015 at 07:01:46PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This enables M64 window on P7IOC, which has been enabled on PHB3.
>>Different from PHB3 where 16 M64 BARs are supported and each of
>>them can be owned by one particular PE# exclusively or divided
>>evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each
>>of them are divided to 8 segments. So every P7IOC PHB supports
>>128 M64 segments in total. P7IOC has M64DT, which helps mapping
>>one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
>>M64DT, indicating that one M64 segment can only be pinned to the
>>fixed PE#. In order to have same code to support M64 on P7IOC and
>>PHB3, we just provide 128 M64 segments on every P7IOC PHB and each
>>of them is pinned to the fixed PE# by bypassing the function of
>>M64DT. In turn, we just need different phb->init_m64() for P7IOC
>>and PHB3 to support M64.
>>
>>Signed-off-by: Gavin Shan
>>---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 86
>> +--
>> arch/powerpc/platforms/powernv/pci.h | 3 ++
>> 2 files changed, 86 insertions(+), 3 deletions(-)
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>>b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index 1f7d985..bfe69f1 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -256,6 +256,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev
>>*pdev,
>> }
>> }
>>
>>+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
>>+{
>>+ struct resource *r;
>>+ int index;
>>+
>>+ /*
>>+ * There are 16 M64 BARs, each of which has 8 segments. So
>>+ * there are as many M64 segments as the maximum number of
>>+ * PEs, which is 128.
>>+ */
>>+ for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
>>+ unsigned long base, segsz = phb->ioda.m64_segsize;
>>+ int64_t rc;
>>+
>>+ base = phb->ioda.m64_base +
>>+index * PNV_IODA1_M64_SEGS * segsz;
>>+ rc = opal_pci_set_phb_mem_window(phb->opal_id,
>>+ OPAL_M64_WINDOW_TYPE, index, base, 0,
>>+ PNV_IODA1_M64_SEGS * segsz);
>>+ if (rc != OPAL_SUCCESS) {
>>+ pr_warn(" Error %lld setting M64 PHB#%d-BAR#%d\n",
>>+ rc, phb->hose->global_number, index);
>>+ goto fail;
>>+ }
>>+
>>+ rc = opal_pci_phb_mmio_enable(phb->opal_id,
>>+ OPAL_M64_WINDOW_TYPE, index,
>>+ OPAL_ENABLE_M64_SPLIT);
>>+ if (rc != OPAL_SUCCESS) {
>>+ pr_warn(" Error %lld enabling M64 PHB#%d-BAR#%d\n",
>>+ rc, phb->hose->global_number, index);
>>+ goto fail;
>>+ }
>>+ }
>>+
>>+ /*
>>+ * Exclude the segment used by the reserved PE, which
>>+ * is expected to be 0 or last supported PE#.
>>+ */
>>+ r = &phb->hose->mem_resources[1];
>>+ if (phb->ioda.reserved_pe_idx == 0)
>>+ r->start += phb->ioda.m64_segsize;
>>+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
>>+ r->end -= phb->ioda.m64_segsize;
>>+ else
>>+ pr_warn(" Cannot cut M64 segment for reserved PE#%d\n",
>>+ phb->ioda.reserved_pe_idx);
>>+
>>+ return 0;
>>+
>>+fail:
>>+ for ( ; index >= 0; index--)
>>+ opal_pci_phb_mmio_enable(phb->opal_id,
>>+ OPAL_M64_WINDOW_TYPE, index, OPAL_DISABLE_M64);
>>+
>>+ return -EIO;
>>+}
>>+
>> static void pnv_ioda_reserve_m64_pe(struct pci_bus *bus,
>> unsigned long *pe_bitmap,
>> bool all)
>>@@ -325,6 +383,26 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus,
>>bool all)
>> pe->master = master_pe;
>> list_add_tail(&pe->list, &master_pe->slaves);
>> }
>>+
>>+ /*
>>+ * P7IOC supports M64DT, which helps mapping M64 segment
>>+ * to one particular PE#. However, PHB3 has fixed mapping
>>+ * between M64 segment and PE#. In order to have same logic
>>+ * for P7IOC and PHB3, we enforce fixed mapping between M64
>>+ * segment and PE# on P7IOC.
>>+ */
>>+ if (phb->type == PNV_PHB_IODA1) {
>>+ int64_t rc;
>>+
>>+ rc = opal_pci_map_pe_mmio_window(phb->opal_id,
>>+ pe->pe_number, OPAL_M64_WINDOW_TYPE,
>>+ pe->pe_number / PNV_IODA1_M64_SEGS,
>>+ pe->pe_number % PNV_IODA1_M64_SEGS);
>>+ if (rc != OPAL_SUCCESS)
>>+ pr_warn("%s: Error %lld
Re: [PATCH v7 11/50] powerpc/powernv: IO and M32 mapping based on PCI device resources
On Mon, Nov 16, 2015 at 07:01:43PM +1100, Alexey Kardashevskiy wrote:
>On 11/12/2015 03:55 PM, Gavin Shan wrote:
>>On Thu, Nov 12, 2015 at 02:30:27PM +1100, Daniel Axtens wrote:
>>>Hi Gavin,
>>>
>>>Sorry to have taken so long to resume these reviews!
>>>
>>
>>Thanks for your review, Daniel!
>>
Currently, the IO and M32 segments are mapped to the corresponding
PE based on the windows of the parent bridge of PE's primary bus.
It's not going to work when the windows of root port or upstream
port of the PCIe switch behind root port are extended to PHB's
aperatuses in order to support hotplug in subsequent patch.
>>>I'm not _entirely_ sure I understand this.
>>>
>>>I *think* you mean PHB's apertures (i.e. s/aperatuses/apertures/)?
>>>
>>
>>I'll fix the typo in next revision.
>>
This fixes the issue by mapping IO and M32 segments based on the
resources of the PCI devices included in the PE, instead of the
windows of the parent bridge of the PE's primary bus.
>>>
>>>This solution seems to make a lot of sense, but I don't have a very good
>>>understanding of PCI yet: why was it done that way and not this way
>>>originally? Looking at the code, it looks like the old way was simple
>>>but didn't support SR-IOV?
>>>
>>
>>It's not related to SRIOV. Originally, the IO or M32 segments are mapped
>>according to the bridge's windows.
>
>
>Sorry, I do not understand what this means...
>
Before this patchset, the IO or M32 segments consumed by one PE are mapped
according to the windows of PCI bridge of the PE's primary bus if the PE
isn't including all subordinate PCI buses orginated from the bridge. Otherwise,
the bridge's windows should be taken into account as well.
>
>>The bridge windows on root port or the
>>upstream port of the switch behind that will be extended to PHB's apertures.
>
>What does "extended" mean here and why would the windows be extended anyway?
>
It's reserving IO or memory resource for possible plugged adapters in the
future.
>>If we still use bridge's windows, all IO and M32 resources are mapped/assigned
>>to the PE corresponding to PCI bus#1 or PCI bus#2. That's not correct any
>>more.
>>So the correct way is to do the mapping based on IO or M32 BARs of the devices
>>included in the PE.
>
>In this patch I see quite a lot of code movements and I fail to spot the
>actual change here...
>
>
>It used to be a single loop:
>
>pci_bus_for_each_resource(pe->pbus, res, i) {
> /* do stuff for each @res */
>}
>
>and now it is 2 loops inside another loop:
>
>list_for_each_entry(pdev, &pe->pbus->devices, bus_list) {
> for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
> res = &pdev->resource[i];
> /* do stuff for each @res */
> }
>
> for (i = 0; i <= PCI_BRIDGE_RESOURCE_NUM; i++) {
> res = &pdev->resource[PCI_BRIDGE_RESOURCES + i];
> /* do stuff for each @res */
> }
>}
>
>
>Is that correct? If yes, why is not the patch as simple as this? If no, what
>did I miss?
>
That's correct. The resource tracked by the PCI bridge windows can belonged
to another PE instead the one tracked by @pe in the code.
>
>
>>
>>>There are a few comments inline as well.
>>>
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 553d3f3..4ab93f8 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2741,71 +2741,90 @@ truncate_iov:
}
#endif /* CONFIG_PCI_IOV */
-/*
- * This function is supposed to be called on basis of PE from top
- * to bottom style. So the the I/O or MMIO segment assigned to
- * parent PE could be overrided by its child PEs if necessary.
- */
-static void pnv_ioda_setup_pe_seg(struct pci_controller *hose,
- struct pnv_ioda_pe *pe)
+static int pnv_ioda_setup_one_res(struct pnv_ioda_pe *pe,
+ struct resource *res)
{
- struct pnv_phb *phb = hose->private_data;
+ struct pnv_phb *phb = pe->phb;
struct pci_bus_region region;
- struct resource *res;
- unsigned int segsize;
- int *segmap, index, i;
+ unsigned int index, segsize;
+ int *segmap;
uint16_t win;
int64_t rc;
>>>
>>>s/int64_t/s64/;
>>>I think we might also want to change the uint16_t as well.
>>>
>>
>>As I explained before, I changed it from s64 to int64_t and I won't change it
>>back since both of them are fine. Same situation to uint16 here. If we really
>>want to clean it all at once, I can do that later, but not in this patchset.
>>
- /*
-* NOTE: We only care PCI bus based PE for now. For PCI
-* device based PE, for example SRIOV sensitive VF should
-* be figured out later.
-*/
- BUG_ON(!(pe->flags & (PNV_IODA_PE_BUS | PNV_IODA_PE_BUS_ALL)));
+ if (!res->parent || !res->flags || res->start > res
Re: [PATCH v7 08/50] powerpc/powernv: Rename PE# fields in struct pnv_phb
On Mon, Nov 16, 2015 at 07:01:06PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This renames the fields related to PE number in "struct pnv_phb"
>>for better reflecting of their usages as Alexey suggested. No
>>logical changes introduced.
>>
>>Signed-off-by: Gavin Shan
>>---
>> arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
>> arch/powerpc/platforms/powernv/pci-ioda.c| 56
>> ++--
>> arch/powerpc/platforms/powernv/pci.c | 2 +-
>> arch/powerpc/platforms/powernv/pci.h | 4 +-
>> 4 files changed, 32 insertions(+), 32 deletions(-)
>>
>>diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
>>b/arch/powerpc/platforms/powernv/eeh-powernv.c
>>index e1c9072..861a7d2 100644
>>--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
>>+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
>>@@ -75,7 +75,7 @@ static int pnv_eeh_init(void)
>> * and P7IOC separately. So we should regard
>> * PE#0 as valid for PHB3 and P7IOC.
>> */
>>- if (phb->ioda.reserved_pe != 0)
>>+ if (phb->ioda.reserved_pe_idx != 0)
>> eeh_add_flag(EEH_VALID_PE_ZERO);
>>
>> break;
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>>b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index 968da91..b4932c3 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -134,7 +134,7 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
>>flags)
>>
>> static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
>> {
>>- if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe)) {
>>+ if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
>> pr_warn("%s: Invalid PE %d on PHB#%x\n",
>> __func__, pe_no, phb->hose->global_number);
>> return;
>>@@ -154,8 +154,8 @@ static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
>>
>> do {
>> pe = find_next_zero_bit(phb->ioda.pe_alloc,
>>- phb->ioda.total_pe, 0);
>>- if (pe >= phb->ioda.total_pe)
>>+ phb->ioda.total_pe_num, 0);
>>+ if (pe >= phb->ioda.total_pe_num)
>> return IODA_INVALID_PE;
>> } while(test_and_set_bit(pe, phb->ioda.pe_alloc));
>>
>>@@ -209,13 +209,13 @@ static int pnv_ioda2_init_m64(struct pnv_phb *phb)
>> * expected to be 0 or last one of PE capabicity.
>> */
>> r = &phb->hose->mem_resources[1];
>>- if (phb->ioda.reserved_pe == 0)
>>+ if (phb->ioda.reserved_pe_idx == 0)
>> r->start += phb->ioda.m64_segsize;
>>- else if (phb->ioda.reserved_pe == (phb->ioda.total_pe - 1))
>>+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
>> r->end -= phb->ioda.m64_segsize;
>> else
>> pr_warn(" Cannot strip M64 segment for reserved PE#%d\n",
>>- phb->ioda.reserved_pe);
>>+ phb->ioda.reserved_pe_idx);
>>
>> return 0;
>>
>>@@ -284,7 +284,7 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus,
>>bool all)
>> return IODA_INVALID_PE;
>>
>> /* Allocate bitmap */
>>- size = _ALIGN_UP(phb->ioda.total_pe / 8, sizeof(unsigned long));
>>+ size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
>> pe_alloc = kzalloc(size, GFP_KERNEL);
>> if (!pe_alloc) {
>> pr_warn("%s: Out of memory !\n",
>>@@ -300,7 +300,7 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus,
>>bool all)
>> * contributed by its child buses. For the case, we needn't
>> * pick M64 dependent PE#.
>> */
>>- if (bitmap_empty(pe_alloc, phb->ioda.total_pe)) {
>>+ if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num)) {
>> kfree(pe_alloc);
>> return IODA_INVALID_PE;
>> }
>>@@ -311,8 +311,8 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus,
>>bool all)
>> */
>> master_pe = NULL;
>> i = -1;
>>- while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe, i + 1)) <
>>- phb->ioda.total_pe) {
>>+ while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe_num, i + 1)) <
>>+ phb->ioda.total_pe_num) {
>> pe = &phb->ioda.pe_array[i];
>>
>> if (!master_pe) {
>>@@ -364,7 +364,7 @@ static void __init pnv_ioda_parse_m64_window(struct
>>pnv_phb *phb)
>> hose->mem_offset[1] = res->start - pci_addr;
>>
>> phb->ioda.m64_size = resource_size(res);
>>- phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe;
>>+ phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe_num;
>> phb->ioda.m64_base = pci_addr;
>>
>> pr_info(" MEM64 0x%016llx..0x%016llx -> 0x%016llx\n",
>>@@ -465,7 +465,7 @@ static int pnv_ioda_get_pe_state(struct pnv_phb *phb, int
>>pe_no)
>> s64 rc;
>>
>> /* Sanit
Re: [PATCH v7 12/50] powerpc/powernv: Track M64 segment consumption
On Mon, Nov 16, 2015 at 07:01:59PM +1100, Alexey Kardashevskiy wrote: >On 11/05/2015 12:12 AM, Gavin Shan wrote: >>As we track M32 segment consumption, this introduces an array to >>the PHB to track the mapping between M64 segment and PE number. >>The information is going to be used to find M64 segment from the >>PE number during PCI unplugging time in subsequent patches. > > >It would not hurt to put a few words about how we managed to live without >such a mapping for M64 before but we needed mapping for M32. > The M32 mapping (phb->ioda.m32_segmap[]) isn't used for anything before this patcheset. There're no need for M64 mapping before this patchset similarly, no need to add the words. Thanks, Gavin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/50] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg()
On Mon, Nov 16, 2015 at 07:01:18PM +1100, Alexey Kardashevskiy wrote: >On 11/06/2015 10:52 AM, Gavin Shan wrote: >>On Fri, Nov 06, 2015 at 09:56:06AM +1100, Daniel Axtens wrote: >>>Gavin Shan writes: >>> The original implementation of pnv_ioda_setup_pe_seg() configures IO and M32 segments by separate logics, which can be merged by by caching @segmap, @seg_size, @win in advance. This shouldn't cause any behavioural changes. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/pci-ioda.c | 62 ++- 1 file changed, 28 insertions(+), 34 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 7ee7cfe..553d3f3 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -2752,8 +2752,10 @@ static void pnv_ioda_setup_pe_seg(struct pci_controller *hose, struct pnv_phb *phb = hose->private_data; struct pci_bus_region region; struct resource *res; - int i, index; - int rc; + unsigned int segsize; + int *segmap, index, i; + uint16_t win; + int64_t rc; >>> >>>Good catch! Opal return codes are 64 bit and that should be explicit >>>in the type. However, I seem to remember that we preferred a different >>>type for 64 bit ints in the kernel. I think it's s64, and there are some >>>other uses of that in pci_ioda.c for return codes. >>> >> >>Both int64_t and s64 are fine. I used s64 for the OPAL return value, but >>Alexey likes "int64_t", which is ok to me as well. I won't change it back >>to s64 :-) >> >>>(I'm actually surprised that's not picked up as a compiler >>>warning. Maybe that's something to look at in future.) >>> >> >>Indeed, I didn't see a warning from gcc. >> >>>The rest of the patch looks good on casual inspection - to be sure I'll >>>test the entire series on a machine. (hopefully, time permitting!) >>> >> >>I run scripts/checkpatch.pl on the patchset. Only one warning came from >>[PATCH 44/50], but I won't bother to change that as the warning was >>brought by original code. > >None of these patches failed checkpatch.pl check, what was the error in 44/50? > You're right that none of those patches failed with checkpatch.pl. I had revison 6.1, 6.2, 6.3 before this revision (v7) was posted. There was a warning for 44/50 in 6.3 (perhaps). I run checkpatch.pl on all (v7) patches, no warning reported. Thanks, Gavin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 17/50] powerpc/powernv: Avoid calculating DMA32 segments on PHB3
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In pnv_ioda_setup_dma(), it's unnecessary to calculate the DMA32
segments for PEs on PHB3 as the whole available DMA32 space can
be assigned to one specific PE on PHB3.
This splits pnv_ioda_setup_dma() to pnv_pci_ioda1_setup_dma() and
pnv_pci_ioda2_setup_dma() in order to avoid calculating DMA32
segments for PEs on PHB3. No logical changes introduced.
This patch is not needed as
[PATCH v7 20/50] powerpc/powernv: Improve DMA32 segment calculation
moves this calculation to another place (which already makes this patch
unnecessary) and
[PATCH v7 26/50] powerpc/powernv: Create PEs at PCI hot plugging time
removes just introduced pnv_pci_ioda1_setup_dma() - if you remove it, then
there is no point in fixing it in the first place.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 41 ++-
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5a08e20..4c2e023 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2383,7 +2383,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
pnv_ioda_setup_bus_dma(pe, pe->pbus);
}
-static void pnv_ioda_setup_dma(struct pnv_phb *phb)
+static void pnv_pci_ioda1_setup_dma(struct pnv_phb *phb)
{
struct pci_controller *hose = phb->hose;
unsigned int residual, remaining, segs, tw, base;
@@ -2428,26 +2428,30 @@ static void pnv_ioda_setup_dma(struct pnv_phb *phb)
segs = remaining;
}
- /*
-* For IODA2 compliant PHB3, we needn't care about the weight.
-* The all available 32-bits DMA space will be assigned to
-* the specific PE.
-*/
- if (phb->type == PNV_PHB_IODA1) {
- pe_info(pe, "DMA weight %d, assigned %d DMA32
segments\n",
- pe->dma_weight, segs);
- pnv_pci_ioda1_setup_dma_pe(phb, pe, base, segs);
- } else {
- pe_info(pe, "Assign DMA32 space\n");
- segs = 0;
- pnv_pci_ioda2_setup_dma_pe(phb, pe);
- }
+ pe_info(pe, "DMA weight %d, assigned %d DMA32 segments\n",
+ pe->dma_weight, segs);
+ pnv_pci_ioda1_setup_dma_pe(phb, pe, base, segs);
remaining -= segs;
base += segs;
}
}
+static void pnv_pci_ioda2_setup_dma(struct pnv_phb *phb)
+{
+ struct pnv_ioda_pe *pe;
+
+ pnv_pci_ioda_setup_opal_tce_kill(phb);
+
+ list_for_each_entry(pe, &phb->ioda.pe_dma_list, dma_link) {
+ if (!pe->dma_weight)
+ continue;
+
+ pe_info(pe, "Assign DMA32 space\n");
+ pnv_pci_ioda2_setup_dma_pe(phb, pe);
+ }
+}
+
#ifdef CONFIG_PCI_MSI
static void pnv_ioda2_msi_eoi(struct irq_data *d)
{
@@ -2931,10 +2935,13 @@ static void pnv_pci_ioda_setup_DMA(void)
struct pnv_phb *phb;
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
- pnv_ioda_setup_dma(hose->private_data);
+ phb = hose->private_data;
+ if (phb->type == PNV_PHB_IODA1)
+ pnv_pci_ioda1_setup_dma(phb);
+ else
+ pnv_pci_ioda2_setup_dma(phb);
/* Mark the PHB initialization done */
- phb = hose->private_data;
phb->initialized = 1;
}
}
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] staging: ion: Add files for parsing the devicetree
Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This is a set of functions for drivers to call to parse the Ion
devicetree along with definitons for defining heaps.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig | 10 +++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion_of.c | 168 +++
drivers/staging/android/ion/ion_of.h | 35
4 files changed, 214 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_of.c
create mode 100644 drivers/staging/android/ion/ion_of.h
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 3452346..9b6d65d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,13 @@ config ION_TEGRA
help
Choose this option if you wish to use ion on an nVidia Tegra.
+config ION_OF
+ bool "Devicetree support for Ion"
+ depends on ION && OF
+ help
+ Provides base support for defining Ion heaps in devicetree
+ and setting them up. Also includes functions for platforms
+ to parse the devicetree and expand for their own custom
+ extensions
+
+ If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index b56fd2b..a77417b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -7,4 +7,5 @@ endif
obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
obj-$(CONFIG_ION_TEGRA) += tegra/
+obj-$(CONFIG_ION_OF) += ion_of.o ion_physmem.o
diff --git a/drivers/staging/android/ion/ion_of.c
b/drivers/staging/android/ion/ion_of.c
new file mode 100644
index 000..9a56194
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.c
@@ -0,0 +1,168 @@
+/*
+ * Based on work from:
+ * Andrew Andrianov
+ * Google
+ * The Linux Foundation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ion.h"
+#include "ion_priv.h"
+#include "ion_of.h"
+
+int ion_parse_dt_heap_common(struct device_node *heap_node,
+ struct ion_platform_heap *heap,
+ struct ion_of_heap *compatible)
+{
+ int i;
+
+ for (i = 0; compatible[i].name != NULL; i++) {
+ if (of_device_is_compatible(heap_node, compatible[i].compat))
+ break;
+ }
+
+ if (compatible[i].name == NULL)
+ return -ENODEV;
+
+ heap->id = compatible[i].heap_id;
+ heap->type = compatible[i].type;
+ heap->name = compatible[i].name;
+ heap->align = compatible[i].align;
+
+ /* Some kind of callback function pointer? */
+
+ pr_info("%s: id %d type %d name %s align %lx\n", __func__,
+ heap->id, heap->type, heap->name, heap->align);
+ return 0;
+}
+
+int ion_setup_heap_common(struct platform_device *parent,
+ struct device_node *heap_node,
+ struct ion_platform_heap *heap)
+{
+ int ret = 0;
+
+ switch (heap->type) {
+ case ION_HEAP_TYPE_CARVEOUT:
+ case ION_HEAP_TYPE_CHUNK:
+ if (heap->base && heap->size)
+ return 0;
+
+ ret = of_reserved_mem_device_init(heap->priv);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
+ struct ion_of_heap *compatible)
+{
+ int num_heaps, ret;
+ const struct device_node *dt_node = pdev->dev.of_node;
+ struct device_node *node;
+ struct ion_platform_heap *heaps;
+ struct ion_platform_data *data;
+ int i = 0;
+
+ num_heaps = of_get_available_child_count(dt_node);
+
+ if (!num_heaps)
+ return ERR_PTR(-EINVAL);
+
+ heaps = devm_kzalloc(&pdev->dev,
+ sizeof(struct ion_platform_heap)*num_heaps,
+ GFP_KERNEL);
+ if (!heaps)
+ return ERR_PTR(-ENOMEM);
+
+ data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
+ GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ for_each_available_child_of_node(dt_node, node) {
+ struct platform_device *heap_pdev;
+
+ ret = ion_parse_dt_heap_common(node, &heaps[i], compatible);
+ if (ret)
+
[PATCHv2 3/3] NOMERGE: Sample driver
Small sample driver to show what setup would look like with the dt
bindings
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig | 6 ++
drivers/staging/android/ion/Makefile| 1 +
drivers/staging/android/ion/ion_of_sample.c | 96 +
3 files changed, 103 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_of_sample.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 9b6d65d..c2afb35 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -43,3 +43,9 @@ config ION_OF
extensions
If using Ion and devicetree, you should say Y here
+
+config ION_OF_SAMPLE
+ bool "Sample driver"
+ depends on ION_OF
+ help
+ Small sample driver showing the Ion OF interface
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index a77417b..1309b91 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -8,4 +8,5 @@ endif
obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
obj-$(CONFIG_ION_TEGRA) += tegra/
obj-$(CONFIG_ION_OF) += ion_of.o ion_physmem.o
+obj-$(CONFIG_ION_OF_SAMPLE) += ion_of_sample.o
diff --git a/drivers/staging/android/ion/ion_of_sample.c
b/drivers/staging/android/ion/ion_of_sample.c
new file mode 100644
index 000..bbcdf4d
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of_sample.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2015 RC Module
+ * Andrew Andrianov
+ * Also based on work from Google, The Linux Foundation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ion.h"
+#include "ion_priv.h"
+#include "ion_of.h"
+
+struct sample_ion_dev {
+struct ion_heap **heaps;
+struct ion_device *idev;
+};
+
+static struct ion_of_heap heaps[] = {
+ PLATFORM_HEAP("sample-system", 0, ION_HEAP_TYPE_SYSTEM, "system"),
+ PLATFORM_HEAP("sample-camera", 1, ION_HEAP_TYPE_DMA, "camera"),
+ PLATFORM_HEAP("sample-fb", 2, ION_HEAP_TYPE_DMA, "fb"),
+ {}
+};
+
+static int ion_sample_probe(struct platform_device *pdev)
+{
+ struct ion_platform_data *data;
+ struct sample_ion_dev *ipdev;
+ int i;
+
+ ipdev = devm_kzalloc(&pdev->dev, sizeof(*ipdev), GFP_KERNEL);
+ if (!ipdev)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ipdev);
+
+ ipdev->idev = ion_device_create(NULL);
+ if (!ipdev->idev)
+ return -ENOMEM;
+
+ data = ion_parse_dt(pdev, heaps);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ ipdev->heaps = devm_kzalloc(&pdev->dev,
+ sizeof(struct ion_heap)*data->nr, GFP_KERNEL);
+
+ if (!ipdev->heaps)
+ return -ENOMEM;
+
+ for (i = 0; i < data->nr; i++) {
+ ipdev->heaps[i] = ion_heap_create(&data->heaps[i]);
+ if (!ipdev->heaps[i])
+ return -ENOMEM;
+ ion_device_add_heap(ipdev->idev, ipdev->heaps[i]);
+ }
+ return 0;
+}
+
+static int ion_sample_remove(struct platform_device *pdev)
+{
+ /* Everything should be devm */
+ return 0;
+}
+
+static const struct of_device_id of_match_table[] = {
+ { .compatible = "sample-ion", },
+ { /* end of list */ }
+};
+
+static struct platform_driver ion_sample_driver = {
+ .probe = ion_sample_probe,
+ .remove = ion_sample_remove,
+ .driver = {
+ .name = "ion-of",
+ .of_match_table = of_match_ptr(of_match_table),
+ },
+};
+
+static int __init ion_sample_init(void)
+{
+ return platform_driver_register(&ion_sample_driver);
+}
+device_initcall(ion_sample_init);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] Devicetree bindings for Ion
Hi, This is another attempt at devicetree bindings for Ion. The big complaint from v1 was that too much unnecessary data was being pushed into devicetree. v2 takes a different approach of using just compatbile strings for the heaps. This gets closer to the devicetree philosophy of describing just the hardware. Each heap ultimately represents some kind of memory that exists in the system. The compatible string indicates the match for how to handle the type of memory on this system. The details like heap-id, name etc. are now pushed out to C files. This makes Ion heaps look closer to something like a quirks framework. (I'd argue this isn't a complete mischaracterization given the type of setup Ion gets used for...) The one downside here is that this leads to more new bindings for each board that gets added. This version also includes a sample C file which shows what the structure might look like. As always, your comments and reviews are appreciated. Thanks, Laura Laura Abbott (3): ion: Devicetree bindings for Ion staging: ion: Add files for parsing the devicetree (WIP) NOMERGE: Sample driver drivers/staging/android/ion/Kconfig | 16 +++ drivers/staging/android/ion/Makefile| 2 + drivers/staging/android/ion/devicetree.txt | 50 + drivers/staging/android/ion/ion_of.c| 168 drivers/staging/android/ion/ion_of.h| 35 ++ drivers/staging/android/ion/ion_of_sample.c | 96 6 files changed, 367 insertions(+) create mode 100644 drivers/staging/android/ion/devicetree.txt create mode 100644 drivers/staging/android/ion/ion_of.c create mode 100644 drivers/staging/android/ion/ion_of.h create mode 100644 drivers/staging/android/ion/ion_of_sample.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] ion: Devicetree bindings for Ion
This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/devicetree.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 drivers/staging/android/ion/devicetree.txt
diff --git a/drivers/staging/android/ion/devicetree.txt
b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 000..e1ea537
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,50 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion" PLUS a compatible property for the device
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- compatible: compatible string for a heap type PLUS a compatible property
+for the specific instance of the heap. Current heap types
+-- linux,ion-heap-system
+-- linux,ion-heap-system-contig
+-- linux,ion-heap-carveout
+-- linux,ion-heap-chunk
+-- linux,ion-heap-dma
+-- linux,ion-heap-custom
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+
+Example:
+
+ ion {
+ compatbile = "qcom,msm8916-ion", "linux,ion";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ion-system-heap {
+ compatbile = "qcom,system-heap", "linux,ion-heap-system"
+ };
+
+ ion-camera-region {
+ compatible = "qcom,camera-heap", "linux,ion-heap-dma"
+ memory-region = <&camera_region>;
+ };
+
+ ion-fb-region {
+ compatbile = "qcom,fb-heap", "linux,ion-heap-dma"
+ memory-region = <&fb_region>;
+ };
+ }
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 22/50] powerpc/powernv: Introduce pnv_ioda_init_pe()
Gavin Shan writes:
> This introduces pnv_ioda_init_pe() to initialize the specified PE
> instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
> and pnv_ioda_reserve_pe(). No logical changes introduced.
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index ef93a01..488e0f8 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -129,6 +129,14 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
> flags)
> (IORESOURCE_MEM_64 | IORESOURCE_PREFETCH));
> }
>
> +static struct pnv_ioda_pe *pnv_ioda_init_pe(struct pnv_phb *phb, int pe_no)
> +{
> + phb->ioda.pe_array[pe_no].phb = phb;
> + phb->ioda.pe_array[pe_no].pe_number = pe_no;
> +
> + return &phb->ioda.pe_array[pe_no];
You have the function returning the newly initalized PE here...
> +}
> +
> static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
> {
> if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
> @@ -141,8 +149,7 @@ static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int
> pe_no)
> pr_debug("%s: PE %d was reserved on PHB#%x\n",
>__func__, pe_no, phb->hose->global_number);
>
> - phb->ioda.pe_array[pe_no].phb = phb;
> - phb->ioda.pe_array[pe_no].pe_number = pe_no;
> + pnv_ioda_init_pe(phb, pe_no);
... but then you ignore the result here and in the other function you've
modified.
It looks like you're using the result in the next patch though, so I
wonder if you would be better to merge this patch with the next
one. However, as I said before I'll defer to Alexey on decisions about
how to split the patch series if he has a different opinion.
Regards,
Daniel
signature.asc
Description: PGP signature
Re: [PATCH v7 21/50] powerpc/powernv: Increase PE# capacity
Gavin Shan writes:
> Each PHB maintains an array helping to translate 2-bytes Request
> ID (RID) to PE# with the assumption that PE# takes one byte, meaning
> that we can't have more than 256 PEs. However, pci_dn->pe_number
> already had 4-bytes for the PE#.
>
> This extends the PE# capacity so that each of them will be 4-bytes
> long. Then we can reuse IODA_INVALID_PE to check the PE# stored in
> phb->pe_rmap[] is valid or not.
Just for clarity, could you make it clear in the commit message that
you're increasing the PE# capacity _in the PHB_? I just found it a bit
confusing the first time I read it.
With that clarified I'll be happy to add my reviewed-by tag.
Regards,
Daniel
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 6 +-
> arch/powerpc/platforms/powernv/pci.h | 7 ++-
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 0e66c4d..ef93a01 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -766,7 +766,7 @@ static int pnv_ioda_deconfigure_pe(struct pnv_phb *phb,
> struct pnv_ioda_pe *pe)
>
> /* Clear the reverse map */
> for (rid = pe->rid; rid < rid_end; rid++)
> - phb->ioda.pe_rmap[rid] = 0;
> + phb->ioda.pe_rmap[rid] = IODA_INVALID_PE;
>
> /* Release from all parents PELT-V */
> while (parent) {
> @@ -3164,6 +3164,10 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> if (prop32)
> phb->ioda.reserved_pe_idx = be32_to_cpup(prop32);
>
> + /* Invalidate RID to PE# mapping */
> + for (i = 0; i < ARRAY_SIZE(phb->ioda.pe_rmap); ++i)
> + phb->ioda.pe_rmap[i] = IODA_INVALID_PE;
> +
> /* Parse 64-bit MMIO range */
> pnv_ioda_parse_m64_window(phb);
>
> diff --git a/arch/powerpc/platforms/powernv/pci.h
> b/arch/powerpc/platforms/powernv/pci.h
> index 0802fcd..5df945f 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -162,11 +162,8 @@ struct pnv_phb {
> struct list_headpe_list;
> struct mutexpe_list_mutex;
>
> - /* Reverse map of PEs, will have to extend if
> - * we are to support more than 256 PEs, indexed
> - * bus { bus, devfn }
> - */
> - unsigned char pe_rmap[0x1];
> + /* Reverse map of PEs, indexed by {bus, devfn} */
> + int pe_rmap[0x1];
>
> /* TCE cache invalidate registers (physical and
>* remapped)
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: PGP signature
Re: [PATCH v7 19/50] powerpc/powernv: Track DMA32 segment consumption
Gavin Shan writes:
> Similar to the mechanism tracking consumed IO/M32/M64 segments,
> this introduces an array for each PHB to track the consumed DMA32
> segments, which are going to be released on PCI unplugging time.
> The index of the array is the DMA32 segment number while the value
> stored in the element is the assigned PE number.
>
> + /* Setup TCE32 segment mapping */
Do you mean DMA32 rather than TCE32?
> + for (i = base; i < base + segs; i++)
> + phb->ioda.dma32_segmap[i] = pe->pe_number;
> +
I'm pretty sure this is right, but can you just confirm that you
intended to index into the array starting at base and going to base + segs,
and not going from 0 to segs? (i.e. not dma32_segmap[i - base]).
Otherwise looks good.
Regards,
Daniel
> /* Setup linux iommu table */
> pnv_pci_setup_iommu_table(tbl, addr, tce32_segsz * segs,
> base * PNV_IODA1_DMA32_SEGSIZE,
> @@ -2378,13 +2382,13 @@ static void pnv_pci_ioda1_setup_dma(struct pnv_phb
> *phb)
>* then we assign at least one segment per PE, plus more based
>* on the amount of devices under that PE
>*/
> - if (dma_pe_count > phb->ioda.tce32_count)
> + if (dma_pe_count > phb->ioda.dma32_count)
> residual = 0;
> else
> - residual = phb->ioda.tce32_count - dma_pe_count;
> + residual = phb->ioda.dma32_count - dma_pe_count;
>
> pr_info("PCI: Domain %04x has %ld available 32-bit DMA segments\n",
> - hose->global_number, phb->ioda.tce32_count);
> + hose->global_number, phb->ioda.dma32_count);
> pr_info("PCI: %d PE# for a total weight of %d\n",
> dma_pe_count, total_weight);
>
> @@ -2394,7 +2398,7 @@ static void pnv_pci_ioda1_setup_dma(struct pnv_phb *phb)
>* out one base segment plus any residual segments based on
>* weight
>*/
> - remaining = phb->ioda.tce32_count;
> + remaining = phb->ioda.dma32_count;
> base = 0;
> list_for_each_entry(pe, &phb->ioda.pe_list, list) {
> weight = pnv_pci_ioda_pe_dma_weight(pe);
> @@ -3094,7 +3098,8 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> {
> struct pci_controller *hose;
> struct pnv_phb *phb;
> - unsigned long size, m64map_off, m32map_off, pemap_off, iomap_off = 0;
> + unsigned long size, m64map_off, m32map_off, pemap_off;
> + unsigned long iomap_off = 0, dma32map_off = 0;
> const __be64 *prop64;
> const __be32 *prop32;
> int i, len;
> @@ -3177,6 +3182,10 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> phb->ioda.io_segsize = phb->ioda.io_size / phb->ioda.total_pe_num;
> phb->ioda.io_pci_base = 0; /* XXX calculate this ? */
>
> + /* Calculate how many 32-bit TCE segments we have */
> + phb->ioda.dma32_count = phb->ioda.m32_pci_base /
> + PNV_IODA1_DMA32_SEGSIZE;
> +
> /* Allocate aux data & arrays. We don't have IO ports on PHB3 */
> size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
> m64map_off = size;
> @@ -3186,6 +3195,9 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> if (phb->type == PNV_PHB_IODA1) {
> iomap_off = size;
> size += phb->ioda.total_pe_num * sizeof(phb->ioda.io_segmap[0]);
> + dma32map_off = size;
> + size += phb->ioda.dma32_count *
> + sizeof(phb->ioda.dma32_segmap[0]);
> }
> pemap_off = size;
> size += phb->ioda.total_pe_num * sizeof(struct pnv_ioda_pe);
> @@ -3201,6 +3213,10 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> phb->ioda.io_segmap = aux + iomap_off;
> for (i = 0; i < phb->ioda.total_pe_num; i++)
> phb->ioda.io_segmap[i] = IODA_INVALID_PE;
> +
> + phb->ioda.dma32_segmap = aux + dma32map_off;
> + for (i = 0; i < phb->ioda.dma32_count; i++)
> + phb->ioda.dma32_segmap[i] = IODA_INVALID_PE;
> }
> phb->ioda.pe_array = aux + pemap_off;
> set_bit(phb->ioda.reserved_pe_idx, phb->ioda.pe_alloc);
> @@ -3208,10 +3224,6 @@ static void __init pnv_pci_init_ioda_phb(struct
> device_node *np,
> INIT_LIST_HEAD(&phb->ioda.pe_list);
> mutex_init(&phb->ioda.pe_list_mutex);
>
> - /* Calculate how many 32-bit TCE segments we have */
> - phb->ioda.tce32_count = phb->ioda.m32_pci_base /
> - PNV_IODA1_DMA32_SEGSIZE;
> -
> #if 0 /* We should really do that ... */
> rc = opal_pci_set_phb_mem_window(opal->phb_id,
>window_type,
> diff --git a/arch/powerpc/platforms/powernv/pci.h
> b/arch/powerpc/platforms/powernv/pci.h
> index 2038ef2..0802fcd 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.
Re: [PATCH 1/2] Documentation: DT: Add entry for ARM SP805-WDT
On Mon, Nov 16, 2015 at 02:45:25PM +, Mark Rutland wrote: > On Mon, Nov 16, 2015 at 07:54:42PM +0530, Bhupesh Sharma wrote: > > This patch adds a devicetree binding documentation for ARM's > > SP805 WatchDog Timer. > > > > Signed-off-by: Bhupesh Sharma > > --- > > .../devicetree/bindings/watchdog/sp805-wdt.txt | 33 > > > > 1 file changed, 33 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt > > > > diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt > > b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt > > new file mode 100644 > > index 000..ec70fe9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt > > @@ -0,0 +1,33 @@ > > +* ARM SP805 Watchdog Timer (WDT) Controller > > + > > +SP805 WDT is a ARM Primecell Peripheral and has a standard-id register that > > +can be used to identify the peripheral type, vendor, and revision. > > +This value can be used for driver matching. > > + > > +Note that the current sp805_wdt driver relies on the 'drivers/amba/bus.c' > > +framework to invoke the probe function of the sp805_wdt driver using the > > +unique PRIMECELL identifiers of the sp805 wdt IP. > > This paragraph can go. We shouldn't describe kernel internals. > > > +As SP805 WDT is a primecell IP, it follows the base bindings specified in > > +'arm/primecell.txt' > > + > > +Required properties: > > +- compatible : Should be "arm,sp805-wdt", "arm,primecell" > > +- reg : Base address and size of the watchdog timer registers. > > +- interrupts : Should specify WDT interrupt number. > > + > > +Optional properties: > > +- clocks : From common clock binding. First clock is phandle to clock for > > apb > > + pclk. Additional clocks are optional. > > +- clock-names : From common clock binding. Shall be "apb_pclk" for first > > clock. > > The hardware has "WDOGCLK", which is what the driver appears to expect > first implicitly. The h/w has 2 clocks, PCLK and WDOGCLK, so both should be described and neither should be optional. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pstore-ram: add Device Tree bindings
ramoops is one of the remaining places where ARM vendors still rely on
board-specific shims. Device Tree lets us replace those shims with
generic code.
These bindings mirror the ramoops module parameters, with two small
differences:
(1) dump_oops becomes an optional "no-dump-oops" property, since ramoops
sets dump_oops=1 by default.
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
Signed-off-by: Greg Hackmann
---
Changes in V2:
- make DT binding documentation more generic
Documentation/devicetree/bindings/misc/ramoops.txt | 40
Documentation/ramoops.txt | 6 +-
fs/pstore/ram.c| 110 -
3 files changed, 152 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/ramoops.txt
diff --git a/Documentation/devicetree/bindings/misc/ramoops.txt
b/Documentation/devicetree/bindings/misc/ramoops.txt
new file mode 100644
index 000..96c082b
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ramoops.txt
@@ -0,0 +1,40 @@
+Ramoops oops/panic logger
+=
+
+ramoops provides persistent RAM storage for oops and panics, so they can be
+recovered after a reboot.
+
+Parts of this storage may be set aside for other persistent log buffers, such
+as kernel log messages, or for optional ECC error-correction data. The total
+size of these optional buffers must fit in the reserved region. Any remaining
+space will be used for oops and panics.
+
+
+Required properties:
+
+- compatible: must be "ramoops"
+
+- memory-region: phandle to a region of memory that is preserved between
reboots
+
+
+Optional properties:
+
+- ecc-size: enables ECC support and specifies ECC buffer size in bytes
+ (defaults to no ECC)
+
+- record-size: maximum size in bytes of each dump done on oops/panic
+ (defaults to 0)
+
+- console-size: size in bytes of log buffer reserved for kernel messages
+ (defaults to 0)
+
+- ftrace-size: size in bytes of log buffer reserved for function tracing and
+ profiling (defaults to 0)
+
+- pmsg-size: size in bytes of log buffer reserved for userspace messages
+ (defaults to 0)
+
+- unbuffered: if present, use uncached mappings to map the reserved region
+ (defaults to cached mappings)
+
+- no-dump-oops: if present, only dump panics (defaults to panics and oops)
diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 5d86756..9264bca 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -45,7 +45,7 @@ corrupt, but usually it is restorable.
2. Setting the parameters
-Setting the ramoops parameters can be done in 2 different manners:
+Setting the ramoops parameters can be done in 3 different manners:
1. Use the module parameters (which have the names of the variables described
as before).
For quick debugging, you can also reserve parts of memory during boot
@@ -54,7 +54,9 @@ Setting the ramoops parameters can be done in 2 different
manners:
kernel to use only the first 128 MB of memory, and place ECC-protected ramoops
region at 128 MB boundary:
"mem=128M ramoops.mem_address=0x800 ramoops.ecc=1"
- 2. Use a platform device and set the platform data. The parameters can then
+ 2. Use Device Tree bindings, as described in
+ Documentation/device-tree/bindings/misc/ramoops.txt.
+ 3. Use a platform device and set the platform data. The parameters can then
be set through that platform data. An example of doing that is:
#include
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 319c3a6..ac29543 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#define RAMOOPS_KERNMSG_HDR ""
#define MIN_MEM_SIZE 4096UL
@@ -458,15 +460,112 @@ static int ramoops_init_prz(struct device *dev, struct
ramoops_context *cxt,
return 0;
}
+static int ramoops_parse_dt_size(struct platform_device *pdev,
+ const char *propname, unsigned long *val)
+{
+ u64 val64;
+ int ret;
+
+ ret = of_property_read_u64(pdev->dev.of_node, propname, &val64);
+ if (ret == -EINVAL) {
+ *val = 0;
+ return 0;
+ } else if (ret != 0) {
+ dev_err(&pdev->dev, "failed to parse property %s: %d\n",
+ propname, ret);
+ return ret;
+ }
+
+ if (val64 > ULONG_MAX) {
+ dev_err(&pdev->dev, "invalid %s %llu\n", propname, val64);
+ return -EOVERFLOW;
+ }
+
+ *val = val64;
+ return 0;
+}
+
+static int ramoops_parse_dt(struct platform_device *pdev,
+ struct ramoops_platform_data *pdata)
+{
+ struct device_node *of_node = pdev->dev.of_node;
+ struct device_node *mem_region;
+ struct resource res;
+ u32 ecc_size;
+ int ret;
+
+ dev_dbg(&pdev->dev, "using Device Tree\n");
+
+ mem_region = of_parse_phandle(of_node
Re: [PATCH v3 1/4] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation
On Mon, Nov 16, 2015 at 01:19:55PM -0300, Ariel D'Alessandro wrote:
> Add the devicetree binding document for NXP LPC18xx EEPROM memory.
>
> Signed-off-by: Ariel D'Alessandro
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/nvmem/lpc1857-eeprom.txt | 28
> ++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
> b/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
> new file mode 100644
> index 000..809df68
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
> @@ -0,0 +1,28 @@
> +* NXP LPC18xx EEPROM memory NVMEM driver
> +
> +Required properties:
> + - compatible: Should be "nxp,lpc1857-eeprom"
> + - reg: Must contain an entry with the physical base address and length
> +for each entry in reg-names.
> + - reg-names: Must include the following entries.
> +- reg: EEPROM registers.
> +- mem: EEPROM address space.
> + - clocks: Must contain an entry for each entry in clock-names.
> + - clock-names: Must include the following entries.
> +- eeprom: EEPROM operating clock.
> + - resets: Should contain a reference to the reset controller asserting
> +the EEPROM in reset.
> + - interrupts: Should contain EEPROM interrupt.
> +
> +Example:
> +
> + eeprom: eeprom@4000e000 {
> +compatible = "nxp,lpc1857-eeprom";
> +reg = <0x4000e000 0x1000>,
> + <0x2004 0x4000>;
> +reg-names = "reg", "mem";
> +clocks = <&ccu1 CLK_CPU_EEPROM>;
> +clock-names = "eeprom";
> +resets = <&rgu 27>;
> +interrupts = <4>;
> + };
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] irqchip: Add brcm,bcm6345-l1-intc device tree binding
On Mon, Nov 16, 2015 at 07:12:36PM +, Simon Arlott wrote:
> Add device tree binding for the BCM6345 interrupt controller.
>
> This controller is similar to the SMP-capable BCM7038 and
> the BCM3380 but with packed interrupt registers.
>
> Signed-off-by: Simon Arlott
> ---
> On 16/11/15 15:34, Rob Herring wrote:
> > On Sun, Nov 15, 2015 at 04:51:16PM +, Simon Arlott wrote:
> >> Add device tree binding for the BCM63168 interrupt controller.
> >>
> >> This controller is similar to the SMP-capable BCM7038 and
> >> the BCM3380 but with packed interrupt registers.
> >>
> >> Signed-off-by: Simon Arlott
> >
> > Acked-by: Rob Herring
>
> I'm going to rename this to bcm6345-l1 as suggested by Jonas Gorski, and
> the binding now specifies a version of the compatible name to be
> included.
Acked-by: Rob Herring
> .../interrupt-controller/brcm,bcm6345-l1-intc.txt | 57
> ++
> 1 file changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
>
> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
> new file mode 100644
> index 000..c5bdcf1
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
> @@ -0,0 +1,57 @@
> +Broadcom BCM6345-style Level 1 interrupt controller
> +
> +This block is a first level interrupt controller that is typically connected
> +directly to one of the HW INT lines on each CPU.
> +
> +Key elements of the hardware design include:
> +
> +- 32, 64 or 128 incoming level IRQ lines
> +
> +- Most onchip peripherals are wired directly to an L1 input
> +
> +- A separate instance of the register set for each CPU, allowing individual
> + peripheral IRQs to be routed to any CPU
> +
> +- Contains one or more enable/status word pairs per CPU
> +
> +- No atomic set/clear operations
> +
> +- No polarity/level/edge settings
> +
> +- No FIFO or priority encoder logic; software is expected to read all
> + 2-4 status words to determine which IRQs are pending
> +
> +Required properties:
> +
> +- compatible: should be "brcm,bcm-l1-intc", "brcm,bcm6345-l1-intc"
> +- reg: specifies the base physical address and size of the registers;
> + the number of supported IRQs is inferred from the size argument
> +- interrupt-controller: identifies the node as an interrupt controller
> +- #interrupt-cells: specifies the number of cells needed to encode an
> interrupt
> + source, should be 1.
> +- interrupt-parent: specifies the phandle to the parent interrupt
> controller(s)
> + this one is cascaded from
> +- interrupts: specifies the interrupt line(s) in the interrupt-parent
> controller
> + node; valid values depend on the type of parent interrupt controller
> +
> +If multiple reg ranges and interrupt-parent entries are present on an SMP
> +system, the driver will allow IRQ SMP affinity to be set up through the
> +/proc/irq/ interface. In the simplest possible configuration, only one
> +reg range and one interrupt-parent is needed.
> +
> +The driver operates in native CPU endian by default, there is no support for
> +specifying an alternative endianness.
> +
> +Example:
> +
> +periph_intc: periph_intc@1000 {
> +compatible = "brcm,bcm63168-l1-intc", "brcm,bcm6345-l1-intc";
> +reg = <0x1020 0x20>,
> + <0x1040 0x20>;
> +
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +interrupt-parent = <&cpu_intc>;
> +interrupts = <2>, <3>;
> +};
> --
> 2.1.4
>
> --
> Simon Arlott
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 3/4] ARM: BCM: Add SMP support for Broadcom NSP
Hi Kapil,
[auto build test ERROR on: arm-soc/for-next]
[also build test ERROR on: v4.4-rc1 next-20151116]
url:
https://github.com/0day-ci/linux/commits/Kapil-Hali/dt-bindings-add-SMP-enable-method-for-Broadcom-NSP/20151105-135452
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: arm-bcm_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/mach-bcm/built-in.o: In function `__virt_to_phys':
>> arch/arm/include/asm/memory.h:206: undefined reference to
>> `nsp_secondary_startup'
>> arch/arm/include/asm/memory.h:206: undefined reference to
>> `nsp_secondary_startup'
vim +206 arch/arm/include/asm/memory.h
f52bb722 Sricharan R 2013-07-29 200
ca5a45c0 Santosh Shilimkar 2013-07-31 201 static inline phys_addr_t
__virt_to_phys(unsigned long x)
dc21af99 Russell King 2011-01-04 202 {
f52bb722 Sricharan R 2013-07-29 203 phys_addr_t t;
f52bb722 Sricharan R 2013-07-29 204
f52bb722 Sricharan R 2013-07-29 205 if (sizeof(phys_addr_t) == 4) {
cada3c08 Russell King 2011-01-04 @206 __pv_stub(x, t, "add",
__PV_BITS_31_24);
f52bb722 Sricharan R 2013-07-29 207 } else {
f52bb722 Sricharan R 2013-07-29 208 __pv_stub_mov_hi(t);
f52bb722 Sricharan R 2013-07-29 209 __pv_add_carry_stub(x,
t);
:: The code at line 206 was first introduced by commit
:: cada3c0841e1deaec4c0f92654610b028dc683ff ARM: P2V: extend to 16-bit
translation offsets
:: TO: Russell King
:: CC: Russell King
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On 11/16/2015 01:30 PM, Stephen Warren wrote: On 11/13/2015 10:58 AM, Andrew Bresticker wrote: On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding wrote: On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +For Tegra210, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 + - functions: "snps", "xusb", "uart" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 + - functions: "pcie-x1", "usb3-ss", "pcie-x4" +- sata: sata-0 + - functions: "usb3-ss", "sata" usb2-bias also needs to be present. I'm not sure about this. All of the driver code that I've looked deals with the usb2-bias pad internally. As far as I can tell, this pad needs to be configured to whatever any of the other pads is configured for. I think that means if any of the UTMI pads is configured for XUSB then the usb2-bias pad must also be configured for XUSB. Which would also imply that if one of the UTMI pads is configured for XUSB, all of them must be configured for XUSB. I was told by hardware engineers at NVIDIA that (at least on Tegra124/Tegra132) the usb2-bias pad must be configured in the XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB. If UTMI pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the USB register space (base 0x7d00). You may want to follow up internally to confirm this. If it's true, that could make things here a bit nastier, especially if we want to support configurations where some pads are muxed to XUSB while others are muxed to SNPS. Hmm. I've certainly successfully tested a configuration where UTMI pad 0 was handled by the SNPS controller and other pads by the XUSB controller *and* where I set the usb2-bias "pad"'s muxing and configuration via the XUSB PADCTL module. In that case, I /had/ to configure usb2-bias via XUSB PADCTL or the other XUSB pads didn't work. However, perhaps that was because the XUSB controller driver probed before the SNPS driver; perhaps if they'd probed the other way around and the SNPS driver configured the bias pad, then everything would have worked without configuring the bias pad via XUSB PADCTL. I suppose I'll have to start another internal thread to get the full details, and differentiate between "recommended" and "supported" and "must" vs. "can"/"should". I've discussed this with a HW engineer, and apparently this rule is simply a recommendation, with the acknowledgement that everything will work perfectly fine if we ignore it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] devicetree: bindings: Add optional dynamic-power-coefficient property
On Mon, Nov 16, 2015 at 07:30:23PM +, Punit Agrawal wrote:
> The dynamic power consumption of a device is proportional to the
> square of voltage (V) and the clock frequency (f). It can be expressed as
>
> Pdyn = dynamic-power-coefficient * V^2 * f.
>
> The coefficient represents the running time dynamic power consumption in
> units of mw/MHz/uVolt^2 and can be used in the above formula to
> calculate the dynamic power in mW.
>
> Signed-off-by: Punit Agrawal
> Cc: Rob Herring
> Cc: Mark Rutland
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..6aca64f 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -242,6 +242,23 @@ nodes to be present and contain the properties described
> below.
> Definition: Specifies the syscon node controlling the cpu core
> power domains.
>
> + - dynamic-power-coefficient
> + Usage: optional
> + Value type:
> + Definition: A u32 value that represents the running time dynamic
> + power coefficient in units of mW/MHz/uVolt^2. The
> + coefficient can either be calculated from power
> + measurements or derived by analysis.
> +
> + The dynamic power consumption of the CPU is
> + proportional to the square of the Voltage (V) and
> + the clock frequency (f). The coefficient is used to
> + calculate the dynamic power as below -
> +
> + Pdyn = dynamic-power-coefficient * V^2 * f
> +
> + where voltage is in uV, frequency is in MHz.
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
On Mon, Nov 16, 2015 at 03:02:01PM -0600, Matthew McClintock wrote: > From: Varadarajan Narayanan > > Add pinctrl driver support for IPQ4019 platform > > Signed-off-by: Sricharan R > Signed-off-by: Mathieu Olivari > Signed-off-by: Varadarajan Narayanan > Signed-off-by: Matthew McClintock > --- > > v2 - add a note in the device tree binding about the TLMM block Acked-by: Rob Herring > > .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 119 ++ > drivers/pinctrl/qcom/Kconfig |8 + > drivers/pinctrl/qcom/Makefile |1 + > drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 > > 4 files changed, 1408 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c > > diff --git > a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > new file mode 100644 > index 000..ba8a2c6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > @@ -0,0 +1,119 @@ > +Qualcomm Atheros IPQ4019 TLMM block > + > +This is the Top Level Mode Multiplexor block found on the Qualcomm IPQ8019 > +platform, it provides pinctrl, pinmux, pinconf, and gpiolib facilities. > + > +Required properties: > +- compatible: "qcom,ipq4019-pinctrl" > +- reg: Should be the base address and length of the TLMM block. > +- interrupts: Should be the parent IRQ of the TLMM block. > +- interrupt-controller: Marks the device node as an interrupt controller. > +- #interrupt-cells: Should be two. > +- gpio-controller: Marks the device node as a GPIO controller. > +- #gpio-cells : Should be two. > +The first cell is the gpio pin number and the > +second cell is used for optional parameters. > + > +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt > for > +a general description of GPIO and interrupt bindings. > + > +Please refer to pinctrl-bindings.txt in this directory for details of the > +common pinctrl bindings used by client devices, including the meaning of the > +phrase "pin configuration node". > + > +The pin configuration nodes act as a container for an abitrary number of > +subnodes. Each of these subnodes represents some desired configuration for a > +pin, a group, or a list of pins or groups. This configuration can include the > +mux function to select on those pin(s)/group(s), and various pin > configuration > +parameters, such as pull-up, drive strength, etc. > + > +The name of each subnode is not important; all subnodes should be enumerated > +and processed purely based on their content. > + > +Each subnode only affects those parameters that are explicitly listed. In > +other words, a subnode that lists a mux function but no pin configuration > +parameters implies no information about any pin configuration parameters. > +Similarly, a pin subnode that describes a pullup parameter implies no > +information about e.g. the mux function. > + > + > +The following generic properties as defined in pinctrl-bindings.txt are valid > +to specify in a pin configuration subnode: > + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength. > + > +Non-empty subnodes must specify the 'pins' property. > +Note that not all properties are valid for all pins. > + > + > +Valid values for qcom,pins are: > + gpio0-gpio70 > +Supports mux, bias and drive-strength > + > +sdio_cd, sdio_clk, sdio_cmd, sdio_data1, sdio_data1, sdio_data1, > sdio_data1, > +sdio_data5, sdio_data6, sdio_data7 > + > +Valid values for qcom,function are: > +smart0, jtag, audio0, mdio0, wcss0_dbg18, wcss1_dbg18, qdss_tracedata_a, mdc, > +wcss0_dbg19, wcss1_dbg19, blsp_uart1, wifi0_uart, wifi1_uart, smart1, > +wcss0_dbg20, wcss1_dbg20, wifi0_uart0, wifi1_uart0, wcss0_dbg21, wcss1_dbg21, > +blsp_i2c0, wcss0_dbg22, wcss1_dbg22, wcss0_dbg23, wcss1_dbg23, blsp_i2c1, > +wcss0_dbg24, wcss1_dbg24, wcss0_dbg25, wcss1_dbg25, pcie_rst, wcss0_dbg26, > +wcss1_dbg26, pcie_clk0, wcss0_dbg27, wcss1_dbg27, led0, blsp_uart0, led1, > +chip_irq0, wifi0_uart1, wifi1_uart1, wcss0_dbg28, wcss1_dbg28, chip_rst, > +audio_spdifout, sdio1, rgmii2, sdio2, rgmii3, sdio3, rgmii_rx, sdio_clk, > +wcss0_dbg29, wcss1_dbg29, wcss0_dbg16, wcss1_dbg16, audio1, wcss0_dbg17, > +wcss1_dbg17, sdio_cd, rgmii0, sdio0, rgmii1, rgmii_txc, audio_td1, sdio_cmd, > +audio_td2, sdio4, audio_td3, sdio5, audio_pwm0, sdio6, audio_pwm1, sdio7, > +rgmii_rxc, audio_pwm2, rgmii_tx, audio_pwm3, wcss0_dbg30, wcss1_dbg30, > +wcss0_dbg31, wcss1_dbg31, rmii00, led2, rmii01, wifi0_wci, wifi1_wci, > +rmii0_tx, rmii0_rx, pcie_clk1, led3, pcie_wakeup, rmii0_refclk, > +wifi0_rfsilient0, wifi1_rfsilient0, smart2, led4, wifi0_cal, wifi1_cal, > +wifi_wci0, rmii0_dv, wifi_wci1, rmii1_refclk, blsp_spi1, led5, rmii10, > +blsp_spi0, led6, rmii11, led7, rmii1_dv,
Re: [PATCH v2 2/5] devicetree: Add bindings for the ATH79 USB phy
On Mon, Nov 16, 2015 at 10:22:01PM +0100, Alban Bedel wrote:
> Signed-off-by: Alban Bedel
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/phy/phy-ath79-usb.txt | 18
> ++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
> b/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
> new file mode 100644
> index 000..cafe219
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
> @@ -0,0 +1,18 @@
> +* Atheros AR71XX/9XXX USB PHY
> +
> +Required properties:
> +- compatible: "qca,ar7100-usb-phy"
> +- #phys-cells: should be 0
> +- reset-names: "usb-phy"[, "usb-suspend-override"]
> +- resets: references to the reset controllers
> +
> +Example:
> +
> + usb-phy {
> + compatible = "qca,ar7100-usb-phy";
> +
> + reset-names = "usb-phy", "usb-suspend-override";
> + resets = <&rst 4>, <&rst 3>;
> +
> + #phy-cells = <0>;
> + };
> --
> 2.0.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
On Mon, Nov 16, 2015 at 02:34:52PM -0800, Brian Norris wrote: > Pull the supported chip names from drivers/mtd/devices/m25p80.c and stop > pointing readers to Linux code. > > Also (although I see this habit repeated throughout the > Documentation/devicetree/bindings/ tree), stop using the title "driver" > in this file, when we're trying explicitly to describe hardware, not > software. > > Signed-off-by: Brian Norris > Cc: Thanks for the clean-up. Acked-by: Rob Herring > --- > .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 > -- > 1 file changed, 51 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > index 2bee68103b01..2c91c03e7eb0 100644 > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > @@ -1,15 +1,61 @@ > -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips > +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips > > Required properties: > - #address-cells, #size-cells : Must be present if the device has sub-nodes >representing partitions. > - compatible : May include a device-specific string consisting of the > - manufacturer and name of the chip. Bear in mind the DT binding > - is not Linux-only, but in case of Linux, see the "m25p_ids" > - table in drivers/mtd/devices/m25p80.c for the list of > supported > - chips. > + manufacturer and name of the chip. A list of supported chip > + names follows. > Must also include "jedec,spi-nor" for any SPI NOR flash that > can > be identified by the JEDEC READ ID opcode (0x9F). > + > + Supported chip names: > + at25df321a > + at25df641 > + at26df081a > + mr25h256 > + mx25l4005a > + mx25l1606e > + mx25l6405d > + mx25l12805d > + mx25l25635e > + n25q064 > + n25q128a11 > + n25q128a13 > + n25q512a > + s25fl256s1 > + s25fl512s > + s25sl12801 > + s25fl008k > + s25fl064k > + sst25vf040b > + m25p40 > + m25p80 > + m25p16 > + m25p32 > + m25p64 > + m25p128 > + w25x80 > + w25x32 > + w25q32 > + w25q32dw > + w25q80bl > + w25q128 > + w25q256 > + > + The following chip names have been used historically to > + designate quirky versions of flash chips that do not support > the > + JEDEC READ ID opcode (0x9F): > + m25p05-nonjedec > + m25p10-nonjedec > + m25p20-nonjedec > + m25p40-nonjedec > + m25p80-nonjedec > + m25p16-nonjedec > + m25p32-nonjedec > + m25p64-nonjedec > + m25p128-nonjedec > + > - reg : Chip-Select number > - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate > at > > -- > 2.6.0.rc2.230.g3dd15c0 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v4 2/2] media: v4l: ti-vpe: Document CAL driver
Rob Herring wrote on Mon [2015-Nov-16 09:26:16 -0600]:
> On Sun, Nov 15, 2015 at 05:53:48PM -0600, Benoit Parrot wrote:
> > Device Tree bindings for the Camera Adaptation Layer (CAL) driver
>
> Bindings are for h/w blocks, not drivers...
OK I'll fix that.
>
> >
> > Signed-off-by: Benoit Parrot
> > ---
> > Documentation/devicetree/bindings/media/ti-cal.txt | 70
> > ++
> > 1 file changed, 70 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/ti-cal.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt
> > b/Documentation/devicetree/bindings/media/ti-cal.txt
> > new file mode 100644
> > index ..680efadb6208
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/ti-cal.txt
> > @@ -0,0 +1,70 @@
> > +Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
> > +--
> > +
> > +The Camera Adaptation Layer (CAL) is a key component for image capture
> > +applications. The capture module provides the system interface and the
> > +processing capability to connect CSI2 image-sensor modules to the
> > +DRA72x device.
> > +
> > +Required properties:
> > +- compatible: must be "ti,cal"
>
> Needs to be more specific.
See potential patch below.
>
> > +- reg: physical base address and length of the registers set for the 4
> > + memory regions required;
>
> Please list what the 4 regions are.
See potential patch below.
>
> > +- reg-names: name associated with the memory regions described is ;
>
> Please list the names.
See potential patch below.
>
> > +- interrupts: should contain IRQ line for the CAL;
> > +
> > +CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
> > +should contain a 'port' child node with child 'endpoint' node. Please
> > +refer to the bindings defined in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +
> > +Example:
> > + cal: cal@4845b000 {
> > + compatible = "ti,cal";
> > + ti,hwmods = "cal";
> > + reg = <0x4845B000 0x400>,
> > + <0x4845B800 0x40>,
> > + <0x4845B900 0x40>,
> > + <0x4A002e94 0x4>;
> > + reg-names = "cal_top",
> > + "cal_rx_core0",
> > + "cal_rx_core1",
> > + "camerrx_control";
> > + interrupts = ;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + csi2_0: port@0 {
>
> Multiple ports should be under a ports node.
The video-interfaces.txt bindings doc state:
"All 'port' nodes can be grouped under optional 'ports' node"
Doesn't that mean that 'ports' is then optional has show in the csi2
example provide in the same documents?
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > + endpoint {
> > + slave-mode;
> > + remote-endpoint = <&ar0330_1>;
> > + };
> > + };
> > + csi2_1: port@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > + };
> > + };
> > +
> > + i2c5: i2c@4807c000 {
> > + ar0330@10 {
> > + compatible = "ti,ar0330";
> > + reg = <0x10>;
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ar0330_1: endpoint {
> > + reg = <0>;
> > + clock-lanes = <1>;
> > + data-lanes = <0 2 3 4>;
> > + remote-endpoint = <&csi2_0>;
> > + };
> > + };
> > + };
> > + };
> > --
> > 1.8.5.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Potential fix for the above comments:
diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt
b/Documentation/devicetree/bindings/media/ti-cal.txt
index 680efadb6208..ef6f88de38c0 100644
--- a/Documentation/devicetree/bindings/media/ti-cal.txt
+++ b/Documentation/devicetree/bindings/media/ti-cal.txt
@@ -7,10 +7,11 @@ processing capability to connect CSI2 image-sensor modules to
the
DRA72x device.
Required properties:
-- compatible: must be "ti,cal"
-- reg: physical base address and length of the registers set for the 4
- memory regions required;
-- reg-names: name associated with the memory regions described is ;
+- compatible: must be "ti,dra72-cal"
+- reg: CAL Top level, Receiver Core #0, Receiver Core #1 and Camera RX
+
[PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Pull the supported chip names from drivers/mtd/devices/m25p80.c and stop pointing readers to Linux code. Also (although I see this habit repeated throughout the Documentation/devicetree/bindings/ tree), stop using the title "driver" in this file, when we're trying explicitly to describe hardware, not software. Signed-off-by: Brian Norris Cc: --- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 -- 1 file changed, 51 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 2bee68103b01..2c91c03e7eb0 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -1,15 +1,61 @@ -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips Required properties: - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions. - compatible : May include a device-specific string consisting of the - manufacturer and name of the chip. Bear in mind the DT binding - is not Linux-only, but in case of Linux, see the "m25p_ids" - table in drivers/mtd/devices/m25p80.c for the list of supported - chips. + manufacturer and name of the chip. A list of supported chip + names follows. Must also include "jedec,spi-nor" for any SPI NOR flash that can be identified by the JEDEC READ ID opcode (0x9F). + + Supported chip names: + at25df321a + at25df641 + at26df081a + mr25h256 + mx25l4005a + mx25l1606e + mx25l6405d + mx25l12805d + mx25l25635e + n25q064 + n25q128a11 + n25q128a13 + n25q512a + s25fl256s1 + s25fl512s + s25sl12801 + s25fl008k + s25fl064k + sst25vf040b + m25p40 + m25p80 + m25p16 + m25p32 + m25p64 + m25p128 + w25x80 + w25x32 + w25q32 + w25q32dw + w25q80bl + w25q128 + w25q256 + + The following chip names have been used historically to + designate quirky versions of flash chips that do not support the + JEDEC READ ID opcode (0x9F): + m25p05-nonjedec + m25p10-nonjedec + m25p20-nonjedec + m25p40-nonjedec + m25p80-nonjedec + m25p16-nonjedec + m25p32-nonjedec + m25p64-nonjedec + m25p128-nonjedec + - reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at -- 2.6.0.rc2.230.g3dd15c0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mtd: m25p80: fix some module and documentation issues
Hi, There were a few mistakes and improvements pointed out at various points in this thread, subject: spi: OF module autoloading is still broken (was: Re: m25p80: Commit "allow arbitrary OF matching for "jedec,spi-nor"" breaks module autoloading) http://lists.infradead.org/pipermail/linux-mtd/2015-October/062369.html https://lkml.org/lkml/2015/11/12/574 That thread covers some other interesting issues that are still not solved, but let's fix the ones we can here in MTD right now. Regards, Brian Brian Norris (3): mtd: m25p80: fix module autoloading for "jedec,spi-nor" and "spi-nor" mtd: m25p80: replace leftover "nor-jedec" with "spi-nor" in comments doc: dt: mtd: stop referring to driver code for spi-nor IDs .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 -- drivers/mtd/devices/m25p80.c | 17 +-- 2 files changed, 64 insertions(+), 9 deletions(-) -- 2.6.0.rc2.230.g3dd15c0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On 11/10/2015 10:33 PM, Bharat Kumar Gogada wrote:
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
---
Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
Moved MSI functionality to separate functions.
Changed error return values.
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
drivers/pci/host/Kconfig | 16 +-
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1062
4 files changed, 1144 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #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.
+- reg: Should contain Bridge, PCIe Controller registers location,
+ configuration sapce, and length
+- reg-names: Must include the following entries:
+ "breg": bridge registers
+ "pcireg": PCIe controller registers
+ "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+ "msi1, msi0": interrupt asserted when msi is received
+ "intx": interrupt that is asserted when an legacy interrupt is received
+ "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and 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
+- msi-controller: indicates that this is MSI controller node
+- msi-parent: MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy
interrupts
+ - interrupt-controller: identifies the node as an interrupt controller
+ - #interrupt-cells: should be set to 1
+ - #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "xlnx,nwl-pcie-2.11";
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+ interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+ msi-parent = <&nwl_pcie>;
+ reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x0200 0x 0xe100 0x 0xe100 0
0x0f00>;
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..39799cf 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,12 +15,22 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
+config PCIE_XILINX_NWL
+ bool "NWL PCIe Core"
+ depends on ARCH_ZYNQMP
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
config PCIE_DW
- bool
+bool
config PCI_EXYNOS
- bool "Samsung Exynos PCIe controller"
- depends on SOC_EXYNOS5440
+bool "Samsung Exynos PCIe controller"
+depends on SOC_EXYNOS5440
select PCIEPORTBUS
select PCIE_DW
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d
Re: [PATCH V2] ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial support
Hi Lucas
On Mon, Nov 16, 2015 at 06:23:18PM +0100, Michael Trimarchi wrote:
> www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
>
> Signed-off-by: Michael Trimarchi
> ---
> Changes in v2:
> - add the board in alphabetic order
> - remove cpu operating point
> - remove simple-bus and adjust regulaotor
> - add gpios to correct pinctrl
> - remove no mainline binding of gpc
>
Here you have the boot of the board
http://pastebin.com/DBi9kJfZ
I need this patch too
http://lkml.iu.edu/hypermail/linux/kernel/1511.1/04843.html
Regards
Michael
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6q-icore-rqs.dts| 21 ++
> arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 365
> +++
> 3 files changed, 387 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-icore-rqs.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index bb8fa02..7e8f29c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -312,6 +312,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-gw551x.dtb \
> imx6q-gw552x.dtb \
> imx6q-hummingboard.dtb \
> + imx6q-icore-rqs.dtb \
> imx6q-nitrogen6x.dtb \
> imx6q-phytec-pbab01.dtb \
> imx6q-rex-pro.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-icore-rqs.dts
> b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> new file mode 100644
> index 000..96f167f
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2015 Amarula Solutions B.V.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-icore-rqs.dtsi"
> +
> +/ {
> + model = "Engicam i.CoreM6 Quad SOM";
> + compatible = "fsl,imx6-icore-rqs", "fsl,imx6q";
> +};
> +
> +&sata {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> new file mode 100644
> index 000..678ff0a
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright 2015 Amarula Solutions B.V.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +#include
> +#include
> +
> +/ {
> + memory {
> + reg = <0x1000 0x8000>;
> + };
> +
> + reg_1p8v: 1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_2p5v: 2p5v {
> + compatible = "regulator-fixed";
> + regulator-name = "2P5V";
> + regulator-min-microvolt = <250>;
> + regulator-max-microvolt = <250>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_3p3v: 3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_sd3_vmmc: sd3_vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "P3V3_SD3_SWITCHED";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio1 4 GPIO_ACTIVE_LOW>;
> + enable-active-high;
> + };
> +
> + reg_sd4_vmmc: sd4_vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "P3V3_SD4_SWITCHED";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_usb_h1_vbus: usb_h1_vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_usb_otg_vbus: usb_otg_vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-mi
Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On 11/16/2015 7:14 AM, Marc Zyngier wrote:
On 11/11/15 06:33, Bharat Kumar Gogada wrote:
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
---
Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
Moved MSI functionality to separate functions.
Changed error return values.
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
drivers/pci/host/Kconfig | 16 +-
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1062
4 files changed, 1144 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
[...]
+static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus *bus)
+{
+ struct platform_device *pdev = to_platform_device(pcie->dev);
+ struct nwl_msi *msi = &pcie->msi;
+ unsigned long base;
+ int ret;
+
+ mutex_init(&msi->lock);
+
+ /* Check for msii_present bit */
+ ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & MSII_PRESENT;
+ if (!ret) {
+ dev_err(pcie->dev, "MSI not present\n");
+ ret = -EIO;
+ goto err;
+ }
+
+ /* Enable MSII */
+ nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
+ MSII_ENABLE, I_MSII_CONTROL);
+
+ /* Enable MSII status */
+ nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
+ MSII_STATUS_ENABLE, I_MSII_CONTROL);
+
+ /* setup AFI/FPCI range */
+ msi->pages = __get_free_pages(GFP_KERNEL, 0);
+ base = virt_to_phys((void *)msi->pages);
+ nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
+ nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
BTW, you still haven't answered my question as to why you need to waste
a page of memory here, and why putting a device address doesn't work.
As this is (to the best of my knowledge) the only driver doing so, I'd
really like you to explain the rational behind this.
Might not be the only driver doing so after I start sending out patches
for the iProc MSI support (soon), :)
I'm not sure how it works for the Xilinx NWL controller, which Bharat
should be able to help to explain. But for the iProc MSI controller,
there's no device I/O memory reserved for MSI posted writes in the ASIC.
Therefore one needs to reserve host memory for these writes.
Ray
Thanks,
M.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: leds-bcm6328: add more init configuration options
Hi Simon and Jacek, This is done on purpose because not every BCM63268 device has serial LEDs and we should be able to enable/disable those options in order to avoid depending on the bootloader setting the registers correctly. Regards, Álvaro. El 16/11/2015 a las 16:03, Jacek Anaszewski escribió: Hi Simon, On 11/15/2015 06:27 PM, Simon Arlott wrote: commit 1d3ff22d633d35048c35c3deeead7ab116cebc32 Author: Álvaro Fernández Rojas Date: Thu Oct 8 12:35:55 2015 +0200 Documentation: leds: update DT bindings for leds-bcm6328 This patch adds latest DT bindings for leds-bcm6328 init register configuration. commit 9f82c778ce17789a038351a411ff65cd41033c7a Author: Álvaro Fernández Rojas Date: Thu Oct 8 12:35:54 2015 +0200 leds-bcm6328: add more init configuration options This patch adds more init register configuration options: - Serial LEDs multiplexing. - Serial LEDs clock signal low/high polarity. - Serial LEDs data signal low/high polarity. - Serial LEDs shift direction inverted/normal. This was not a backwards-compatible change, because the driver is now turning off all of the serial LED options by default when previously it only turned off brcm,serial-leds and left the other options unchanged. There are currently no in-tree users of this binding, so any existing users will be broken by this change. Please submit a patch fixing the issue in such cases, so that we could discuss possible solutions to the problem. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] phy: Add a driver for the ATH79 USB phy
The ATH79 USB phy is very simple, it only have a reset. On some SoC a
second reset is used to force the phy in suspend mode regardless of the
USB controller status.
Signed-off-by: Alban Bedel
---
Changelog:
v2: * Rebased on the simple PHY driver
* Added myself as maintainer of the driver
---
MAINTAINERS | 8 +++
drivers/phy/Kconfig | 8 +++
drivers/phy/Makefile| 1 +
drivers/phy/phy-ath79-usb.c | 116
4 files changed, 133 insertions(+)
create mode 100644 drivers/phy/phy-ath79-usb.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..310ff8c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1823,6 +1823,14 @@ S: Maintained
F: drivers/gpio/gpio-ath79.c
F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
+ATHEROS 71XX/9XXX USB PHY DRIVER
+M: Alban Bedel
+W: https://github.com/AlbanBedel/linux
+T: git git://github.com/AlbanBedel/linux
+S: Maintained
+F: drivers/phy/phy-ath79-usb.c
+F: Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
+
ATHEROS ATH GENERIC UTILITIES
M: "Luis R. Rodriguez"
L: linux-wirel...@vger.kernel.org
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 028fb16..c8f58ae 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,6 +15,14 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config PHY_ATH79_USB
+ tristate "Atheros AR71XX/9XXX USB PHY driver"
+ depends on ATH79 || COMPILE_TEST
+ default y if USB_EHCI_HCD_PLATFORM
+ select PHY_SIMPLE
+ help
+ Enable this to support the USB PHY on Atheros AR71XX/9XXX SoCs.
+
config PHY_BERLIN_USB
tristate "Marvell Berlin USB PHY Driver"
depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 1a44362..9ff8550 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_ATH79_USB)+= phy-ath79-usb.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
diff --git a/drivers/phy/phy-ath79-usb.c b/drivers/phy/phy-ath79-usb.c
new file mode 100644
index 000..ff49356
--- /dev/null
+++ b/drivers/phy/phy-ath79-usb.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2015 Alban Bedel
+ *
+ * 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
+#include
+#include
+#include
+
+struct ath79_usb_phy {
+ struct simple_phy sphy;
+ struct reset_control *suspend_override;
+};
+
+static int ath79_usb_phy_power_on(struct phy *phy)
+{
+ struct ath79_usb_phy *priv = container_of(
+ phy_get_drvdata(phy), struct ath79_usb_phy, sphy);
+ int err;
+
+ err = simple_phy_power_on(phy);
+ if (err)
+ return err;
+
+ if (priv->suspend_override) {
+ err = reset_control_assert(priv->suspend_override);
+ if (err) {
+ simple_phy_power_off(phy);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static int ath79_usb_phy_power_off(struct phy *phy)
+{
+ struct ath79_usb_phy *priv = container_of(
+ phy_get_drvdata(phy), struct ath79_usb_phy, sphy);
+ int err;
+
+ if (priv->suspend_override) {
+ err = reset_control_deassert(priv->suspend_override);
+ if (err)
+ return err;
+ }
+
+ err = simple_phy_power_off(phy);
+ if (err && priv->suspend_override)
+ reset_control_assert(priv->suspend_override);
+
+ return err;
+}
+
+static const struct phy_ops ath79_usb_phy_ops = {
+ .power_on = ath79_usb_phy_power_on,
+ .power_off = ath79_usb_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static const struct simple_phy_desc ath79_usb_phy_desc = {
+ .ops = &ath79_usb_phy_ops,
+ .reset = "usb-phy",
+ .clk = (void *)-ENOENT,
+};
+
+static int ath79_usb_phy_probe(struct platform_device *pdev)
+{
+ struct ath79_usb_phy *priv;
+ struct phy *phy;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->suspend_override = devm_reset_control_get_optional(
+ &pdev->dev, "usb-suspend-override");
+ if (IS_ERR(priv->suspend_override)) {
+ if (PTR_ERR(priv->suspend_override) == -ENOENT)
+ priv->suspend_override = NULL;
+
[PATCH v2 4/5] MIPS: ath79: Add the EHCI controller and USB phy to the AR9132 dtsi
Signed-off-by: Alban Bedel
---
Changelog:
v2: * Fix the USB controller node name to follow ePAPR
* Set the USB phy as disabled like the USB controller
---
arch/mips/boot/dts/qca/ar9132.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/mips/boot/dts/qca/ar9132.dtsi
b/arch/mips/boot/dts/qca/ar9132.dtsi
index fb7734e..857ca48 100644
--- a/arch/mips/boot/dts/qca/ar9132.dtsi
+++ b/arch/mips/boot/dts/qca/ar9132.dtsi
@@ -125,6 +125,21 @@
};
};
+ usb@1b000100 {
+ compatible = "qca,ar7100-ehci", "generic-ehci";
+ reg = <0x1b000100 0x100>;
+
+ interrupts = <3>;
+ resets = <&rst 5>;
+
+ has-transaction-translator;
+
+ phy-names = "usb";
+ phys = <&usb_phy>;
+
+ status = "disabled";
+ };
+
spi@1f00 {
compatible = "qca,ar9132-spi", "qca,ar7100-spi";
reg = <0x1f00 0x10>;
@@ -138,4 +153,15 @@
#size-cells = <0>;
};
};
+
+ usb_phy: usb-phy {
+ compatible = "qca,ar7100-usb-phy";
+
+ reset-names = "usb-phy", "usb-suspend-override";
+ resets = <&rst 4>, <&rst 3>;
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
};
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] MIPS: ath79: Add USB support on the TL-WR1043ND
Hi, First re-roll of this patch series to add a driver for the USB phy on ATH79 SoCs. As suggested in the previous series this new version include a generic driver for simple phys which is re-used for the ATH79 driver. This generic driver should be useful for all kind of phys that don't need any configuration. Alban Alban Bedel (5): phy: Add a driver for simple phy devicetree: Add bindings for the ATH79 USB phy phy: Add a driver for the ATH79 USB phy MIPS: ath79: Add the EHCI controller and USB phy to the AR9132 dtsi MIPS: ath79: Enable the USB port on the TL-WR1043ND .../devicetree/bindings/phy/phy-ath79-usb.txt | 18 ++ MAINTAINERS| 8 + arch/mips/boot/dts/qca/ar9132.dtsi | 26 +++ arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts | 8 + drivers/phy/Kconfig| 20 ++ drivers/phy/Makefile | 2 + drivers/phy/phy-ath79-usb.c| 116 drivers/phy/phy-simple.c | 204 + include/linux/phy/simple.h | 39 9 files changed, 441 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-ath79-usb.txt create mode 100644 drivers/phy/phy-ath79-usb.c create mode 100644 drivers/phy/phy-simple.c create mode 100644 include/linux/phy/simple.h -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] phy: Add a driver for simple phy
This driver is meant to take care of all trivial phys that don't need
any special configuration, it just enable a regulator, a clock and
deassert a reset. A public API is also included to allow re-using the
code in other drivers.
Signed-off-by: Alban Bedel
---
drivers/phy/Kconfig| 12 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-simple.c | 204 +
include/linux/phy/simple.h | 39 +
4 files changed, 256 insertions(+)
create mode 100644 drivers/phy/phy-simple.c
create mode 100644 include/linux/phy/simple.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..028fb16 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -118,6 +118,18 @@ config PHY_RCAR_GEN2
help
Support for USB PHY found on Renesas R-Car generation 2 SoCs.
+config PHY_SIMPLE
+ tristate
+ select GENERIC_PHY
+ help
+
+config PHY_SIMPLE_PDEV
+ tristate "Simple PHY driver"
+ select PHY_SIMPLE
+ help
+ A PHY driver for simple devices that only need a regulator, clock
+ and reset for power up and shutdown.
+
config OMAP_CONTROL_PHY
tristate "OMAP CONTROL PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..1a44362 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o
+obj-$(CONFIG_PHY_SIMPLE) += phy-simple.o
obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
diff --git a/drivers/phy/phy-simple.c b/drivers/phy/phy-simple.c
new file mode 100644
index 000..013f846
--- /dev/null
+++ b/drivers/phy/phy-simple.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2015 Alban Bedel
+ *
+ * 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
+#include
+#include
+#include
+#include
+
+int simple_phy_power_on(struct phy *phy)
+{
+ struct simple_phy *sphy = phy_get_drvdata(phy);
+ int err;
+
+ if (sphy->regulator) {
+ err = regulator_enable(sphy->regulator);
+ if (err)
+ return err;
+ }
+
+ if (sphy->clk) {
+ err = clk_prepare_enable(sphy->clk);
+ if (err)
+ goto regulator_disable;
+ }
+
+ if (sphy->reset) {
+ err = reset_control_deassert(sphy->reset);
+ if (err)
+ goto clock_disable;
+ }
+
+ return 0;
+
+clock_disable:
+ if (sphy->clk)
+ clk_disable_unprepare(sphy->clk);
+regulator_disable:
+ if (sphy->regulator)
+ WARN_ON(regulator_disable(sphy->regulator));
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(simple_phy_power_on);
+
+int simple_phy_power_off(struct phy *phy)
+{
+ struct simple_phy *sphy = phy_get_drvdata(phy);
+ int err;
+
+ if (sphy->reset) {
+ err = reset_control_assert(sphy->reset);
+ if (err)
+ return err;
+ }
+
+ if (sphy->clk)
+ clk_disable_unprepare(sphy->clk);
+
+ if (sphy->regulator) {
+ err = regulator_disable(sphy->regulator);
+ if (err)
+ goto clock_enable;
+ }
+
+ return 0;
+
+clock_enable:
+ if (sphy->clk)
+ WARN_ON(clk_prepare_enable(sphy->clk));
+ if (sphy->reset)
+ WARN_ON(reset_control_deassert(sphy->reset));
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(simple_phy_power_off);
+
+static const struct phy_ops simple_phy_ops = {
+ .power_on = simple_phy_power_on,
+ .power_off = simple_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+struct phy *devm_simple_phy_create(struct device *dev,
+ const struct simple_phy_desc *desc,
+ struct simple_phy *sphy)
+{
+ struct phy *phy;
+
+ if (!dev || !desc)
+ return ERR_PTR(-EINVAL);
+
+ if (!sphy) {
+ sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
+ if (!sphy)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ if (!IS_ERR_OR_NULL(desc->regulator)) {
+ sphy->regulator = devm_regulator_get(dev, desc->regulator);
+ if (IS_ERR(sphy->regulator)) {
+ if (PTR_ERR(
[PATCH v2 2/5] devicetree: Add bindings for the ATH79 USB phy
Signed-off-by: Alban Bedel
---
.../devicetree/bindings/phy/phy-ath79-usb.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
b/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
new file mode 100644
index 000..cafe219
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
@@ -0,0 +1,18 @@
+* Atheros AR71XX/9XXX USB PHY
+
+Required properties:
+- compatible: "qca,ar7100-usb-phy"
+- #phys-cells: should be 0
+- reset-names: "usb-phy"[, "usb-suspend-override"]
+- resets: references to the reset controllers
+
+Example:
+
+ usb-phy {
+ compatible = "qca,ar7100-usb-phy";
+
+ reset-names = "usb-phy", "usb-suspend-override";
+ resets = <&rst 4>, <&rst 3>;
+
+ #phy-cells = <0>;
+ };
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] MIPS: ath79: Enable the USB port on the TL-WR1043ND
Signed-off-by: Alban Bedel
---
Changelog:
v2: * Fix the USB controller node name to follow ePAPR
* Enable the USB phy as it is now disabled per default
---
arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
b/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
index 003015a..e535ee3 100644
--- a/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
+++ b/arch/mips/boot/dts/qca/ar9132_tl_wr1043nd_v1.dts
@@ -35,6 +35,10 @@
};
};
+ usb@1b000100 {
+ status = "okay";
+ };
+
spi@1f00 {
status = "okay";
num-cs = <1>;
@@ -65,6 +69,10 @@
};
};
+ usb-phy {
+ status = "okay";
+ };
+
gpio-keys {
compatible = "gpio-keys-polled";
#address-cells = <1>;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/32] scsi: hisi_sas: scan device tree
Hi John, [auto build test ERROR on scsi/for-next] [also build test ERROR on v4.4-rc1 next-20151116] url: https://github.com/0day-ci/linux/commits/John-Garry/HiSilicon-SAS-driver/20151116-215304 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next config: i386-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "of_irq_count" undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH RESEND v2 3/4] ARM: BCM: Add SMP support for Broadcom NSP
On Tue, Nov 10, 2015 at 5:21 PM, Kapil Hali wrote: > On 11/10/2015 7:59 AM, Florian Fainelli wrote: >>> Also give it a sane name, bcm_sec_boot_address or so. >>> "secondary_boot" sounds like a function you call to boot >>> the second core. >> >> Agree with that, there could be a better name which better reflects >> this is a variable. >> > As this change is consolidating SMP implementation, I kept the same > name of the variable which was used in kona_smp.c so that the changes > in the common code is minimal. Also, the fact that the change is part > of up-streamed code, I didn't alter with the variable name. Shall I > change it in the next patch? Sure do it any way as long as the end result looks fine. It was not a big issue anyways. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
From: Varadarajan Narayanan Add pinctrl driver support for IPQ4019 platform Signed-off-by: Sricharan R Signed-off-by: Mathieu Olivari Signed-off-by: Varadarajan Narayanan Signed-off-by: Matthew McClintock --- v2 - add a note in the device tree binding about the TLMM block .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 119 ++ drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 4 files changed, 1408 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt new file mode 100644 index 000..ba8a2c6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt @@ -0,0 +1,119 @@ +Qualcomm Atheros IPQ4019 TLMM block + +This is the Top Level Mode Multiplexor block found on the Qualcomm IPQ8019 +platform, it provides pinctrl, pinmux, pinconf, and gpiolib facilities. + +Required properties: +- compatible: "qcom,ipq4019-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. +The first cell is the gpio pin number and the +second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength. + +Non-empty subnodes must specify the 'pins' property. +Note that not all properties are valid for all pins. + + +Valid values for qcom,pins are: + gpio0-gpio70 +Supports mux, bias and drive-strength + +sdio_cd, sdio_clk, sdio_cmd, sdio_data1, sdio_data1, sdio_data1, sdio_data1, +sdio_data5, sdio_data6, sdio_data7 + +Valid values for qcom,function are: +smart0, jtag, audio0, mdio0, wcss0_dbg18, wcss1_dbg18, qdss_tracedata_a, mdc, +wcss0_dbg19, wcss1_dbg19, blsp_uart1, wifi0_uart, wifi1_uart, smart1, +wcss0_dbg20, wcss1_dbg20, wifi0_uart0, wifi1_uart0, wcss0_dbg21, wcss1_dbg21, +blsp_i2c0, wcss0_dbg22, wcss1_dbg22, wcss0_dbg23, wcss1_dbg23, blsp_i2c1, +wcss0_dbg24, wcss1_dbg24, wcss0_dbg25, wcss1_dbg25, pcie_rst, wcss0_dbg26, +wcss1_dbg26, pcie_clk0, wcss0_dbg27, wcss1_dbg27, led0, blsp_uart0, led1, +chip_irq0, wifi0_uart1, wifi1_uart1, wcss0_dbg28, wcss1_dbg28, chip_rst, +audio_spdifout, sdio1, rgmii2, sdio2, rgmii3, sdio3, rgmii_rx, sdio_clk, +wcss0_dbg29, wcss1_dbg29, wcss0_dbg16, wcss1_dbg16, audio1, wcss0_dbg17, +wcss1_dbg17, sdio_cd, rgmii0, sdio0, rgmii1, rgmii_txc, audio_td1, sdio_cmd, +audio_td2, sdio4, audio_td3, sdio5, audio_pwm0, sdio6, audio_pwm1, sdio7, +rgmii_rxc, audio_pwm2, rgmii_tx, audio_pwm3, wcss0_dbg30, wcss1_dbg30, +wcss0_dbg31, wcss1_dbg31, rmii00, led2, rmii01, wifi0_wci, wifi1_wci, +rmii0_tx, rmii0_rx, pcie_clk1, led3, pcie_wakeup, rmii0_refclk, +wifi0_rfsilient0, wifi1_rfsilient0, smart2, led4, wifi0_cal, wifi1_cal, +wifi_wci0, rmii0_dv, wifi_wci1, rmii1_refclk, blsp_spi1, led5, rmii10, +blsp_spi0, led6, rmii11, led7, rmii1_dv, led8, rmii1_tx, aud_pin, led9, +rmii1_rx, led10, wifi0_rfsilient1, wifi1_rfsilient1, led11, qpic_pad, +qdss_cti_trig_in_a0, mdio1, audio2, dbg_out, wcss0_dbg, wcss1_dbg, atest_char3, +pmu0, wcss0_dbg0, wcss1_dbg0, atest_char2, pmu1, wcss0_dbg1, wcss1_dbg1, +atest_char1, wcss0_dbg2, wcss1_dbg2, qpic_pad4,
[PATCH v2 5/5] dts: ipq4019: Add support for IPQ4019 DK01 board
From: Matthew McClintock
Initial board support dts files for DK01 board.
Signed-off-by: Senthilkumar N L
Signed-off-by: Varadarajan Narayanan
---
v2 - add xo clock
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts | 22 +
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 59 +
3 files changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..11b151e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -505,6 +505,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
+ qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
new file mode 100644
index 000..0d92f1b
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
@@ -0,0 +1,22 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include "qcom-ipq4019-ap.dk01.1.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";
+
+};
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
new file mode 100644
index 000..fe78f3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -0,0 +1,59 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include "qcom-ipq4019.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
+ compatible = "qcom,ipq4019";
+
+ clocks {
+xo: xo {
+compatible = "fixed-clock";
+clock-frequency = <4800>;
+#clock-cells = <0>;
+};
+ };
+
+ soc {
+
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 2 0xf08>,
+<1 3 0xf08>,
+<1 4 0xf08>,
+<1 1 0xf08>;
+ clock-frequency = <4800>;
+ };
+
+ pinctrl@0x0100 {
+ serial_pins: serial_pinmux {
+ mux {
+ pins = "gpio60", "gpio61";
+ function = "blsp_uart0";
+ bias-disable;
+ };
+ };
+ };
+
+ serial@78af000 {
+ pinctrl-0 = <&serial_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+ };
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] qcom: ipq4019: Add basic board/dts support for IPQ4019 SoC
From: Matthew McClintock
Add initial dts files and SoC support for IPQ4019
Signed-off-by: Varadarajan Narayanan
---
v2 - add sleep_clk
arch/arm/boot/dts/qcom-ipq4019.dtsi | 115
1 file changed, 115 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq4019.dtsi
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
new file mode 100644
index 000..fc73822
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -0,0 +1,115 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+#include
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ4019";
+ compatible = "qcom,ipq4019";
+ interrupt-parent = <&intc>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x2>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x3>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+ };
+
+ clocks {
+ sleep_clk: sleep_clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "simple-bus";
+
+ intc: interrupt-controller@b00 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0b00 0x1000>,
+ <0x0b002000 0x1000>;
+ };
+
+ gcc: clock-controller@180 {
+ compatible = "qcom,gcc-ipq4019";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x180 0x6>;
+ };
+
+ tlmm: pinctrl@0x0100 {
+ compatible = "qcom,ipq4019-pinctrl";
+ reg = <0x0100 0x30>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 208 0>;
+ };
+
+ serial@78af000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78af000 0x200>;
+ interrupts = <0 107 0>;
+ status = "disabled";
+ clocks = <&gcc GCC_BLSP1_UART1_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
+
+ serial@78b {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78b 0x200>;
+ interrupts = <0 108 0>;
+ status = "disabled";
+ clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On 11/13/2015 10:58 AM, Andrew Bresticker wrote: On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding wrote: On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +For Tegra210, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 + - functions: "snps", "xusb", "uart" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 + - functions: "pcie-x1", "usb3-ss", "pcie-x4" +- sata: sata-0 + - functions: "usb3-ss", "sata" usb2-bias also needs to be present. I'm not sure about this. All of the driver code that I've looked deals with the usb2-bias pad internally. As far as I can tell, this pad needs to be configured to whatever any of the other pads is configured for. I think that means if any of the UTMI pads is configured for XUSB then the usb2-bias pad must also be configured for XUSB. Which would also imply that if one of the UTMI pads is configured for XUSB, all of them must be configured for XUSB. I was told by hardware engineers at NVIDIA that (at least on Tegra124/Tegra132) the usb2-bias pad must be configured in the XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB. If UTMI pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the USB register space (base 0x7d00). You may want to follow up internally to confirm this. If it's true, that could make things here a bit nastier, especially if we want to support configurations where some pads are muxed to XUSB while others are muxed to SNPS. Hmm. I've certainly successfully tested a configuration where UTMI pad 0 was handled by the SNPS controller and other pads by the XUSB controller *and* where I set the usb2-bias "pad"'s muxing and configuration via the XUSB PADCTL module. In that case, I /had/ to configure usb2-bias via XUSB PADCTL or the other XUSB pads didn't work. However, perhaps that was because the XUSB controller driver probed before the SNPS driver; perhaps if they'd probed the other way around and the SNPS driver configured the bias pad, then everything would have worked without configuring the bias pad via XUSB PADCTL. I suppose I'll have to start another internal thread to get the full details, and differentiate between "recommended" and "supported" and "must" vs. "can"/"should". -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On 11/13/2015 09:32 AM, Thierry Reding wrote: On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote: On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +PCIe pad: +- + +Required properties: +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Must contain the following entries: + - "pll": phandle and specifier referring to the PLLE +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the PCIe UPHY block I don't recall any clocks or resets properties in the pads for Tegra124. Do we really not need any? Tegra124 had two instances of what used to be called IOPHY, one for PCIe and one for SATA. On Tegra210 these have been replaced by two instances of what's called UPHY. The resets listed in the PCIe and SATA pad nodes are wired to those UPHY instances, hence why they are new on Tegra210. For Tegra124 no resets exist for the IOPHY instances. OK. I wonder if renaming the section title from "PCIe pad" to "Tegra210 PCIe pad" would be helpful; it'd certainly allow the reader to more quickly work out what part of the document they were looking at if jumping around in it. +SATA pad: +- + +Required properties: +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the SATA UPHY block + PHY nodes: Nit: 2 blank lines there. Those were intentional for additional spacing between sections. That seems inconsistent, and not something I recall seeing before, so I'm not sure anyone would realize that. Better to do it with more explicit section names I think. +For Tegra210, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 + - functions: "snps", "xusb", "uart" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 + - functions: "pcie-x1", "usb3-ss", "pcie-x4" +- sata: sata-0 + - functions: "usb3-ss", "sata" usb2-bias also needs to be present. I'm not sure about this. All of the driver code that I've looked deals with the usb2-bias pad internally. As far as I can tell, this pad needs to be configured to whatever any of the other pads is configured for. I think that means if any of the UTMI pads is configured for XUSB then the usb2-bias pad must also be configured for XUSB. Which would also imply that if one of the UTMI pads is configured for XUSB, all of them must be configured for XUSB. I don't believe that's true; on Tegra210 I have successfully configured the (legacy) "USB2 controller" to drive the recovery/micro-USB board-level port, and the "XUSB controller" (USB2 and USB3 ports thereof) to drive a couple of other board-level ports. It's also not a pad in the sense that the others are pads. It doesn't directly connect anywhere. It's also shared by all the UTMI pads. That said, there are two registers that allow some of the parameters of the pad to be set, so perhaps adding the node exclusively for configurability might make sense. It wouldn't really be a PHY node, though, so wouldn't fit into the above group. Perhaps something like the following could be added: There is an additional pad that is used to support the bias voltages to the USB2/UTMI pads. This is not a PHY that can be consumed by any I/O controller, but the device tree node can be used to specify parameters needed for the programming of the pad. I think the function shouldn't necessarily be exposed as a parameter, because all that would do is add the possibility for a conflicting set of mux options with the USB2/UTMI pads. OK, if we can come up with a well-described algorithm re: how/when to program/enable this pad, then we can probably represent this differently than the other pads. I might expect DT to contain values for HS_DISCON_LEVEL HS_SQUELCH_LEVEL, although I can't recall if those values are SoC- or board-specific off the top of my head. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
On 11/13/2015 09:11 AM, Thierry Reding wrote: On Wed, Nov 04, 2015 at 01:54:15PM -0700, Stephen Warren wrote: On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a set of lanes that are used for PCIe, SATA and USB. .../bindings/phy/nvidia,tegra-xusb-padctl.txt | 359 + For Tegra bindings, we usually use the full compatible value as the filename, so I'd expect the chip number in the filename too. I specifically didn't do that to avoid confusion. The XUSB pad controller was introduced on Tegra114, but patches weren't posted until Tegra124. So nvidia,tegra114-xusb-padctl.txt would be the proper name for this binding if we were following the conventions, but then we have never specified that binding (though I think it would look mostly the same as for Tegra124). I can of course still go for nvidia,tegra114-xusb-padctl.txt, the content would explicitly list valid compatible strings. It's just that none of them would match the filename. I was asking that the file be named to match the compatible flag, not the SoC version that contains the HW module. The first/oldest compatible value currently documented is Tegra124, so I'd expect that to appear in the filename. Yes, it's theoretically possible for the binding to be enhanced in the future to cover Tegra114, and at that time we'd probably want to rename the file. However, I believe the likelihood of that happening is zero (or even negative, which is admittedly mathematically impossible, but I'm being hyperbolic). I'd expect to see a patch in this series that edits the existing Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt and mentions that the binding is deprecated. How about this: --- >8 --- diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt index 30676ded85bb..77dfba05ccfd 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt @@ -1,6 +1,11 @@ Device tree binding for NVIDIA Tegra XUSB pad controller +NOTE: It turns out that this binding isn't an accurate description of the XUSB +pad controller. While the description is good enough for the functional subset +required for PCIe and SATA, it lacks the flexibility to represent the features +needed for USB. For the new binding, see ../phy/nvidia,tegra-xusb-padctl.txt. + The Tegra XUSB pad controller manages a set of lanes, each of which can be assigned to one out of a set of different pads. Some of these pads have an associated PHY that must be powered up before the pad can be used. --- >8 --- That sounds good, although I'd suggest explicitly mentioning that the binding is deprecated. Perhaps add ", and so this binding is deprecated" at the end of the first sentence? diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +- reg: Physical base address and length of the controller's registers. +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must include the following entries: + - "padctl" Are there no clocks or power domains that affect XUSB padctl? I suppose we can start off without any, and add them later if we need. I don't think there are any. The TRM specifies that it's in the ungated Vaux_soc power partition, and doesn't mention any clocks. OK. Obviously the module must used some clock, since it contains clocked logic. However, equally that clock is obviously on even without the driver explicitly managing it since the HW works right now. So, I suppose we can defer adding any clock entries to the binding/DT until later, if the need arises. It'd still be nice if we could put the complete details into the binding from day one, but I understand that the documentation isn't exactly forthcoming on these topics. +- mboxes: Must contain an entry for each entry in mbox-names. +- mbox-names: Must include the following entries: + - "xusb" I thought we'd decided not to use any mbox binding or drivers in XUSB now? See for example my proposed XUSB controller binding at: http://www.spinics.net/lists/linux-tegra/msg23922.html [PATCH V9] dt: add NVIDIA Tegra XUSB controller binding The idea is that the mailbox should be entirely internal to the XUSB controller driver, and if the receipt of a mailbox message requires any change in the XUSB pad controller programming, the XUSB controller driver should simply call the XUSB pad controller driver to perform that operation. Okay, I think that should work, but it'll require a rather large rewrite of... well, everything. I think Martyn was going to look into that, so I guess I'
Re: [PATCH 2/2] MIPS: bmips: Add bcm63168-l1 interrupt controller
On 16/11/15 12:56, Jonas Gorski wrote:
> On Sun, Nov 15, 2015 at 5:53 PM, Simon Arlott wrote:
>> Add the BCM63168 interrupt controller based on the SMP-capable BCM7038
>> and the BCM3380 but with packed interrupt registers.
>>
>> Add the BCM63168 interrupt controller to a list with the existing BCM7038
>> so that interrupts on CPU1 are not ignored.
This will be renamed to bcm6345-l1.
...
>> diff --git a/drivers/irqchip/irq-bcm63168-l1.c
>> b/drivers/irqchip/irq-bcm63168-l1.c
>> new file mode 100644
>> index 000..5a144af
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-bcm63168-l1.c
>> @@ -0,0 +1,372 @@
>> +/*
>> + * Broadcom BCM63168 style Level 1 interrupt controller driver
>> + *
>> + * Copyright (C) 2014 Broadcom Corporation
>> + * Copyright 2015 Simon Arlott
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This is based on the BCM7038 (which supports SMP) but with a single
>> + * enable register instead of separate mask/set/clear registers.
>> + *
>> + * The BCM3380 has a similar mask/status register layout, but each pair
>> + * of words is at separate locations (and SMP is not supported).
>> + *
>> + * ENABLE/STATUS words are packed next to each other for each CPU:
>> + *
>> + * 6368:
>> + * 0x1000_0020: CPU0_W0_ENABLE
>> + * 0x1000_0024: CPU0_W1_ENABLE
>> + * 0x1000_0028: CPU0_W0_STATUS IRQs 31-63
>> + * 0x1000_002c: CPU0_W1_STATUS IRQs 0-31
>> + * 0x1000_0030: CPU1_W0_ENABLE
>> + * 0x1000_0034: CPU1_W1_ENABLE
>> + * 0x1000_0038: CPU1_W0_STATUS IRQs 31-63
>> + * 0x1000_003c: CPU1_W1_STATUS IRQs 0-31
>> + *
>> + * 63168:
>> + * 0x1000_0020: CPU0_W0_ENABLE
>> + * 0x1000_0024: CPU0_W1_ENABLE
>> + * 0x1000_0028: CPU0_W2_ENABLE
>> + * 0x1000_002c: CPU0_W3_ENABLE
>> + * 0x1000_0030: CPU0_W0_STATUS IRQs 96-127
>> + * 0x1000_0034: CPU0_W1_STATUS IRQs 64-95
>> + * 0x1000_0038: CPU0_W2_STATUS IRQs 32-63
>> + * 0x1000_003c: CPU0_W3_STATUS IRQs 0-31
>> + * 0x1000_0040: CPU1_W0_ENABLE
>> + * 0x1000_0044: CPU1_W1_ENABLE
>> + * 0x1000_0048: CPU1_W2_ENABLE
>> + * 0x1000_004c: CPU1_W3_ENABLE
>> + * 0x1000_0050: CPU1_W0_STATUS IRQs 96-127
>> + * 0x1000_0054: CPU1_W1_STATUS IRQs 64-95
>> + * 0x1000_0058: CPU1_W2_STATUS IRQs 32-63
>> + * 0x1000_005c: CPU1_W3_STATUS IRQs 0-31
>> + *
>> + * IRQs are numbered in CPU native endian order
>> + * (which is big-endian in these examples)
>> + */
>> +
...
>> +static inline unsigned int reg_enable(struct bcm63168_l1_chip *intc,
>> + unsigned int word)
>> +{
>> +#ifdef __BIG_ENDIAN
>> + return (1 * intc->n_words - word - 1) * sizeof(u32);
>> +#else
>> + return (0 * intc->n_words + word) * sizeof(u32);
>
> Huh, do the words really change the order when running in LE? I would
> have expected
> to each 32-bit word to contain the same interrupts, just bit-order reversed.
Without having a LE version of this SoC to check it on, I don't know...
but this device binding is specified as native endian and the current
ordering is definitely BE as interrupt "0" is in the last register.
>> +#endif
>> +}
>> +
>> +static inline unsigned int reg_status(struct bcm63168_l1_chip *intc,
>> + unsigned int word)
>> +{
>> +#ifdef __BIG_ENDIAN
>> + return (2 * intc->n_words - word - 1) * sizeof(u32);
>> +#else
>> + return (1 * intc->n_words + word) * sizeof(u32);
>> +#endif
>> +}
>> +
>> +static inline unsigned int cpu_for_irq(struct bcm63168_l1_chip *intc,
>> + struct irq_data *d)
>> +{
>> + return cpumask_first_and(&intc->cpumask,
>> irq_data_get_affinity_mask(d));
>> +}
>> +
>> +static void bcm63168_l1_irq_handle(struct irq_desc *desc)
>> +{
>> + struct bcm63168_l1_chip *intc = irq_desc_get_handler_data(desc);
>> + struct bcm63168_l1_cpu *cpu;
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + unsigned int idx;
>> +
>> +#ifdef CONFIG_SMP
>> + cpu = intc->cpus[cpu_logical_map(smp_processor_id())];
>> +#else
>> + cpu = intc->cpus[0];
>> +#endif
>
> This looks expensive, can they change during runtime? If not, maybe
> just assign intc->cpus[] accordingly at probe time, so you can just do
> intc->cpus[smp_processor_id()] without any #ifdefs.
It's an array lookup in mips, so it becomes:
cpu = intc->cpus[__cpu_logical_map[smp_processor_id()]];
I could just remove the ifdef because smp_processor_id() becomes 0. It
looks like it still does the array lookup.
The bcm7038-l1 driver had this ifdef.
>> +
>> + chained_irq_enter(chip, desc);
>> +
>> + for (idx = 0; idx < intc->n_words; idx++) {
>> + int base = idx * IRQS_PER_WORD;
>> + unsigned long pending;
[PATCH v4 3/3] cpufreq: arm_big_little: Add support to register a cpufreq cooling device
Register passive cooling devices when initialising cpufreq on
big.LITTLE systems. If the device tree provides a dynamic power
coefficient for the CPUs then the bound cooling device will support
the extensions that allow it to be used with all the existing thermal
governors including the power allocator governor.
A cooling device will be created per individual frequency domain and
can be bound to thermal zones via the thermal DT bindings.
Signed-off-by: Punit Agrawal
Acked-by: Viresh Kumar
Cc: Sudeep Holla
Cc: Eduardo Valentin
---
drivers/cpufreq/Kconfig.arm | 2 ++
drivers/cpufreq/arm_big_little.c | 35 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 1582c1c..0e0052e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -6,6 +6,8 @@
config ARM_BIG_LITTLE_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver"
depends on (ARM_CPU_TOPOLOGY || ARM64) && HAVE_CLK
+ # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be
=y
+ depends on !CPU_THERMAL || THERMAL
select PM_OPP
help
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index c5d256c..60d09c0 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -55,6 +56,7 @@ static bool bL_switching_enabled;
#define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 :
freq)
#define VIRT_FREQ(cluster, freq)((cluster == A7_CLUSTER) ? freq >> 1 :
freq)
+static struct thermal_cooling_device *cdev[MAX_CLUSTERS];
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
@@ -493,6 +495,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
static int bL_cpufreq_exit(struct cpufreq_policy *policy)
{
struct device *cpu_dev;
+ int domain;
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
@@ -501,12 +504,43 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
return -ENODEV;
}
+ domain = topology_physical_package_id(cpu_dev->id);
+ cpufreq_cooling_unregister(cdev[domain]);
+ cdev[domain] = NULL;
+
put_cluster_clk_and_freq_table(cpu_dev);
dev_dbg(cpu_dev, "%s: Exited, cpu: %d\n", __func__, policy->cpu);
return 0;
}
+static void bL_cpufreq_ready(struct cpufreq_policy *policy)
+{
+ struct device *cpu_dev = get_cpu_device(policy->cpu);
+ struct device_node *np = of_node_get(cpu_dev->of_node);
+ int domain = topology_physical_package_id(cpu_dev->id);
+
+ if (WARN_ON(!np))
+ return;
+
+ if (of_find_property(np, "#cooling-cells", NULL)) {
+ u32 power_coefficient = 0;
+
+ of_property_read_u32(np, "dynamic-power-coefficient",
+&power_coefficient);
+
+ cdev[domain] = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
+ if (IS_ERR(cdev[domain])) {
+ dev_err(cpu_dev,
+ "running cpufreq without cooling device: %ld\n",
+ PTR_ERR(cdev[domain]));
+ cdev[domain] = NULL;
+ }
+ }
+ of_node_put(np);
+}
+
static struct cpufreq_driver bL_cpufreq_driver = {
.name = "arm-big-little",
.flags = CPUFREQ_STICKY |
@@ -517,6 +551,7 @@ static struct cpufreq_driver bL_cpufreq_driver = {
.get= bL_cpufreq_get_rate,
.init = bL_cpufreq_init,
.exit = bL_cpufreq_exit,
+ .ready = bL_cpufreq_ready,
.attr = cpufreq_generic_attr,
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] cpufreq-dt: Supply power coefficient when registering cooling devices
Support registering cooling devices with dynamic power coefficient
where provided by the device tree. This allows OF registered cooling
devices driver to be used with the power_allocator thermal governor.
Signed-off-by: Punit Agrawal
Acked-by: Viresh Kumar
Reviewed-by: Javi Merino
Cc: Eduardo Valentin
---
drivers/cpufreq/cpufreq-dt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 90d6408..1ceece9 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -407,8 +407,13 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
* thermal DT code takes care of matching them.
*/
if (of_find_property(np, "#cooling-cells", NULL)) {
- priv->cdev = of_cpufreq_cooling_register(np,
-policy->related_cpus);
+ u32 power_coefficient = 0;
+
+ of_property_read_u32(np, "dynamic-power-coefficient",
+&power_coefficient);
+
+ priv->cdev = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
if (IS_ERR(priv->cdev)) {
dev_err(priv->cpu_dev,
"running cpufreq without cooling device: %ld\n",
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] devicetree: bindings: Add optional dynamic-power-coefficient property
The dynamic power consumption of a device is proportional to the
square of voltage (V) and the clock frequency (f). It can be expressed as
Pdyn = dynamic-power-coefficient * V^2 * f.
The coefficient represents the running time dynamic power consumption in
units of mw/MHz/uVolt^2 and can be used in the above formula to
calculate the dynamic power in mW.
Signed-off-by: Punit Agrawal
Cc: Rob Herring
Cc: Mark Rutland
---
Documentation/devicetree/bindings/arm/cpus.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 3a07a87..6aca64f 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -242,6 +242,23 @@ nodes to be present and contain the properties described
below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
+ - dynamic-power-coefficient
+ Usage: optional
+ Value type:
+ Definition: A u32 value that represents the running time dynamic
+ power coefficient in units of mW/MHz/uVolt^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the CPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in uV, frequency is in MHz.
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] Dynamic power model from device tree
Hi, This patchset adds support to build a single-coefficient dynamic power model for a CPU. The model is used by the CPU cooling device to provide an estimate of power consumption and also translate allocated power to performance cap. Changes from previous posting - v3 -> v4: arm_big_little: Migrated to using static arrays arm_big_little: Updated Kconfig to support building thermal as module Patch 1 extends the CPU nodes binding to provide an optional dynamic power coefficient which can be used to create a dynamic power model for the CPUs. This model is used to constrain device power consumption (using power_allocator governor) when the system is thermally constrained. Patches 2-3 extends the cpufreq-dt and arm_big_little driver to register cpu cooling devices with the dynamic coefficient when provided. The patches were previously posted at [0][1][2]. Mediatek platform 8173 builds on these bindings to build the power model. If there are no objections, I'd appreciate Acks from device tree bindings maintainers. Thanks, Punit [0] http://thread.gmane.org/gmane.linux.kernel/2002152 [1] http://thread.gmane.org/gmane.linux.kernel/2011466 [2] http://marc.info/?l=linux-kernel&m=144709020014884&w=2 Punit Agrawal (3): devicetree: bindings: Add optional dynamic-power-coefficient property cpufreq-dt: Supply power coefficient when registering cooling devices cpufreq: arm_big_little: Add support to register a cpufreq cooling device Documentation/devicetree/bindings/arm/cpus.txt | 17 + drivers/cpufreq/Kconfig.arm| 2 ++ drivers/cpufreq/arm_big_little.c | 35 ++ drivers/cpufreq/cpufreq-dt.c | 9 +-- 4 files changed, 61 insertions(+), 2 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] mailbox: Add APM X-Gene platform mailbox driver
On Mon, Nov 9, 2015 at 10:05 AM, Duc Dang wrote: > APM X-Gene SoC has a mailbox controller that provides > communication mechanism for X-Gene Arm64 cores to communicate > with X-Gene SoC's Cortex M3 (SLIMpro) processor. > > X-Gene mailbox controller provides 8 mailbox channels, with > each channel has a dedicated interrupt line. > > Changes since v2: > - Rebase Feng's patch set over v4.3-rc5 > - Remove uneccessary 'inline' in function definition > - Use module_platform_driver instead of subsys_initcall > - Minor coding stype clean up > > Changes since v1: > - Add ACPI support > - Use defines for reg offset > > .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34 +++ > arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++ > drivers/mailbox/Kconfig| 9 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/mailbox-xgene-slimpro.c| 264 > + > 5 files changed, 323 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt > create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c > Hi Jassi, Paul, Do you have any comment on this patch set? > -- > 1.9.1 > Regards, Duc dang. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
