RE: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 15, 2015 8:15 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/dts: Update the core cluster PLL node(s)
On Wed, 2015-04-15 at 06:07 -0500, Liberman Igal-B31950 wrote:
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, April 14, 2015 11:23 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/dts: Update the core cluster PLL
node(s)
On Tue, 2015-04-14 at 15:21 -0500, Scott Wood wrote:
On Tue, 2015-04-14 at 12:55 +0300, Igal.Liberman wrote:
From: Igal Liberman igal.liber...@freescale.com
This patch replaces the following:
https://patchwork.ozlabs.org/patch/427664/
This patch is described by the following binding document update:
https://patchwork.ozlabs.org/patch/461150/
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
index 48e0b6e..7e1f074 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
@@ -49,14 +49,16 @@ global-utilities@e1000 {
reg = 0x800 0x4;
compatible = fsl,qoriq-core-pll-2.0;
clocks = sysclk;
- clock-output-names = pll0, pll0-div2, pll0-div4;
+ clock-output-names = pll0, pll0-div2, pll0-div3,
+ pll0-div4;
};
pll1: pll1@820 {
#clock-cells = 1;
reg = 0x820 0x4;
compatible = fsl,qoriq-core-pll-2.0;
clocks = sysclk;
- clock-output-names = pll1, pll1-div2, pll1-div4;
+ clock-output-names = pll1, pll1-div2, pll1-div3,
+ pll1-div4;
Wait, so if the driver implements the binding you submitted,
you'll break compatibility with these older device trees...
I think we need to just accept the ugly count-the-clock-names
approach and document it.
Is there any current 2.0 clock consumer that references pll-div4?
I looked at T4240 for example, there's a mux node which adds pll-div4
option:
mux0: mux0@0 {
#clock-cells = 0;
reg = 0x0 0x4;
compatible = fsl,qoriq-core-mux-2.0;
clocks = pll0 0, pll0 1, pll0 2,
pll1 0, pll1 1, pll1 2,
pll2 0, pll2 1, pll2 2;
clock-names = pll0, pll0-div2, pll0-div4,
pll1, pll1-div2, pll1-div4,
pll2, pll2-div2, pll2-div4;
clock-output-names = cmux0;
};
After this change pll0 2 will represent pll0-div3 and not pll0-div4.
So this needs to be updated to match -- and it confirms that existing device
trees will be broken if you base the interpretation on compatible rather than
the number of clock-output-names.
Yes.
I'll submit a patch and mention this dependency.
-Scott
Igal.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 15, 2015 8:36 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
From: Igal Liberman igal.liber...@freescale.com
v3: Addressed feedback from Scott:
- Removed clock specifier description.
v2: Addressed feedback from Scott:
- Moved the fman-clk-mux clock provider details
under clocks property.
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
.../devicetree/bindings/clock/qoriq-clock.txt | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index b0d7b73..2bb3b38 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -65,9 +65,10 @@ Required properties:
It takes parent's clock-frequency as its clock.
* fsl,qoriq-platform-pll-1.0 for the platform PLL clock (v1.0)
* fsl,qoriq-platform-pll-2.0 for the platform PLL clock (v2.0)
+ * fsl,fman-clk-mux for the Frame Manager clock.
- #clock-cells: From common clock binding. The number of cells in a
- clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
- clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
+ clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0 and
+ fsl,fman-clk-mux clocks or 1 for fsl,qoriq-core-pll-[1,2].0.
For fsl,qoriq-core-pll-1.0 clocks, the single
clock-specifier cell may take the following values:
* 0 - equal to the PLL frequency
@@ -145,6 +146,18 @@ Example for clock block and clock provider:
clocks = sysclk;
clock-output-names = platform-pll, platform-pll-
div2;
};
+
+ fm0clk: fm0-clk-mux {
+ #clock-cells = 0;
+ reg = 0x10 4
+ compatible = fsl,fman-clk-mux;
+ clocks = pll0 0, pll0 1, pll0 2, pll0 3,
+platform_pll 0, pll1 1, pll1 2;
+ clock-names = pll0, pll0-div2, pll0-div3,
+ pll0-div4, platform-pll, pll1-div2,
+ pll1-div3;
+ clock-output-names = fm0-clk;
+ };
};
};
I don't see this register in the manuals for older DPAA chips, such as
p4080 or p3041. Is it present but undocumented? Should I be looking
somewhere other than Clocking Memory Map?
It's available only in part of the new chips (T4, T2, B4).
In T1024/T1040 there's only one option for FMan clock so this register is not
available.
-Scott
Igal.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 17/31] powerpc/iommu/powernv: Release replaced TCE
On Fri, Apr 10, 2015 at 04:30:59PM +1000, Alexey Kardashevskiy wrote:
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such as VFIO. The pool locks are to protect
DMA page allocator rather than entries and since the host kernel does
not control what pages are in use, there is no point in pool locks and
exchange()+put_page(oldtce) is sufficient to avoid possible races.
This adds an exchange() callback to iommu_table_ops which does the same
thing as set() plus it returns replaced TCE and DMA direction so
the caller can release the pages afterwards.
The returned old TCE value is a virtual address as the new TCE value.
This is different from tce_clear() which returns a physical address.
This implements exchange() for P5IOC2/IODA/IODA2. This adds a requirement
for a platform to have exchange() implemented in order to support VFIO.
This replaces iommu_tce_build() and iommu_clear_tce() with
a single iommu_tce_xchg().
This makes sure that TCE permission bits are not set in TCE passed to
IOMMU API as those are to be calculated by platform code from DMA direction.
This moves SetPageDirty() to the IOMMU code to make it work for both
VFIO ioctl interface in in-kernel TCE acceleration (when it becomes
available later).
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 17 ++--
arch/powerpc/kernel/iommu.c | 53 +---
arch/powerpc/platforms/powernv/pci-ioda.c | 38 ++
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 ++
arch/powerpc/platforms/powernv/pci.c| 17
arch/powerpc/platforms/powernv/pci.h| 2 +
drivers/vfio/vfio_iommu_spapr_tce.c | 62
++---
7 files changed, 130 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index d1f8c6c..bde7ee7 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -44,11 +44,22 @@ extern int iommu_is_off;
extern int iommu_force_on;
struct iommu_table_ops {
+ /* When called with direction==DMA_NONE, it is equal to clear() */
int (*set)(struct iommu_table *tbl,
long index, long npages,
unsigned long uaddr,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+#ifdef CONFIG_IOMMU_API
+ /*
+ * Exchanges existing TCE with new TCE plus direction bits;
+ * returns old TCE and DMA direction mask
+ */
+ int (*exchange)(struct iommu_table *tbl,
+ long index,
+ unsigned long *tce,
+ enum dma_data_direction *direction);
+#endif
void (*clear)(struct iommu_table *tbl,
long index, long npages);
unsigned long (*get)(struct iommu_table *tbl, long index);
@@ -152,6 +163,8 @@ extern void iommu_register_group(struct iommu_table_group
*table_group,
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
+extern long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
+ unsigned long *tce, enum dma_data_direction *direction);
#else
static inline void iommu_register_group(struct iommu_table_group
*table_group,
int pci_domain_number,
@@ -231,10 +244,6 @@ extern int iommu_tce_clear_param_check(struct
iommu_table *tbl,
unsigned long npages);
extern int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce);
-extern int iommu_tce_build(struct iommu_table *tbl, unsigned long entry,
- unsigned long hwaddr, enum dma_data_direction direction);
-extern unsigned long iommu_clear_tce(struct iommu_table *tbl,
- unsigned long entry);
extern void iommu_flush_tce(struct iommu_table *tbl);
extern int iommu_take_ownership(struct iommu_table_group *table_group);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 068fe4ff..501e8ee 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -982,9 +982,6 @@ EXPORT_SYMBOL_GPL(iommu_tce_clear_param_check);
int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce)
{
- if (!(tce (TCE_PCI_WRITE | TCE_PCI_READ)))
- return -EINVAL;
-
if (tce ~(IOMMU_PAGE_MASK(tbl) | TCE_PCI_WRITE | TCE_PCI_READ))
return -EINVAL;
@@ -1002,44 +999,20 @@ int
Re: [PATCH kernel v8 18/31] powerpc/powernv/ioda2: Rework iommu_table creation
On Fri, Apr 10, 2015 at 04:31:00PM +1000, Alexey Kardashevskiy wrote:
This moves iommu_table creation to the beginning. This is a mechanical
patch.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 34
---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 4d80502..a1e0df9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1437,27 +1437,33 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
addr = page_address(tce_mem);
memset(addr, 0, tce_table_size);
+ /* Setup iommu */
+ pe-table_group.tables[0].it_group = pe-table_group;
+
+ /* Setup linux iommu table */
+ tbl = pe-table_group.tables[0];
+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
+ IOMMU_PAGE_SHIFT_4K);
+
+ tbl-it_ops = pnv_ioda2_iommu_ops;
+ iommu_init_table(tbl, phb-hose-node);
+#ifdef CONFIG_IOMMU_API
+ pe-table_group.ops = pnv_pci_ioda2_ops;
+#endif
+
/*
* Map TCE table through TVT. The TVE index is the PE number
* shifted by 1 bit for 32-bits DMA space.
*/
rc = opal_pci_map_pe_dma_window(phb-opal_id, pe-pe_number,
- pe-pe_number 1, 1, __pa(addr),
- tce_table_size, 0x1000);
+ pe-pe_number 1, 1, __pa(tbl-it_base),
+ tbl-it_size 3, 1ULL tbl-it_page_shift);
This looks like a real change, not just mechanical code movement.
if (rc) {
pe_err(pe, Failed to configure 32-bit TCE table,
err %ld\n, rc);
goto fail;
}
- /* Setup iommu */
- pe-table_group.tables[0].it_group = pe-table_group;
-
- /* Setup linux iommu table */
- tbl = pe-table_group.tables[0];
- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- IOMMU_PAGE_SHIFT_4K);
-
/* OPAL variant of PHB3 invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
if (swinvp) {
@@ -1471,16 +1477,12 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
8);
tbl-it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
}
- tbl-it_ops = pnv_ioda2_iommu_ops;
- iommu_init_table(tbl, phb-hose-node);
-#ifdef CONFIG_IOMMU_API
- pe-table_group.ops = pnv_pci_ioda2_ops;
-#endif
iommu_register_group(pe-table_group, phb-hose-global_number,
pe-pe_number);
if (pe-pdev)
- set_iommu_table_base_and_group(pe-pdev-dev, tbl);
+ set_iommu_table_base_and_group(pe-pdev-dev,
+ pe-table_group.tables[0]);
And it's not obvious why this change happens either.
else
pnv_ioda_setup_bus_dma(pe, pe-pbus, true);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpLLL3l0K3Aq.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 21/31] powerpc/iommu: Split iommu_free_table into 2 helpers
On Fri, Apr 10, 2015 at 04:31:03PM +1000, Alexey Kardashevskiy wrote:
The iommu_free_table helper release memory it is using (the TCE table and
@it_map) and release the iommu_table struct as well. We might not want
the very last step as we store iommu_table in parent structures.
Yeah, as I commented on the earlier patch, freeing the surrounding
group from a function taking just the individual table is wrong.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 57
2 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index bde7ee7..8ed4648 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -127,6 +127,7 @@ static inline void *get_iommu_table_base(struct device
*dev)
extern struct iommu_table *iommu_table_alloc(int node);
/* Frees table for an individual device node */
+extern void iommu_reset_table(struct iommu_table *tbl, const char
*node_name);
extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
/* Initializes an iommu_table based in values set in the passed-in
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 501e8ee..0bcd988 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -721,24 +721,46 @@ struct iommu_table *iommu_table_alloc(int node)
return table_group-tables[0];
}
+void iommu_reset_table(struct iommu_table *tbl, const char *node_name)
+{
+ if (!tbl)
+ return;
+
+ if (tbl-it_map) {
+ unsigned long bitmap_sz;
+ unsigned int order;
+
+ /*
+ * In case we have reserved the first bit, we should not emit
+ * the warning below.
+ */
+ if (tbl-it_offset == 0)
+ clear_bit(0, tbl-it_map);
+
+ /* verify that table contains no entries */
+ if (!bitmap_empty(tbl-it_map, tbl-it_size))
+ pr_warn(%s: Unexpected TCEs for %s\n, __func__,
+ node_name);
+
+ /* calculate bitmap size in bytes */
+ bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
+
+ /* free bitmap */
+ order = get_order(bitmap_sz);
+ free_pages((unsigned long) tbl-it_map, order);
+ }
+
+ memset(tbl, 0, sizeof(*tbl));
+}
+
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
- unsigned long bitmap_sz;
- unsigned int order;
struct iommu_table_group *table_group = tbl-it_group;
- if (!tbl || !tbl-it_map) {
- printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
- node_name);
+ if (!tbl)
return;
- }
- /*
- * In case we have reserved the first bit, we should not emit
- * the warning below.
- */
- if (tbl-it_offset == 0)
- clear_bit(0, tbl-it_map);
+ iommu_reset_table(tbl, node_name);
#ifdef CONFIG_IOMMU_API
if (table_group-group) {
@@ -747,17 +769,6 @@ void iommu_free_table(struct iommu_table *tbl, const
char *node_name)
}
#endif
- /* verify that table contains no entries */
- if (!bitmap_empty(tbl-it_map, tbl-it_size))
- pr_warn(%s: Unexpected TCEs for %s\n, __func__, node_name);
-
- /* calculate bitmap size in bytes */
- bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
-
- /* free bitmap */
- order = get_order(bitmap_sz);
- free_pages((unsigned long) tbl-it_map, order);
-
/* free table */
kfree(table_group);
}
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpfqK1xnKhNy.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 19/31] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_create_table/pnc_pci_free_table
On Fri, Apr 10, 2015 at 04:31:01PM +1000, Alexey Kardashevskiy wrote: This is a part of moving TCE table allocation into an iommu_ops callback to support multiple IOMMU groups per one VFIO container. This enforce window size to be a power of two. This is a pretty mechanical patch. ??? Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru But apart from that dubious comment in the commit message, Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgprKRRibPB5L.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 14/31] vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework IOMMU ownership control
On Fri, Apr 10, 2015 at 04:30:56PM +1000, Alexey Kardashevskiy wrote:
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
The set_bypass() callback is not really an iommu_table function but
IOMMU/PE function. This introduces a iommu_table_group_ops struct and
adds a set_ownership() callback to it which is called when an external
user takes control over the IOMMU.
Do you really need separate ops structures at both the single table
and table group level? The different tables in a group will all
belong to the same basic iommu won't they?
This renames set_bypass() to set_ownership() as it is not necessarily
just enabling bypassing, it can be something else/more so let's give it
more generic name. The bool parameter is inverted.
The callback is implemented for IODA2 only. Other platforms (P5IOC2,
IODA1) will use the old iommu_take_ownership/iommu_release_ownership API.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 14 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 30 ++
drivers/vfio/vfio_iommu_spapr_tce.c | 25 +
3 files changed, 56 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index b9e50d3..d1f8c6c 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -92,7 +92,6 @@ struct iommu_table {
unsigned long it_page_shift;/* table iommu page size */
struct iommu_table_group *it_group;
struct iommu_table_ops *it_ops;
- void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
/* Pure 2^n version of get_order */
@@ -127,11 +126,24 @@ extern struct iommu_table *iommu_init_table(struct
iommu_table * tbl,
#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+struct iommu_table_group;
+
+struct iommu_table_group_ops {
+ /*
+ * Switches ownership from the kernel itself to an external
+ * user. While onwership is enabled, the kernel cannot use IOMMU
+ * for itself.
+ */
+ void (*set_ownership)(struct iommu_table_group *table_group,
+ bool enable);
The meaning of enable in a function called set_ownership is
entirely obscure.
+};
+
struct iommu_table_group {
#ifdef CONFIG_IOMMU_API
struct iommu_group *group;
#endif
struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
+ struct iommu_table_group_ops *ops;
};
#ifdef CONFIG_IOMMU_API
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index a964c50..9687731 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1255,10 +1255,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
*phb,
__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
}
-static void pnv_pci_ioda2_set_bypass(struct iommu_table *tbl, bool enable)
+static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
{
- struct pnv_ioda_pe *pe = container_of(tbl-it_group, struct pnv_ioda_pe,
- table_group);
uint16_t window_id = (pe-pe_number 1 ) + 1;
int64_t rc;
@@ -1286,7 +1284,8 @@ static void pnv_pci_ioda2_set_bypass(struct iommu_table
*tbl, bool enable)
* host side.
*/
if (pe-pdev)
- set_iommu_table_base(pe-pdev-dev, tbl);
+ set_iommu_table_base(pe-pdev-dev,
+ pe-table_group.tables[0]);
else
pnv_ioda_setup_bus_dma(pe, pe-pbus, false);
}
@@ -1302,13 +1301,27 @@ static void pnv_pci_ioda2_setup_bypass_pe(struct
pnv_phb *phb,
/* TVE #1 is selected by PCI address bit 59 */
pe-tce_bypass_base = 1ull 59;
- /* Install set_bypass callback for VFIO */
- pe-table_group.tables[0].set_bypass = pnv_pci_ioda2_set_bypass;
-
/* Enable bypass by default */
- pnv_pci_ioda2_set_bypass(pe-table_group.tables[0], true);
+ pnv_pci_ioda2_set_bypass(pe, true);
}
+static void pnv_ioda2_set_ownership(struct iommu_table_group *table_group,
+ bool enable)
+{
+ struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
+ table_group);
+ if (enable)
+ iommu_take_ownership(table_group);
+ else
+ iommu_release_ownership(table_group);
+
+ pnv_pci_ioda2_set_bypass(pe, !enable);
+}
+
+static struct iommu_table_group_ops pnv_pci_ioda2_ops = {
+ .set_ownership = pnv_ioda2_set_ownership,
+};
+
static
Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote: On 04/15/2015 12:15 PM, Vasant Hegde wrote: On 04/15/2015 02:12 PM, Jacek Anaszewski wrote: Hi Vasant, Hi Jacek, .../... I mean, we have to retain the state of LED across system reboot. Static variables are reinitialized on system reboot, aren't they? Sorry. I think comment was confusing.. As I understood, classdev_unregister call resets all LEDs state. However in our case, we don't want to change the LED state during system shutdown/reboot. Hence I have introduced state variable here. So during register call, I just disable LEDs so that any further call will just return. That way we retain LED state even after unloading module. Please let me know if there is any better way to achieve this. Since this is not a feature of the device, but rather a use case, then it cannot be hard coded in the driver this way. The solution I see is introducing a sysfs attribute that would determine if we want the LED to be turned off on unregistration or not. Hmmm. I thought having simple various is enough .. I don't know the usage of other LED drivers .. Just a thought .. How about enabling this feature in LED class itself ...Something like: - Add new attribute to generic LED class (say persistent)? - If drivers wants to retain LED state across reboot, then enable this option - During unregister call check for this attribute You can refer to the following driver to find out how to add the sysfs attribute: drivers/leds/leds-lm3533.c The attribute will also have to be documented, similarly to these: Documentation/ABI/testing/sysfs-class-led-driver-lm3533 Currently I don't have a good candidate for attribute name, so feel free to propose one. If you don't like generic attribute, then shall I introduce persistent attribute inside my driver. ? - By default this attribute is ON and if user wants he can disable this . - And I will have another variable (say op_support).. which I will disable in unload path.. .../... The label could be composed of segments and an ordinal number as labels have to be unique, e.g. attn_ident_0, attn_ident_1. The segments would have to be parsed by the driver to discover all the LED's available modes. nitpicking: identify is a verb and is not a proper name for the LED. Could you describe the purpose of this mode, so that we could come up with a better name? Each component (Field Replacement Unit) will have service indicator (LEDS) which can have below states : - OFF : no action - Identify: blinking state (user can use this state to identify particular component). In Power Systems world we call it as identify indicator.. Hence I retained same name here. How about just ident ? Sounds good. - fault : solid state (when component goes bad, LED goes to solid state) Note that our FW is capable of isolating some of the issues and it can turn on LEDs without OS interference. Does it mean that the LED can be controlled from hardware? If so, what would be software use cases then? The same question is related to the attn and indent states. - Identify LEDs: We have service processor interface to set/reset this LEDs.. Similar operation can be done from inband interface as well (via user space tools in Linux).. Later management layer can make use of this. - Fault / Attention : FW can SET these LEDs if its capable of isolating problem. Similarly host/user space can SET these LEDs if then can do fine grained problem isolation etc. Host/user space can RESET these LEDs. Hence we are adding host support to all the LEDs which can be modified by host. Hope this clarifies. -Vasant ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 20/31] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
On Fri, Apr 10, 2015 at 04:31:02PM +1000, Alexey Kardashevskiy wrote: This is a part of moving DMA window programming to an iommu_ops callback. This is a mechanical patch. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpwYBhJe4K_l.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 12/31] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On Fri, Apr 10, 2015 at 04:30:54PM +1000, Alexey Kardashevskiy wrote:
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch/powerpc/kernel/iommu.c | 34
arch/powerpc/platforms/powernv/pci-ioda.c | 38 +
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 17 ++--
arch/powerpc/platforms/powernv/pci.c| 2 +-
arch/powerpc/platforms/powernv/pci.h| 4 +-
arch/powerpc/platforms/pseries/iommu.c | 9 ++-
drivers/vfio/vfio_iommu_spapr_tce.c | 120
8 files changed, 160 insertions(+), 82 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index eb75726..667aa1a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -90,9 +90,7 @@ struct iommu_table {
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
-#ifdef CONFIG_IOMMU_API
- struct iommu_group *it_group;
-#endif
+ struct iommu_table_group *it_group;
struct iommu_table_ops *it_ops;
void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
@@ -126,14 +124,24 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+
+struct iommu_table_group {
#ifdef CONFIG_IOMMU_API
-extern void iommu_register_group(struct iommu_table *tbl,
+ struct iommu_group *group;
+#endif
+ struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
There's nothing to indicate which of the tables are in use at the
current time. I mean, it doesn't matter now because there's only one,
but the patch doesn't make a whole lot of sense without that.
+};
+
+#ifdef CONFIG_IOMMU_API
+extern void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
#else
-static inline void iommu_register_group(struct iommu_table *tbl,
+static inline void iommu_register_group(struct iommu_table_group
*table_group,
int pci_domain_number,
unsigned long pe_num)
{
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b39d00a..fd49c8e 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -712,17 +712,20 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
struct iommu_table *iommu_table_alloc(int node)
{
- struct iommu_table *tbl;
+ struct iommu_table_group *table_group;
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
+ table_group = kzalloc_node(sizeof(struct iommu_table_group), GFP_KERNEL,
+node);
+ table_group-tables[0].it_group = table_group;
- return tbl;
+ return table_group-tables[0];
}
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
Surely the free function should take a table group rather than a table
as argument.
{
unsigned long bitmap_sz;
unsigned int order;
+ struct iommu_table_group *table_group = tbl-it_group;
if (!tbl || !tbl-it_map) {
printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
@@ -738,9 +741,9 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
clear_bit(0, tbl-it_map);
#ifdef CONFIG_IOMMU_API
- if (tbl-it_group) {
- iommu_group_put(tbl-it_group);
- BUG_ON(tbl-it_group);
+ if (table_group-group) {
+ iommu_group_put(table_group-group);
+ BUG_ON(table_group-group);
}
#endif
@@ -756,7 +759,7 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
free_pages((unsigned long) tbl-it_map, order);
/* free table */
- kfree(tbl);
+ kfree(table_group);
}
/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -903,11 +906,12 @@ EXPORT_SYMBOL_GPL(iommu_direction_to_tce_perm);
*/
static void group_release(void *iommu_data)
{
- struct iommu_table *tbl = iommu_data;
- tbl-it_group = NULL;
+ struct iommu_table_group *table_group = iommu_data;
+
+ table_group-group = NULL;
}
-void
Re: [PATCH kernel v8 15/31] powerpc/iommu: Fix IOMMU ownership control functions
On Fri, Apr 10, 2015 at 04:30:57PM +1000, Alexey Kardashevskiy wrote:
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in it_map.
Clearing must be done outside of the table locks as iommu_clear_tce()
called from iommu_clear_tces_and_put_pages() does this.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v5:
* do not store bit#0 value, it has to be set for zero-based table
anyway
* removed test_and_clear_bit
---
arch/powerpc/kernel/iommu.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 7d6089b..068fe4ff 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1052,17 +1052,28 @@ EXPORT_SYMBOL_GPL(iommu_tce_build);
static int iommu_table_take_ownership(struct iommu_table *tbl)
{
- unsigned long sz = (tbl-it_size + 7) 3;
+ unsigned long flags, i, sz = (tbl-it_size + 7) 3;
+ int ret = 0;
+
+ spin_lock_irqsave(tbl-large_pool.lock, flags);
+ for (i = 0; i tbl-nr_pools; i++)
+ spin_lock(tbl-pools[i].lock);
if (tbl-it_offset == 0)
clear_bit(0, tbl-it_map);
if (!bitmap_empty(tbl-it_map, tbl-it_size)) {
pr_err(iommu_tce: it_map is not empty);
- return -EBUSY;
+ ret = -EBUSY;
+ if (tbl-it_offset == 0)
+ set_bit(0, tbl-it_map);
This really needs a comment. Why on earth are you changing the it_map
on a failure case?
+ } else {
+ memset(tbl-it_map, 0xff, sz);
}
- memset(tbl-it_map, 0xff, sz);
+ for (i = 0; i tbl-nr_pools; i++)
+ spin_unlock(tbl-pools[i].lock);
+ spin_unlock_irqrestore(tbl-large_pool.lock, flags);
return 0;
}
@@ -1095,7 +1106,11 @@ EXPORT_SYMBOL_GPL(iommu_take_ownership);
static void iommu_table_release_ownership(struct iommu_table *tbl)
{
- unsigned long sz = (tbl-it_size + 7) 3;
+ unsigned long flags, i, sz = (tbl-it_size + 7) 3;
+
+ spin_lock_irqsave(tbl-large_pool.lock, flags);
+ for (i = 0; i tbl-nr_pools; i++)
+ spin_lock(tbl-pools[i].lock);
memset(tbl-it_map, 0, sz);
@@ -1103,6 +1118,9 @@ static void iommu_table_release_ownership(struct
iommu_table *tbl)
if (tbl-it_offset == 0)
set_bit(0, tbl-it_map);
+ for (i = 0; i tbl-nr_pools; i++)
+ spin_unlock(tbl-pools[i].lock);
+ spin_unlock_irqrestore(tbl-large_pool.lock, flags);
}
extern void iommu_release_ownership(struct iommu_table_group *table_group)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpLvOaDuKX8b.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 13/31] vfio: powerpc/spapr: powerpc/iommu: Rework IOMMU ownership control
On Fri, Apr 10, 2015 at 04:30:55PM +1000, Alexey Kardashevskiy wrote:
This replaces iommu_take_ownership()/iommu_release_ownership() calls
with the callback calls and it is up to the platform code to call
iommu_take_ownership()/iommu_release_ownership() if needed.
I think this commit message is out of date - I don't see any callbacks
here.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 4 +--
arch/powerpc/kernel/iommu.c | 50
-
drivers/vfio/vfio_iommu_spapr_tce.c | 4 +--
3 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index 667aa1a..b9e50d3 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -225,8 +225,8 @@ extern unsigned long iommu_clear_tce(struct iommu_table
*tbl,
unsigned long entry);
extern void iommu_flush_tce(struct iommu_table *tbl);
-extern int iommu_take_ownership(struct iommu_table *tbl);
-extern void iommu_release_ownership(struct iommu_table *tbl);
+extern int iommu_take_ownership(struct iommu_table_group *table_group);
+extern void iommu_release_ownership(struct iommu_table_group *table_group);
extern enum dma_data_direction iommu_tce_direction(unsigned long tce);
extern unsigned long iommu_direction_to_tce_perm(enum dma_data_direction
dir);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index fd49c8e..7d6089b 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1050,7 +1050,7 @@ int iommu_tce_build(struct iommu_table *tbl, unsigned
long entry,
}
EXPORT_SYMBOL_GPL(iommu_tce_build);
-int iommu_take_ownership(struct iommu_table *tbl)
+static int iommu_table_take_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl-it_size + 7) 3;
@@ -1064,19 +1064,36 @@ int iommu_take_ownership(struct iommu_table *tbl)
memset(tbl-it_map, 0xff, sz);
- /*
- * Disable iommu bypass, otherwise the user can DMA to all of
- * our physical memory via the bypass window instead of just
- * the pages that has been explicitly mapped into the iommu
- */
- if (tbl-set_bypass)
- tbl-set_bypass(tbl, false);
The code to disable bypass is removed, and doesn't seem to be replaced
with anything. That doesn't look safe.
+ return 0;
+}
+
+static void iommu_table_release_ownership(struct iommu_table *tbl);
+
+int iommu_take_ownership(struct iommu_table_group *table_group)
+{
+ int i, j, rc = 0;
+
+ for (i = 0; i IOMMU_TABLE_GROUP_MAX_TABLES; ++i) {
+ struct iommu_table *tbl = table_group-tables[i];
+
+ if (!tbl-it_map)
+ continue;
+
+ rc = iommu_table_take_ownership(tbl);
+ if (rc) {
+ for (j = 0; j i; ++j)
+ iommu_table_release_ownership(
+ table_group-tables[j]);
+
+ return rc;
+ }
+ }
return 0;
}
EXPORT_SYMBOL_GPL(iommu_take_ownership);
-void iommu_release_ownership(struct iommu_table *tbl)
+static void iommu_table_release_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl-it_size + 7) 3;
@@ -1086,9 +1103,18 @@ void iommu_release_ownership(struct iommu_table *tbl)
if (tbl-it_offset == 0)
set_bit(0, tbl-it_map);
- /* The kernel owns the device now, we can restore the iommu bypass */
- if (tbl-set_bypass)
- tbl-set_bypass(tbl, true);
+}
+
+extern void iommu_release_ownership(struct iommu_table_group *table_group)
+{
+ int i;
+
+ for (i = 0; i IOMMU_TABLE_GROUP_MAX_TABLES; ++i) {
+ struct iommu_table *tbl = table_group-tables[i];
+
+ if (tbl-it_map)
+ iommu_table_release_ownership(tbl);
+ }
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index d61aad2..9f38351 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -535,7 +535,7 @@ static int tce_iommu_attach_group(void *iommu_data,
goto unlock_exit;
}
- ret = iommu_take_ownership(table_group-tables[0]);
+ ret = iommu_take_ownership(table_group);
if (!ret)
container-grp = iommu_group;
@@ -572,7 +572,7 @@ static void tce_iommu_detach_group(void *iommu_data,
table_group = iommu_group_get_iommudata(iommu_group);
BUG_ON(!table_group);
- iommu_release_ownership(table_group-tables[0]);
+ iommu_release_ownership(table_group);
unlock_exit:
mutex_unlock(container-lock);
--
David Gibson| I'll have my music baroque, and my code
david AT
Re: [PATCH kernel v8 16/31] powerpc/powernv/ioda/ioda2: Rework tce_build()/tce_free()
On Fri, Apr 10, 2015 at 04:30:58PM +1000, Alexey Kardashevskiy wrote:
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table. This approach makes it possible
to get pnv_pci_ioda_tce_invalidate() unintentionally called on
p5ioc2.
It's not clear what passing start and end addresses has to do with
unintentionally calling the wrong invalidate function.
Another issue is that IODA2 needs PCI addresses to invalidate the cache
and those can be calculated from host addresses but since we are going
to implement multi-level TCE tables, calculating PCI address from
a host address might get either tricky or ugly as TCE table remains flat
on PCI bus but not in RAM.
This defines separate iommu_table_ops callbacks for p5ioc2 and IODA1/2
PHBs. They all call common pnv_tce_build/pnv_tce_free/pnv_tce_get helpers
but call PHB specific TCE invalidation helper (when needed).
This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
number of pages which are PCI addresses shifted by IOMMU page shift.
The patch is pretty mechanical and behaviour is not expected to change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 92
++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 9 ++-
arch/powerpc/platforms/powernv/pci.c| 76 +---
arch/powerpc/platforms/powernv/pci.h| 7 ++-
4 files changed, 111 insertions(+), 73 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 9687731..fd993bc 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1065,18 +1065,20 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe,
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
- struct iommu_table *tbl,
- __be64 *startp, __be64 *endp, bool rm)
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_group,
+ struct pnv_ioda_pe, table_group);
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
(__be64 __iomem *)tbl-it_index;
unsigned long start, end, inc;
const unsigned shift = tbl-it_page_shift;
- start = __pa(startp);
- end = __pa(endp);
+ start = __pa((__be64 *)tbl-it_base + index - tbl-it_offset);
+ end = __pa((__be64 *)tbl-it_base + index - tbl-it_offset +
+ npages - 1);
/* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
if (tbl-it_busno) {
@@ -1112,10 +1114,40 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
*/
}
-static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
- struct iommu_table *tbl,
- __be64 *startp, __be64 *endp, bool rm)
+static int pnv_ioda1_tce_build_vm(struct iommu_table *tbl, long index,
What does the the _vm stand for?
+ long npages, unsigned long uaddr,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
{
+ long ret = pnv_tce_build(tbl, index, npages, uaddr, direction,
+ attrs);
+
+ if (!ret (tbl-it_type TCE_PCI_SWINV_CREATE))
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+
+ return ret;
+}
+
+static void pnv_ioda1_tce_free_vm(struct iommu_table *tbl, long index,
+ long npages)
+{
+ pnv_tce_free(tbl, index, npages);
+
+ if (tbl-it_type TCE_PCI_SWINV_FREE)
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+}
+
+struct iommu_table_ops pnv_ioda1_iommu_ops = {
+ .set = pnv_ioda1_tce_build_vm,
+ .clear = pnv_ioda1_tce_free_vm,
+ .get = pnv_tce_get,
+};
+
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
+{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_group,
+ struct pnv_ioda_pe, table_group);
unsigned long start, end, inc;
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
@@ -1128,9 +1160,9 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
end = start;
/* Figure out the start, end and step */
- inc = tbl-it_offset + (((u64)startp - tbl-it_base) / sizeof(u64));
+ inc = tbl-it_offset + index / sizeof(u64);
start |= (inc shift);
- inc = tbl-it_offset + (((u64)endp -
[git pull] Please pull mpe/linux.git powerpc-4.1-1 tag
Hi Linus, Please pull powerpc updates for 4.1: The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda: Linux 4.0-rc4 (2015-03-15 17:38:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-4.1-1 for you to fetch changes up to 2fe0753d49402aee325cc39c476b46fd51a8afec: powerpc/powermac: Fix build error seen with powermac smp builds (2015-04-15 15:52:59 +1000) There are a couple of conflicts in this merge, nothing major, but FYI: Anton's hard lockup detector commit c54b2bf1b5e9 powerpc: Add ppc64 hard lockup detector support, added a use of watchdog_enable_hardlockup_detector(), which has been removed in 692297d8f968 watchdog: introduce the hardlockup_detector_disable() function. The obvious fix is to instead use hardlockup_detector_disable(). The first conflict in tools/testing/selftests/powerpc/Makefile is caused by commits 6faeeea44b84 selftests: Add install support for the powerpc tests and 84f887bfb930 selftests: Set CC using CROSS_COMPILE once in lib.mk from the selftests tree, colliding with a908f5de3b10 selftests/powerpc: Rename TARGETS in powerpc selftests makefile and 4cd968ef4249 selftests/powerpc: Add a test of the switch_endian() syscall which came via my tree. The second is in tools/testing/selftests/powerpc/tm/Makefile, caused by 6faeeea44b84 selftests: Add install support for the powerpc tests and 7fe924d9d71c selftests/powerpc: Add transactional syscall test. Just in case I've done the merge and left the result in a branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git merge powerpc updates for 4.1 - Numerous minor fixes, cleanups etc. - More EEH work from Gavin to remove its dependency on device_nodes. - Memory hotplug implemented entirely in the kernel from Nathan Fontenot. - Removal of redundant CONFIG_PPC_OF by Kevin Hao (most of the noise in drivers/) - Rewrite of VPHN parsing logic tests from Greg Kurz. - A fix from Nish Aravamudan to reduce memory usage by clamping nodes_possible_map. - Support for pstore on powernv from Hari Bathini. - Removal of old powerpc specific byte swap routines by David Gibson. - Fix from Vasant Hegde to prevent the flash driver telling you it was flashing your firmware when it wasn't. - Patch from Ben Herrenschmidt to add an OPAL heartbeat driver. - Fix for an oops causing get/put_cpu_var() imbalance in perf by Jan Stancek. - Some fixes for migration from Tyrel Datwyler. - A new syscall to switch the cpu endian by Michael Ellerman. - Large series from Wei Yang to implement SRIOV, reviewed and acked by Bjorn. - A fix for the OPAL sensor driver from Cédric Le Goater. - Fixes to get STRICT_MM_TYPECHECKS building again by Michael Ellerman. - Large series from Daniel Axtens to make our PCI hooks per PHB rather than per machine. - Small patch from Sam Bobroff to explicitly abort non-suspended transactions on syscalls, plus a test to exercise it. - Numerous reworks and fixes for the 24x7 PMU from Sukadev Bhattiprolu. - Small patch to enable the hard lockup detector from Anton Blanchard. - Fix from Dave Olson for missing L2 cache information on some CPUs. - Some fixes from Michael Ellerman to get Cell machines booting again. - Freescale updates from Scott: Highlights include BMan device tree nodes, an MSI erratum workaround, a couple minor performance improvements, config updates, and misc fixes/cleanup. Alex Dowad (1): powerpc/kernel: Rename copy_thread() 'arg' argument to 'kthread_arg' Alexey Kardashevskiy (1): powerpc/pseries: Fix compile of memory hotplug without CONFIG_MEMORY_HOTREMOVE Andy Fleming (1): powerpc/corenet: Enable muxing MDIO buses via GPIO Anton Blanchard (5): powerpc: Change vrX register defines to vX to match gcc and glibc powerpc: Change vsrX register defines to vsX to match gcc and glibc oprofile: Disable oprofile NMI timer on ppc64 powerpc: Add ppc64 hard lockup detector support powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH Arseny Solokha (3): powerpc/boot: drop planetcore_set_serial_speed powerpc/qe: drop unused ucc_slow_poll_transmitter_now powerpc/mpic: remove unused functions Benjamin Herrenschmidt (5): powerpc: Make corenet64_defconfig a bit more useful net/ethernet/sfc: Don't use of_node_to_eeh_dev() media/bt8xx: Remove old powerpc cruft powerpc/powernv: Support OPAL requested heartbeat Merge branch 'next-eeh' into next-sriov Bjorn Helgaas (2): PCI: Print more info in sriov_enable() error message PCI: Index IOV resources in the conventional style Bogdan Purcareata (1): powerpc/mpic: Remove WHOAMI readback after EOI Cyril Bur (1): powerpc/powernv: Add interfaces for flash device access Cédric Le Goater (2):
Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
Hi Vasant, On 04/16/2015 08:52 AM, Vasant Hegde wrote: On 04/15/2015 06:42 PM, Jacek Anaszewski wrote: On 04/15/2015 12:15 PM, Vasant Hegde wrote: On 04/15/2015 02:12 PM, Jacek Anaszewski wrote: Hi Vasant, Hi Jacek, .../... I mean, we have to retain the state of LED across system reboot. Static variables are reinitialized on system reboot, aren't they? Sorry. I think comment was confusing.. As I understood, classdev_unregister call resets all LEDs state. However in our case, we don't want to change the LED state during system shutdown/reboot. Hence I have introduced state variable here. So during register call, I just disable LEDs so that any further call will just return. That way we retain LED state even after unloading module. Please let me know if there is any better way to achieve this. Since this is not a feature of the device, but rather a use case, then it cannot be hard coded in the driver this way. The solution I see is introducing a sysfs attribute that would determine if we want the LED to be turned off on unregistration or not. Hmmm. I thought having simple various is enough .. I don't know the usage of other LED drivers .. Just a thought .. How about enabling this feature in LED class itself ...Something like: - Add new attribute to generic LED class (say persistent)? - If drivers wants to retain LED state across reboot, then enable this option - During unregister call check for this attribute You can refer to the following driver to find out how to add the sysfs attribute: drivers/leds/leds-lm3533.c The attribute will also have to be documented, similarly to these: Documentation/ABI/testing/sysfs-class-led-driver-lm3533 Currently I don't have a good candidate for attribute name, so feel free to propose one. If you don't like generic attribute, then shall I introduce persistent attribute inside my driver. ? - By default this attribute is ON and if user wants he can disable this . - And I will have another variable (say op_support).. which I will disable in unload path.. .../... The label could be composed of segments and an ordinal number as labels have to be unique, e.g. attn_ident_0, attn_ident_1. The segments would have to be parsed by the driver to discover all the LED's available modes. nitpicking: identify is a verb and is not a proper name for the LED. Could you describe the purpose of this mode, so that we could come up with a better name? Each component (Field Replacement Unit) will have service indicator (LEDS) which can have below states : - OFF : no action - Identify: blinking state (user can use this state to identify particular component). In Power Systems world we call it as identify indicator.. Hence I retained same name here. How about just ident ? Sounds good. - fault : solid state (when component goes bad, LED goes to solid state) Note that our FW is capable of isolating some of the issues and it can turn on LEDs without OS interference. Does it mean that the LED can be controlled from hardware? If so, what would be software use cases then? The same question is related to the attn and indent states. - Identify LEDs: We have service processor interface to set/reset this LEDs.. Similar operation can be done from inband interface as well (via user space tools in Linux).. Later management layer can make use of this. - Fault / Attention : FW can SET these LEDs if its capable of isolating problem. Similarly host/user space can SET these LEDs if then can do fine grained problem isolation etc. Host/user space can RESET these LEDs. Hence we are adding host support to all the LEDs which can be modified by host. Hope this clarifies. Thanks for this explanation. I am changing my mind about these LEDs. Since they can be controlled from hardware without any system interaction, then turning them off on driver removal makes no sense. The LEDs could be turned on again even if the driver is unloaded. Since the driver doesn't perform any initialization of the LEDs, neither should it turn them off on removal. If I understand this correctly, then the solution with variable would do and no sysfs attribute would be required. -- Best Regards, Jacek Anaszewski ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
On 04/16/2015 02:21 PM, Jacek Anaszewski wrote: Hi Vasant, On 04/16/2015 08:52 AM, Vasant Hegde wrote: On 04/15/2015 06:42 PM, Jacek Anaszewski wrote: On 04/15/2015 12:15 PM, Vasant Hegde wrote: On 04/15/2015 02:12 PM, Jacek Anaszewski wrote: Hi Vasant, Hi Jacek, .../... I mean, we have to retain the state of LED across system reboot. Static variables are reinitialized on system reboot, aren't they? Sorry. I think comment was confusing.. As I understood, classdev_unregister call resets all LEDs state. However in our case, we don't want to change the LED state during system shutdown/reboot. Hence I have introduced state variable here. So during register call, I just disable LEDs so that any further call will just return. That way we retain LED state even after unloading module. Please let me know if there is any better way to achieve this. Since this is not a feature of the device, but rather a use case, then it cannot be hard coded in the driver this way. The solution I see is introducing a sysfs attribute that would determine if we want the LED to be turned off on unregistration or not. Hmmm. I thought having simple various is enough .. I don't know the usage of other LED drivers .. Just a thought .. How about enabling this feature in LED class itself ...Something like: - Add new attribute to generic LED class (say persistent)? - If drivers wants to retain LED state across reboot, then enable this option - During unregister call check for this attribute You can refer to the following driver to find out how to add the sysfs attribute: drivers/leds/leds-lm3533.c The attribute will also have to be documented, similarly to these: Documentation/ABI/testing/sysfs-class-led-driver-lm3533 Currently I don't have a good candidate for attribute name, so feel free to propose one. If you don't like generic attribute, then shall I introduce persistent attribute inside my driver. ? - By default this attribute is ON and if user wants he can disable this . - And I will have another variable (say op_support).. which I will disable in unload path.. .../... The label could be composed of segments and an ordinal number as labels have to be unique, e.g. attn_ident_0, attn_ident_1. The segments would have to be parsed by the driver to discover all the LED's available modes. nitpicking: identify is a verb and is not a proper name for the LED. Could you describe the purpose of this mode, so that we could come up with a better name? Each component (Field Replacement Unit) will have service indicator (LEDS) which can have below states : - OFF : no action - Identify: blinking state (user can use this state to identify particular component). In Power Systems world we call it as identify indicator.. Hence I retained same name here. How about just ident ? Sounds good. - fault : solid state (when component goes bad, LED goes to solid state) Note that our FW is capable of isolating some of the issues and it can turn on LEDs without OS interference. Does it mean that the LED can be controlled from hardware? If so, what would be software use cases then? The same question is related to the attn and indent states. - Identify LEDs: We have service processor interface to set/reset this LEDs.. Similar operation can be done from inband interface as well (via user space tools in Linux).. Later management layer can make use of this. - Fault / Attention : FW can SET these LEDs if its capable of isolating problem. Similarly host/user space can SET these LEDs if then can do fine grained problem isolation etc. Host/user space can RESET these LEDs. Hence we are adding host support to all the LEDs which can be modified by host. Hope this clarifies. Thanks for this explanation. I am changing my mind about these LEDs. Since they can be controlled from hardware without any system interaction, then turning them off on driver removal makes no sense. The LEDs could be turned on again even if the driver is unloaded. Since the driver doesn't perform any initialization of the LEDs, neither should it turn them off on removal. If I understand this correctly, then the solution with variable would do and no sysfs attribute would be required. Jacek, Thanks. Then I will retain current method. One question..What is the preferred way to name LED node in this case ? location_code:ATTENTION|IDENTIFY|FAULT OR location_code ident - attribute under each node fault attention -Vasant ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/4xx: Fix return value check in hsta_msi_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the functions platform_get_resource() and kmalloc()
returns NULL not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
index f366d2d..49e24f5 100644
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -130,7 +130,7 @@ static int hsta_msi_probe(struct platform_device *pdev)
int irq, ret, irq_count;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (IS_ERR(mem)) {
+ if (!mem) {
dev_err(dev, Unable to get mmio space\n);
return -EINVAL;
}
@@ -155,7 +155,7 @@ static int hsta_msi_probe(struct platform_device *pdev)
goto out;
ppc4xx_hsta_msi.irq_map = kmalloc(sizeof(int) * irq_count, GFP_KERNEL);
- if (IS_ERR(ppc4xx_hsta_msi.irq_map)) {
+ if (!ppc4xx_hsta_msi.irq_map) {
ret = -ENOMEM;
goto out1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] kvm: powerpc: Fix ppc64_defconfig + PPC_POWERNV=n build error
kvm_no_guest function calls power7_wakeup_loss to put the thread into the deepest supported idle state. power7_wakeup_loss is defined in arch/powerpc/kernel/idle_power7.S, which is compiled only when PPC_P7_NAP=y. And PPC_P7_NAP is selected when PPC_POWERNV=y. Hence in cases where PPC_POWERNV=n and KVM_BOOK3S_64_HV=y we see the following error: arch/powerpc/kvm/built-in.o: In function `kvm_no_guest': arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x42c): undefined reference to `power7_wakeup_loss' Fix this by adding PPC_POWERNV as a dependency for KVM_BOOK3S_64_HV. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- arch/powerpc/kvm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 11850f3..b3b3d9f 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -75,7 +75,7 @@ config KVM_BOOK3S_64 config KVM_BOOK3S_64_HV tristate KVM support for POWER7 and PPC970 using hypervisor mode in host - depends on KVM_BOOK3S_64 + depends on KVM_BOOK3S_64 PPC_POWERNV select KVM_BOOK3S_HV_POSSIBLE select MMU_NOTIFIER select CMA -- 1.9.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
On 04/16/2015 12:26 PM, Vasant Hegde wrote:
On 04/16/2015 02:21 PM, Jacek Anaszewski wrote:
Hi Vasant,
On 04/16/2015 08:52 AM, Vasant Hegde wrote:
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
.../...
I mean, we have to retain the state of LED across system reboot.
Static variables are reinitialized on system reboot, aren't they?
Sorry. I think comment was confusing..
As I understood, classdev_unregister call resets all LEDs state. However in our
case, we don't
want to change the LED state during system shutdown/reboot.
Hence I have introduced state variable here. So during register call, I just
disable LEDs so that any further call will just return. That way we retain LED
state even after unloading module.
Please let me know if there is any better way to achieve this.
Since this is not a feature of the device, but rather a use case, then
it cannot be hard coded in the driver this way. The solution I see is
introducing a sysfs attribute that would determine if we want the
LED to be turned off on unregistration or not.
Hmmm. I thought having simple various is enough ..
I don't know the usage of other LED drivers .. Just a thought .. How about
enabling this feature in LED class itself ...Something like:
- Add new attribute to generic LED class (say persistent)?
- If drivers wants to retain LED state across reboot, then enable this
option
- During unregister call check for this attribute
You can refer to the following driver to find out how to add the
sysfs attribute:
drivers/leds/leds-lm3533.c
The attribute will also have to be documented, similarly to these:
Documentation/ABI/testing/sysfs-class-led-driver-lm3533
Currently I don't have a good candidate for attribute
name, so feel free to propose one.
If you don't like generic attribute, then shall I introduce persistent
attribute inside my driver. ?
- By default this attribute is ON and if user wants he can disable this .
- And I will have another variable (say op_support).. which I will disable
in
unload path..
.../...
The label could be composed of segments and an ordinal number as
labels have to be unique, e.g. attn_ident_0, attn_ident_1.
The segments would have to be parsed by the driver to discover
all the LED's available modes.
nitpicking: identify is a verb and is not a proper name for the LED.
Could you describe the purpose of this mode, so that we could come
up with a better name?
Each component (Field Replacement Unit) will have service indicator (LEDS)
which
can have below states :
- OFF : no action
- Identify: blinking state (user can use this state to identify particular
component).
In Power Systems world we call it as identify indicator.. Hence I
retained same name here.
How about just ident ?
Sounds good.
- fault : solid state (when component goes bad, LED goes to solid state)
Note that our FW is capable of isolating some of the issues and it
can turn
on LEDs without OS
interference.
Does it mean that the LED can be controlled from hardware?
If so, what would be software use cases then? The same question is
related to the attn and indent states.
- Identify LEDs:
We have service processor interface to set/reset this LEDs.. Similar
operation
can be done from inband interface as well (via user space tools in Linux)..
Later management layer can make use of this.
- Fault / Attention :
FW can SET these LEDs if its capable of isolating problem.
Similarly host/user space can SET these LEDs if then can do fine grained
problem isolation etc.
Host/user space can RESET these LEDs.
Hence we are adding host support to all the LEDs which can be modified by host.
Hope this clarifies.
Thanks for this explanation.
I am changing my mind about these LEDs. Since they can be controlled
from hardware without any system interaction, then turning them off
on driver removal makes no sense. The LEDs could be turned on again even
if the driver is unloaded.
Since the driver doesn't perform any initialization of the LEDs,
neither should it turn them off on removal.
If I understand this correctly, then the solution with variable would
do and no sysfs attribute would be required.
Jacek,
Thanks. Then I will retain current method.
One question..What is the preferred way to name LED node in this case ?
location_code:ATTENTION|IDENTIFY|FAULT
OR
location_code
ident - attribute under each node
fault
attention
If possible locations are eclosure/descendent as in the documentation
you gave a reference to, then the related identifiers could be:
enclosure: encl
descendent: desc or fru (how does fru expand btw?)
Child nodes could be defined as follows:
led0 {
label = powernv0:encl:attn:ident:fault
}
led1 {
label = powernv1:encl::ident:fault
}
led2
[PATCH 2/2] sound: ppc: keywest: drop using attach adapter
As we now have deferred probing, we can use a custom mechanism and
finally get rid of the legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
sound/ppc/keywest.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
index 0d1c27e911b8dd..d7627bae08362e 100644
--- a/sound/ppc/keywest.c
+++ b/sound/ppc/keywest.c
@@ -52,7 +52,7 @@ static int keywest_attach_adapter(struct i2c_adapter *adapter)
return -EINVAL;
if (strncmp(adapter-name, mac-io, 6))
- return 0; /* ignored */
+ return -EINVAL; /* ignored */
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, keywest, I2C_NAME_SIZE);
@@ -100,7 +100,6 @@ static struct i2c_driver keywest_driver = {
.driver = {
.name = PMac Keywest Audio,
},
- .attach_adapter = keywest_attach_adapter,
.probe = keywest_probe,
.remove = keywest_remove,
.id_table = keywest_i2c_id,
@@ -132,16 +131,32 @@ int snd_pmac_tumbler_post_init(void)
/* exported */
int snd_pmac_keywest_init(struct pmac_keywest *i2c)
{
- int err;
+ struct i2c_adapter *adap;
+ int err, i = 0;
if (keywest_ctx)
return -EBUSY;
+ adap = i2c_get_adapter(0);
+ if (!adap)
+ return -EPROBE_DEFER;
+
keywest_ctx = i2c;
if ((err = i2c_add_driver(keywest_driver))) {
snd_printk(KERN_ERR cannot register keywest i2c driver\n);
+ i2c_put_adapter(adap);
return err;
}
- return 0;
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ err = keywest_attach_adapter(adap);
+ if (!err)
+ return 0;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
+ return -ENODEV;
}
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] i2c: rework last users of 2.4 style attach_adapter
The attach_adapter mechanism of the I2C framework is deprecated for years. There are two users left; drivers for old Macintosh computers. I got the idea of replacing this mechanism with a custom one with the help of deferred probing. Because I don't have the hardware, I modified the windtunnel driver to be runnable on my Renesas Lager board (ARM). This patch is not in this series but in the branch mentioned below. I first verified that the attach_adapter method was in deed used for bus scanning. When scanning, the driver rightfully failed on detecting the actual i2c clients because there is no such hardware on my board. However, the actual scanning happened. Using my custom mechanism, the same happens: all busses get scanned, then the clients cannot be detected. Since I didn't change the actual detection code, I assume that it should be working on those Macintosh devices as well. The keywest driver is only compile-tested. That being said, I'd be more than happy, if we could find someone willing to test these patches. Top-of-tree kernel would be nice, but these patches can easily be backported to probably the beginning of deferred probing. I will also notify some ppc lists of distributions of this thread for further help. If this works out, we can _finally_ get rid of this stone-age mechanism and clean up the i2c core. Changes since RFC: return -ENODEV instead of 0 when exiting the while loop (= nothing found on all busses) The branch I used for ARM compilation is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/attach_adapter_removal_with_arm_compile-experimental Thanks, Wolfram Wolfram Sang (2): macintosh: therm_windtunnel: drop using attach adapter sound: ppc: keywest: drop using attach adapter drivers/macintosh/therm_windtunnel.c | 25 +++-- sound/ppc/keywest.c | 23 +++ 2 files changed, 42 insertions(+), 6 deletions(-) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/dts: Fix incorrect clock-names property
From: Igal Liberman igal.liber...@freescale.com Signed-off-by: Igal Liberman igal.liber...@freescale.com --- arch/powerpc/boot/dts/fsl/t2081si-post.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi index 3dee307..1462431 100644 --- a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi @@ -589,7 +589,7 @@ compatible = fsl,qoriq-core-mux-2.0; clocks = pll0 0, pll0 1, pll0 2, pll1 0, pll1 1, pll1 2; - clock-names = pll0, pll0-div2, pll1-div4, + clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4; clock-output-names = cmux0; }; @@ -600,7 +600,7 @@ compatible = fsl,qoriq-core-mux-2.0; clocks = pll0 0, pll0 1, pll0 2, pll1 0, pll1 1, pll1 2; - clock-names = pll0, pll0-div2, pll1-div4, + clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4; clock-output-names = cmux1; }; -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[v4] clk: qoriq: Add support for the FMan clock
From: Igal Liberman igal.liber...@freescale.com
This patch depends on the following patches:
https://patchwork.ozlabs.org/patch/461151/
https://patchwork.ozlabs.org/patch/461155/
This patche is described by the following binding document update:
https://patchwork.ozlabs.org/patch/461166/
v4: - Replaced fsl,b4-device-config with
fsl,b4860/b4420-device-config
- Updated error messages
v3: Updated commit message
v2: - Added clock maintainers
- Cached FMan clock parent during initialization
- Register the clock after checking if the hardware exists
- updated error messages
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
drivers/clk/clk-qoriq.c | 213 +++
1 file changed, 213 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index cda90a9..871c6df 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/slab.h
+#include asm/fsl_guts.h
+
struct cmux_clk {
struct clk_hw hw;
void __iomem *reg;
@@ -155,6 +157,216 @@ err_name:
kfree(parent_names);
}
+/* Table for matching compatible strings, for device tree
+ * guts node, for QorIQ SOCs.
+ * fsl,qoriq-device-config-2.0 corresponds to T4 B4
+ * SOCs. For the older SOCs fsl,qoriq-device-config-1.0
+ * string would be used.
+ */
+
+static const struct of_device_id guts_device_ids[] = {
+ { .compatible = fsl,qoriq-device-config-1.0, },
+ { .compatible = fsl,qoriq-device-config-2.0, },
+ {}
+};
+
+/* P2, P3, P4, P5 */
+#define FM1_CLK_SEL_SHIFT 30
+#define FM1_CLK_SELBIT(FM1_CLK_SEL_SHIFT)
+#define FM2_CLK_SEL_SHIFT 29
+#define FM2_CLK_SELBIT(FM2_CLK_SEL_SHIFT)
+#define HWA_ASYNC_DIV_SHIFT26
+#define HWA_ASYNC_DIV BIT(HWA_ASYNC_DIV_SHIFT)
+
+/* B4, T2 */
+#define HWA_CGA_M1_CLK_SEL_SHIFT 29
+#define HWA_CGA_M1_CLK_SEL (BIT(HWA_CGA_M1_CLK_SEL_SHIFT + 2) |\
+BIT(HWA_CGA_M1_CLK_SEL_SHIFT + 1) |\
+BIT(HWA_CGA_M1_CLK_SEL_SHIFT))
+
+/* T4240 */
+#define HWA_CGB_M1_CLK_SEL_SHIFT 26
+#define HWA_CGB_M1_CLK_SEL (BIT(HWA_CGB_M1_CLK_SEL_SHIFT + 2) |\
+BIT(HWA_CGB_M1_CLK_SEL_SHIFT + 1) |\
+BIT(HWA_CGB_M1_CLK_SEL_SHIFT))
+#define HWA_CGB_M2_CLK_SEL_SHIFT 3
+#define HWA_CGB_M2_CLK_SEL (BIT(HWA_CGB_M2_CLK_SEL_SHIFT + 2) |\
+BIT(HWA_CGB_M2_CLK_SEL_SHIFT + 1) |\
+BIT(HWA_CGB_M2_CLK_SEL_SHIFT))
+
+static u8 get_fm_clk_parent(struct clk_hw *hw)
+{
+ return hw-init-flags;
+}
+
+static const struct clk_ops fm_clk_ops = {
+ .get_parent = get_fm_clk_parent,
+};
+
+static int get_fm_clk_idx(int fm_id, int *fm_clk_idx)
+{
+ struct ccsr_guts __iomem *guts_regs = NULL;
+ struct device_node *guts;
+ uint32_t reg = 0;
+ int clk_src = 0;
+
+ guts = of_find_matching_node(NULL, guts_device_ids);
+ if (!guts) {
+ pr_err(%s(): could not find GUTS node\n, __func__);
+ return -ENODEV;
+ }
+
+ guts_regs = of_iomap(guts, 0);
+ of_node_put(guts);
+ if (!guts_regs) {
+ pr_err(%s(): ioremap of GUTS node failed\n, __func__);
+ return -ENODEV;
+ }
+
+ if (of_device_is_compatible(guts, fsl,p1023-guts) ||
+ of_device_is_compatible(guts, fsl,t1040-device-config)) {
+ /* P1023 and T1040 have only one optional clock source */
+ *fm_clk_idx = 0;
+ } else if (of_device_is_compatible(guts, fsl,p2041-device-config) ||
+ of_device_is_compatible(guts, fsl,p3041-device-config) ||
+ of_device_is_compatible(guts, fsl,p4080-device-config)) {
+ /* Read RCW*/
+ reg = ioread32be(guts_regs-rcwsr[7]);
+
+ if (fm_id == 0)
+ *fm_clk_idx = (reg FM1_CLK_SEL)
+ FM1_CLK_SEL_SHIFT;
+ else
+ *fm_clk_idx = (reg FM2_CLK_SEL)
+ FM2_CLK_SEL_SHIFT;
+ } else if (of_device_is_compatible(guts, fsl,p5020-device-config) ||
+ of_device_is_compatible(guts, fsl,p5040-device-config)) {
+ /* Read RCW */
+ reg = ioread32be(guts_regs-rcwsr[7]);
+
+ if (fm_id == 0)
+ clk_src = (reg FM1_CLK_SEL) FM1_CLK_SEL_SHIFT;
+ else
+ clk_src = (reg FM2_CLK_SEL) FM2_CLK_SEL_SHIFT;
+
+ if (clk_src == 0) {
+ *fm_clk_idx = 0;
+
[PATCH] powerpc/dts: Move pll0/1-div4 index
From: Igal Liberman igal.liber...@freescale.com This patch updates pll0/1-div4 index to '3'. Originally it was '2'. The following patch adds pll0/1-div3 option: https://patchwork.ozlabs.org/patch/461151/ After this patch, index '2' becomes pll0/1-div3. This patch based on top of the following: https://patchwork.ozlabs.org/patch/461811/ Signed-off-by: Igal Liberman igal.liber...@freescale.com --- arch/powerpc/boot/dts/fsl/b4si-post.dtsi|4 ++-- arch/powerpc/boot/dts/fsl/t2081si-post.dtsi |8 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |8 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi index 8d061a4..d6c410d 100644 --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi @@ -446,8 +446,8 @@ #clock-cells = 0; reg = 0x0 0x4; compatible = fsl,qoriq-core-mux-2.0; - clocks = pll0 0, pll0 1, pll0 2, - pll1 0, pll1 1, pll1 2; + clocks = pll0 0, pll0 1, pll0 3, + pll1 0, pll1 1, pll1 3; clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4; clock-output-names = cmux0; diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi index 1462431..e347f2d 100644 --- a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi @@ -587,8 +587,8 @@ #clock-cells = 0; reg = 0x0 4; compatible = fsl,qoriq-core-mux-2.0; - clocks = pll0 0, pll0 1, pll0 2, -pll1 0, pll1 1, pll1 2; + clocks = pll0 0, pll0 1, pll0 3, +pll1 0, pll1 1, pll1 3; clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4; clock-output-names = cmux0; @@ -598,8 +598,8 @@ #clock-cells = 0; reg = 0x20 4; compatible = fsl,qoriq-core-mux-2.0; - clocks = pll0 0, pll0 1, pll0 2, -pll1 0, pll1 1, pll1 2; + clocks = pll0 0, pll0 1, pll0 3, +pll1 0, pll1 1, pll1 3; clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4; clock-output-names = cmux1; diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi index 1c91d00..1fdce44 100644 --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi @@ -1099,8 +1099,8 @@ #clock-cells = 0; reg = 0x0 0x4; compatible = fsl,qoriq-core-mux-2.0; - clocks = pll0 0, pll0 1, pll0 2, - pll1 0, pll1 1, pll1 2, + clocks = pll0 0, pll0 1, pll0 3, + pll1 0, pll1 1, pll1 3, pll2 0, pll2 1, pll2 2; clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4, @@ -1112,8 +1112,8 @@ #clock-cells = 0; reg = 0x20 0x4; compatible = fsl,qoriq-core-mux-2.0; - clocks = pll0 0, pll0 1, pll0 2, - pll1 0, pll1 1, pll1 2, + clocks = pll0 0, pll0 1, pll0 3, + pll1 0, pll1 1, pll1 3, pll2 0, pll2 1, pll2 2; clock-names = pll0, pll0-div2, pll0-div4, pll1, pll1-div2, pll1-div4, -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[v3] dt/bindings: fsl/guts: Added global-utilities compatibles
From: Igal Liberman igal.liber...@freescale.com v3 - Addressed Scott's feedback: Added fsl,chip-guts v2 - Addressed Scott's feedback Signed-off-by: Igal Liberman igal.liber...@freescale.com --- .../devicetree/bindings/powerpc/fsl/guts.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt index 7f150b5..b71b203 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt @@ -9,6 +9,11 @@ Required properties: - compatible : Should define the compatible device type for global-utilities. + Possible compatibles: + fsl,qoriq-device-config-1.0 + fsl,qoriq-device-config-2.0 + fsl,chip-device-config + fsl,chip-guts - reg : Offset and length of the register set for the device. Recommended properties: -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v8 12/31] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On 04/16/2015 03:55 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:30:54PM +1000, Alexey Kardashevskiy wrote:
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch/powerpc/kernel/iommu.c | 34
arch/powerpc/platforms/powernv/pci-ioda.c | 38 +
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 17 ++--
arch/powerpc/platforms/powernv/pci.c| 2 +-
arch/powerpc/platforms/powernv/pci.h| 4 +-
arch/powerpc/platforms/pseries/iommu.c | 9 ++-
drivers/vfio/vfio_iommu_spapr_tce.c | 120
8 files changed, 160 insertions(+), 82 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index eb75726..667aa1a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -90,9 +90,7 @@ struct iommu_table {
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
-#ifdef CONFIG_IOMMU_API
- struct iommu_group *it_group;
-#endif
+ struct iommu_table_group *it_group;
struct iommu_table_ops *it_ops;
void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
@@ -126,14 +124,24 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+
+struct iommu_table_group {
#ifdef CONFIG_IOMMU_API
-extern void iommu_register_group(struct iommu_table *tbl,
+ struct iommu_group *group;
+#endif
+ struct iommu_table tables[IOMMU_TABLE_GROUP_MAX_TABLES];
There's nothing to indicate which of the tables are in use at the
current time. I mean, it doesn't matter now because there's only one,
but the patch doesn't make a whole lot of sense without that.
+};
+
+#ifdef CONFIG_IOMMU_API
+extern void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
#else
-static inline void iommu_register_group(struct iommu_table *tbl,
+static inline void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number,
unsigned long pe_num)
{
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b39d00a..fd49c8e 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -712,17 +712,20 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
struct iommu_table *iommu_table_alloc(int node)
{
- struct iommu_table *tbl;
+ struct iommu_table_group *table_group;
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
+ table_group = kzalloc_node(sizeof(struct iommu_table_group), GFP_KERNEL,
+ node);
+ table_group-tables[0].it_group = table_group;
- return tbl;
+ return table_group-tables[0];
}
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
Surely the free function should take a table group rather than a table
as argument.
No, it should not. Tables lifetime is not the same even within the same group.
{
unsigned long bitmap_sz;
unsigned int order;
+ struct iommu_table_group *table_group = tbl-it_group;
if (!tbl || !tbl-it_map) {
printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
@@ -738,9 +741,9 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
clear_bit(0, tbl-it_map);
#ifdef CONFIG_IOMMU_API
- if (tbl-it_group) {
- iommu_group_put(tbl-it_group);
- BUG_ON(tbl-it_group);
+ if (table_group-group) {
+ iommu_group_put(table_group-group);
+ BUG_ON(table_group-group);
}
#endif
@@ -756,7 +759,7 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
free_pages((unsigned long) tbl-it_map, order);
/* free table */
- kfree(tbl);
+ kfree(table_group);
}
/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -903,11 +906,12 @@ EXPORT_SYMBOL_GPL(iommu_direction_to_tce_perm);
*/
static void group_release(void *iommu_data)
{
- struct iommu_table *tbl = iommu_data;
- tbl-it_group = NULL;
+
Re: [PATCH kernel v8 21/31] powerpc/iommu: Split iommu_free_table into 2 helpers
On 04/16/2015 04:46 PM, David Gibson wrote:
On Fri, Apr 10, 2015 at 04:31:03PM +1000, Alexey Kardashevskiy wrote:
The iommu_free_table helper release memory it is using (the TCE table and
@it_map) and release the iommu_table struct as well. We might not want
the very last step as we store iommu_table in parent structures.
Yeah, as I commented on the earlier patch, freeing the surrounding
group from a function taking just the individual table is wrong.
This is iommu tables created by the old code which stores these iommu_table
struct pointers in device nodes. I believe there is a plan to get rid of
iommu tables there and when this is done, this workaround will be gone.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 57
2 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index bde7ee7..8ed4648 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -127,6 +127,7 @@ static inline void *get_iommu_table_base(struct device *dev)
extern struct iommu_table *iommu_table_alloc(int node);
/* Frees table for an individual device node */
+extern void iommu_reset_table(struct iommu_table *tbl, const char *node_name);
extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
/* Initializes an iommu_table based in values set in the passed-in
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 501e8ee..0bcd988 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -721,24 +721,46 @@ struct iommu_table *iommu_table_alloc(int node)
return table_group-tables[0];
}
+void iommu_reset_table(struct iommu_table *tbl, const char *node_name)
+{
+ if (!tbl)
+ return;
+
+ if (tbl-it_map) {
+ unsigned long bitmap_sz;
+ unsigned int order;
+
+ /*
+* In case we have reserved the first bit, we should not emit
+* the warning below.
+*/
+ if (tbl-it_offset == 0)
+ clear_bit(0, tbl-it_map);
+
+ /* verify that table contains no entries */
+ if (!bitmap_empty(tbl-it_map, tbl-it_size))
+ pr_warn(%s: Unexpected TCEs for %s\n, __func__,
+ node_name);
+
+ /* calculate bitmap size in bytes */
+ bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
+
+ /* free bitmap */
+ order = get_order(bitmap_sz);
+ free_pages((unsigned long) tbl-it_map, order);
+ }
+
+ memset(tbl, 0, sizeof(*tbl));
+}
+
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
- unsigned long bitmap_sz;
- unsigned int order;
struct iommu_table_group *table_group = tbl-it_group;
- if (!tbl || !tbl-it_map) {
- printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
- node_name);
+ if (!tbl)
return;
- }
- /*
-* In case we have reserved the first bit, we should not emit
-* the warning below.
-*/
- if (tbl-it_offset == 0)
- clear_bit(0, tbl-it_map);
+ iommu_reset_table(tbl, node_name);
#ifdef CONFIG_IOMMU_API
if (table_group-group) {
@@ -747,17 +769,6 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
}
#endif
- /* verify that table contains no entries */
- if (!bitmap_empty(tbl-it_map, tbl-it_size))
- pr_warn(%s: Unexpected TCEs for %s\n, __func__, node_name);
-
- /* calculate bitmap size in bytes */
- bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
-
- /* free bitmap */
- order = get_order(bitmap_sz);
- free_pages((unsigned long) tbl-it_map, order);
-
/* free table */
kfree(table_group);
}
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
-Original Message- From: Wood Scott-B07421 Sent: Thursday, April 09, 2015 5:31 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org; Schmitt Richard-B43082 Subject: Re: new way of writing defconfigs for freescale's powerpc platforms On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. If we don't have separate build for p1/p2/p4/t1/t2/b4, in what way do we build for these SoC with merge_config approach? Do you have any suggestions? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/16/2015 12:44 AM, Bob Cochran wrote: On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. Here is a link to a patch from a Freescale developer introducing Yocto kernel tool support (description files configuration fragments) to the meta-fsl-ppc repo (FSL QorIQ SDK on Yocto). https://lists.yoctoproject.org/pipermail/meta-freescale/2014-October/010890.html It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] macintosh: therm_windtunnel: drop using attach adapter
As we now have deferred probing, we can use a custom mechanism and
finally get rid of the legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/macintosh/therm_windtunnel.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 835ca8be4c1632..57909a3ce67bf2 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -422,7 +422,6 @@ static struct i2c_driver g4fan_driver = {
.driver = {
.name = therm_windtunnel,
},
- .attach_adapter = do_attach,
.probe = do_probe,
.remove = do_remove,
.id_table = therm_windtunnel_id,
@@ -435,7 +434,29 @@ static struct i2c_driver g4fan_driver = {
static int therm_of_probe(struct platform_device *dev)
{
- return i2c_add_driver( g4fan_driver );
+ struct i2c_adapter *adap;
+ int ret, i = 0;
+
+ adap = i2c_get_adapter(0);
+ if (!adap)
+ return -EPROBE_DEFER;
+
+ ret = i2c_add_driver(g4fan_driver);
+ if (ret) {
+ i2c_put_adapter(adap);
+ return ret;
+ }
+
+ /* We assume Macs have consecutive I2C bus numbers starting at 0 */
+ while (adap) {
+ do_attach(adap);
+ if (x.running)
+ return 0;
+ i2c_put_adapter(adap);
+ adap = i2c_get_adapter(++i);
+ }
+
+ return -ENODEV;
}
static int
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/5] perf: Add a flags parameter to pmu txn interfaces
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Apr 07, 2015 at 05:34:55PM -0700, Sukadev Bhattiprolu wrote:
| diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
| index 2b62198..4dc3d70 100644
| --- a/include/linux/perf_event.h
| +++ b/include/linux/perf_event.h
| @@ -240,20 +240,27 @@ struct pmu {
| *
| * Start the transaction, after this -add() doesn't need to
| * do schedulability tests.
| +*
| +* Optional.
| */
| - void (*start_txn) (struct pmu *pmu); /* optional */
| +#define PERF_PMU_TXN_ADD 0x1 /* txn to add/schedule event on
PMU */
|
| Please do not interleave these flags in the structure. Maybe place it
| near PERF_EVENT_TXN.
Ok.
|
| + void (*start_txn) (struct pmu *pmu, int flags);
| /*
| * If -start_txn() disabled the -add() schedulability test
| * then -commit_txn() is required to perform one. On success
| * the transaction is closed. On error the transaction is kept
| * open until -cancel_txn() is called.
| +*
| +* Optional.
| */
| - int (*commit_txn) (struct pmu *pmu); /* optional */
| + int (*commit_txn) (struct pmu *pmu, int flags);
| /*
| * Will cancel the transaction, assumes -del() is called
| * for each successful -add() during the transaction.
| +*
| +* Optional.
| */
| - void (*cancel_txn) (struct pmu *pmu); /* optional */
| + void (*cancel_txn) (struct pmu *pmu, int flags);
|
| /*
| * Will return the value for perf_event_mmap_page::index for this event,
|
| So (again), why also pass the flags to cancel/commit ?
|
| The transaction state _has_ to already record it, otherwise it doesn't
| know if add/read are part of one.
I had replied to your earlier mail and added a Note to this patch
description. I was hesitating making more intrusive changes to PMUs
that don't care about the new txn type.
But, I agree, it is better to go ahead and update all PMUs to save
the state and check. Will do that in the next version.
Sukadev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
Ingo Molnar [mi...@kernel.org] wrote: Meant to Cc Tom Huynh as they had a related patchset a few months ago. | | * Michael Ellerman m...@ellerman.id.au wrote: | | On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote: | * Sukadev Bhattiprolu suka...@linux.vnet.ibm.com wrote: | |This is another attempt to resurrect Andi Kleen's patchset so users |can specify perf events by their event names rather than raw codes. | |This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0. |(I fixed minor and not so minor conflicts). | | So this series shows some progress, but instead of this limited | checkout ability I'd still prefer it if 'perf download' downloaded | the latest perf code itself and built it - it shouldn't be limited | to just a small subset of the perf source code! | | Ingo, can you please stop blocking this? It's getting ridiculous. | | We've been waiting over 8 months for this to go in. | | We just merged a patch series that was first sent in 2013. Some things | take time to get right. I used to rebuild git years ago to work around bugs in rebase, but rarely need to rebuild these days, because it is stable. I am guessing it is the same for most users of perf. IOW, perf download/upgrade can be extended to fetch and build, but dont' understand why that is _required_ to _use_ the JSON files. - perf having an ability to parse JSON files - perf downloading JSON files - perf downloading latest source code - perf downloading dependent RPMS/packages to build (which seem to be tied to distros) all seem like independent steps to me. If current design can be tweaked to not constrain future choices, we should definitely do that. If not, can we make incremental progress on this? If necessary, we could add an option to 'perf upgrade' to fetch only the JSON files? Or by default, 'perf upgrade' can assume --all and download everything it can download. In the future we can add --json-files, --sources etc and still ahve --all fetch everything it can. Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
|
| * Michael Ellerman m...@ellerman.id.au wrote:
|
| We just merged a patch series that was first sent in 2013. Some
| things take time to get right.
|
| The first attempt to get symbolic event name support into perf was
| sent in 2010, that's FIVE years ago [1].
|
| kgdb took even longer, I think it was first proposed before 2000, over
| 10 years before it got merged?
|
| fs/overlayfs/ took similarly long I think, the first (Unionfs) patches
| I remember were from around 2003 - 11 years before the functionality
| was merged?
|
| And what complicated feature are we asking for? The ability to map a
| human readable name to a hex code, it has the complexity of a first
| year programming assignment.
|
| No, what you are asking for, and which I NAK-ed, is:
|
| - to add a very limited 'update perf' capability which only updates a
|single issue that you care about, with no ability to do more.
Yes, we are trying to solve one really annoying problem without precluding
the ability to do more (aka leave things better than they are even if we
can't solve everything).
Besides, I thought the discussion was where to host the JSON files.
I was not aware of the requirement to download/rebuild perf or not use
JSON at all (i.e generate data structures during build?).
|The 'perf upgrade' prototype I sent can update all or part of perf.
|(The latest version is attached further below.)
|
| - to break the 'single binary' property of perf that many people rely on
Thats the part, I am having trouble with.
If the JSON files are like /etc/perfconfig, we don't need to rebuild the
binary when a config file changes right?
Second, if I build perf on my Power8 box, would the perf binary only include
events on my specific revision of the CPU or all Power8 versions? Would the
perf binary from Power8 include events from all revisions of Power7 and
Power8?
If we include all possible revisions of the CPU, we would bloat perf.
If not we break the ability/convenience of copying rpms from one system
to the other? And we need to rebuild perf if the CPU on my system is
replaced and there are a couple of new event codes in the new CPU?
|
| - to add JSON parsing overhead to every invocation of perf instead of
|pre-parsing the event tables at build time and putting them into
|a nice data structure.
|
| - to blindly follow some poorly constructed vendor format with no
|high level structure, that IMHO didn't work very well when OProfile
|was written, and misrepresenting it as 'symbolic event names'.
|
|Take a look at:
|
| https://download.01.org/perfmon/HSW/Haswell_core_V17.json
|
|and weep.
Evil vendor formats, but to be fair, here is what _we_ have today:
perf stat -e r10068,r20036,r40060,r40ac sleep 1
Performance counter stats for 'sleep 1':
554,608 r10068
47,948 r20036
491,084 r40060
249 r40ac
1.001561257 seconds time elapsed
| How is one supposed to see the higher level structure of
|the events with a format like that?
True, having events like 'cycles', 'branches' makes sense, but there
are so many different flavors of run cycles events in just Power8.
PM_ANY_THRD_RUN_CYC,
PM_MRK_RUN_CYC,
PM_RUN_CYC,
PM_RUN_CYC_SMT2_MODE,
PM_RUN_CYC_SMT2_SHRD_MODE,
PM_RUN_CYC_SMT2_SPLIT_MODE,
PM_RUN_CYC_SMT4_MODE,
PM_RUN_CYC_SMT8_MODE,
PM_RUN_CYC_ST_MODE,
PM_THRD_ALL_RUN_CYC,
PM_TM_TRANS_RUN_CYC,
PM_TM_TX_PASS_RUN_CYC,
Are we trying to build a high level structures across architectures?
|
| - to add an ABI to support those vendor files
|
| And those are IMHO five good technical reasons to disagree with your
| approach.
|
| My suggestion to resolve the technical objections and lift the NAK
| would be:
|
| - to add the tables to the source code, in a more human readable
|format and (optionally) structure the event names better into a
|higher level hierarchy, than the humungous linear dumps with no
|explanations that you propose - while still supporting the 'raw'
|vendor event names you want to use, for those people who are used
|to them.
|
A bit confused.
Have the JSON files in the tree and generate the C structure during
build?
Or, ditch the JSON files and add something like this in say,
tools/perf/arch/powerpc/util/power8-events.h?
static const struct events power8_events[] = {
[ 0 ] = {
.name = PM_1LPAR_CYC,
.code = 0x1f05e,
.brief_desc = Number of cycles in single lpar mode. All threads in
the core are assigned to the same lpar,,
.public_desc = Number of cycles in single lpar mode.,,
Re: [PATCH v2 4/5] perf: Define PMU_TXN_READ interface
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Apr 07, 2015 at 05:34:58PM -0700, Sukadev Bhattiprolu wrote:
| diff --git a/kernel/events/core.c b/kernel/events/core.c
| index 1ac99d1..a001582 100644
| --- a/kernel/events/core.c
| +++ b/kernel/events/core.c
| @@ -3644,6 +3644,33 @@ static void orphans_remove_work(struct work_struct
*work)
| put_ctx(ctx);
| }
|
| +/*
| + * Use the transaction interface to read the group of events in @leader.
| + * PMUs like the 24x7 counters in Power, can use this to queue the events
| + * in the -read() operation and perform the actual read in -commit_txn.
| + *
| + * Other PMUs can ignore the -start_txn and -commit_txn and read each
| + * PMU directly in the -read() operation.
| + */
| +static int perf_event_read_txn(struct perf_event *leader)
|
| perf_event_read_group() might be a better name. Ah, I see that's already
| taken. Bugger.
|
| See the below patch.
Sure, will include your patch in the next version and use
perf_event_read_group().
|
| +{
| + int ret;
| + struct perf_event *sub;
| + struct pmu *pmu;
| +
| + pmu = leader-pmu;
| +
| + pmu-start_txn(pmu, PERF_PMU_TXN_READ);
| +
| + perf_event_read(leader);
| + list_for_each_entry(sub, leader-sibling_list, group_entry)
| + perf_event_read(sub);
| +
| + ret = pmu-commit_txn(pmu, PERF_PMU_TXN_READ);
| +
| + return ret;
| +}
|
| And while were here, should we change the NOP txn implementation to not
| call perf_pmu_disable for TXN_READ ?
|
| That seems entirely unneeded in this case.
Yes. Should we use a per-cpu, per-pmu variable to save/check the
transaction type like this? (I am using the cpuhw-group_flag in
x86, Power and other PMUs)
From 2f3658b0b131739dc08e0d6d579e58864d1777bc Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Thu, 9 Apr 2015 13:47:50 -0400
Subject: [PATCH 1/1] perf: Have NOP txn interface ignore non ADD txns
The NOP txn interface should ignore non TXN_ADD transactions and
avoid disabling/enabling the PMU.
Use a per-cpu, per-PMU flag to store/check the type of transaction
in progress.
Thanks to Peter Zijlstra for the input.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9e869b2..9466864 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -160,7 +160,10 @@ struct perf_event;
/*
* Common implementation detail of pmu::{start,commit,cancel}_txn
*/
-#define PERF_EVENT_TXN 0x1
+#define PERF_EVENT_TXN_ADD 0x1/* txn to add/schedule event on PMU */
+#define PERF_EVENT_TXN_READ 0x2/* txn to add/schedule event on PMU */
+
+#define PERF_EVENT_TXN_MASK (PERF_EVENT_TXN_ADD|PERF_EVENT_TXN_READ)
/**
* pmu::capabilities flags
@@ -240,8 +243,10 @@ struct pmu {
*
* Start the transaction, after this -add() doesn't need to
* do schedulability tests.
+*
+* Optional.
*/
- void (*start_txn) (struct pmu *pmu); /* optional */
+ void (*start_txn) (struct pmu *pmu, int flags);
/*
* If -start_txn() disabled the -add() schedulability test
* then -commit_txn() is required to perform one. On success
@@ -534,6 +534,7 @@ struct perf_cpu_context {
ktime_t hrtimer_interval;
struct pmu *unique_pmu;
struct perf_cgroup *cgrp;
+ int group_flag;
};
struct perf_output_handle {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0ebc468..08d0c3e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6746,18 +6746,35 @@ static int perf_pmu_nop_int(struct pmu *pmu)
static void perf_pmu_start_txn(struct pmu *pmu, int flags)
{
- perf_pmu_disable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu-pmu_cpu_context);
+
+ BUG_ON(cpuctx-group_flag);
+
+ cpuctx-group_flag = flags;
+
+ if (flags PERF_EVENT_TXN_ADD)
+ perf_pmu_disable(pmu);
}
static int perf_pmu_commit_txn(struct pmu *pmu)
{
- perf_pmu_enable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu-pmu_cpu_context);
+
+ if (cpuctx-group_flag PERF_EVENT_TXN_ADD)
+ perf_pmu_enable(pmu);
+
+ cpuctx-group_flag = ~PERF_EVENT_TXN_MASK;
return 0;
}
static void perf_pmu_cancel_txn(struct pmu *pmu)
{
- perf_pmu_enable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu-pmu_cpu_context);
+
+ if (cpuctx-group_flag PERF_EVENT_TXN_ADD)
+ perf_pmu_enable(pmu);
+
+ cpuctx-group_flag = ~PERF_EVENT_TXN_MASK;
}
static int perf_event_idx_default(struct perf_event *event)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Re: [PATCH v10 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan sowmini.varad...@oracle.com Date: Thu, 9 Apr 2015 15:33:29 -0400 Investigation of network performance on Sparc shows a high degree of locking contention in the IOMMU allocator, and it was noticed that the PowerPC code has a better locking model. This patch series tries to extract the generic parts of the PowerPC code so that it can be shared across multiple PCI devices and architectures. Series applied, thanks everyone for all the hard work! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
Hi, Scott.
On Apr 16 2015, Scott Wood wrote:
On Thu, 2015-04-16 at 21:01 -0300, Rogério Brito wrote:
On Apr 16 2015, Scott Wood wrote:
On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
Is there any proper way for me to discover what device name the kernel
uses? I have tried the following command lines without success:
1 -
mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
2 -
mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
3 -
mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
Look in sysfs.
The output that I get from sysfs is:
# ls -l /sys/block/mtdblock0
lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -
../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0
# cat /sys/devices/platform/physmap-flash.0/uevent
DRIVER=physmap-flash
MODALIAS=platform:physmap-flash
# cat /sys/devices/platform/physmap-flash.0/driver_override
(null)
So, it is saying that the driver is physmap-flash, right?
It looks like the device name is physmap-flash.0. You're partitioning
the device, not the driver.
Sure, the device, not the driver. :) I simply thought that the trailing .0
was a way to disambiguate from multiple devices that might (perhaps) be
activated by the same driver.
Regardless, I guess that I have already tried this physmap-flash.0 thing,
but I will let you know the results in a few minutes. :) I have just
finished compiling the kernel with that (forced) command line and I'm
rebooting the system now.
Yay! It worked:
,
| physmap platform flash device: 0040 at ffc0
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID
0x04 Chip ID 0x7e
| Amd/Fujitsu Extended Query Table at 0x0040
| Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
| 4 cmdlinepart partitions found on MTD device physmap-flash.0
| Creating 4 MTD partitions on physmap-flash.0:
| 0x-0x0030 : firmimg
| 0x0030-0x0037 : bootcode
| 0x0037-0x0038 : status
| 0x0038-0x0040 : conf
`
Now, the next step is to learn this DTS thing and send patches to two DTS
files. :)
Thank you so very much,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Move pll0/1-div4 index
On Thu, 2015-04-16 at 15:08 +0300, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com This patch updates pll0/1-div4 index to '3'. Originally it was '2'. The following patch adds pll0/1-div3 option: https://patchwork.ozlabs.org/patch/461151/ After this patch, index '2' becomes pll0/1-div3. This patch based on top of the following: https://patchwork.ozlabs.org/patch/461811/ Signed-off-by: Igal Liberman igal.liber...@freescale.com This needs to be done in the same patch as the provider change, to avoid a buggy intermediate state. Will there be a new binding patch coming? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Thu, 2015-04-16 at 01:11 -0500, Liberman Igal-B31950 wrote:
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, April 15, 2015 8:36 PM
To: Liberman Igal-B31950
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Tue, 2015-04-14 at 13:56 +0300, Igal.Liberman wrote:
From: Igal Liberman igal.liber...@freescale.com
v3: Addressed feedback from Scott:
- Removed clock specifier description.
v2: Addressed feedback from Scott:
- Moved the fman-clk-mux clock provider details
under clocks property.
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
.../devicetree/bindings/clock/qoriq-clock.txt | 17
+++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index b0d7b73..2bb3b38 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -65,9 +65,10 @@ Required properties:
It takes parent's clock-frequency as its clock.
* fsl,qoriq-platform-pll-1.0 for the platform PLL clock (v1.0)
* fsl,qoriq-platform-pll-2.0 for the platform PLL clock (v2.0)
+ * fsl,fman-clk-mux for the Frame Manager clock.
- #clock-cells: From common clock binding. The number of cells in a
- clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
- clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
+ clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0 and
+ fsl,fman-clk-mux clocks or 1 for fsl,qoriq-core-pll-[1,2].0.
For fsl,qoriq-core-pll-1.0 clocks, the single
clock-specifier cell may take the following values:
* 0 - equal to the PLL frequency
@@ -145,6 +146,18 @@ Example for clock block and clock provider:
clocks = sysclk;
clock-output-names = platform-pll, platform-pll-
div2;
};
+
+ fm0clk: fm0-clk-mux {
+ #clock-cells = 0;
+ reg = 0x10 4
+ compatible = fsl,fman-clk-mux;
+ clocks = pll0 0, pll0 1, pll0 2, pll0 3,
+ platform_pll 0, pll1 1, pll1 2;
+ clock-names = pll0, pll0-div2, pll0-div3,
+ pll0-div4, platform-pll, pll1-div2,
+ pll1-div3;
+ clock-output-names = fm0-clk;
+ };
};
};
I don't see this register in the manuals for older DPAA chips, such as
p4080 or p3041. Is it present but undocumented? Should I be looking
somewhere other than Clocking Memory Map?
It's available only in part of the new chips (T4, T2, B4).
In T1024/T1040 there's only one option for FMan clock so this register is not
available.
So it's part of the 2.0 chassis? I'd stick a 2.0 in there, then. Who
knows what we may see in the future.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Thu, 2015-04-09 at 21:52 +, Lijun Pan wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? I don't like that the user has to manually run merge_config.sh. How does a user even know that it's an option? It also breaks scripts that auto build the kernel, which expect to be able to do: $ make foo_defconfig $ make Scripts like mine for example :) http://kisskb.ellerman.id.au/kisskb/head/8734/ What I'd be happy with is something that does merge_config under the covers. So a user still runs 'make fsl_plat_foo_defconfig', but under the covers it does a merge config. kvmconfig and tinyconfig are implemented that way already, so with a bit more work hopefully you can do that for arch configs also. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
Dear Scott.
On Apr 16 2015, Scott Wood wrote:
On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
Is there any proper way for me to discover what device name the kernel
uses? I have tried the following command lines without success:
1 -
mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
2 -
mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
3 -
mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
Look in sysfs.
The output that I get from sysfs is:
# ls -l /sys/block/mtdblock0
lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -
../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0
# cat /sys/devices/platform/physmap-flash.0/uevent
DRIVER=physmap-flash
MODALIAS=platform:physmap-flash
# cat /sys/devices/platform/physmap-flash.0/driver_override
(null)
So, it is saying that the driver is physmap-flash, right? I will compile
now a (new) kernel 4.0 with the parameter passed as my 2nd attempt above
(just to make sure that I have not messed up before). Just to confirm, this
should (in theory) work, right?
Anything else that I can provide? Again, just ask me and I will do my best
to collect the needed information.
Thanks once again,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Thu, 2015-04-16 at 21:01 -0300, Rogério Brito wrote: Dear Scott. On Apr 16 2015, Scott Wood wrote: On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote: Is there any proper way for me to discover what device name the kernel uses? I have tried the following command lines without success: 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) Look in sysfs. The output that I get from sysfs is: # ls -l /sys/block/mtdblock0 lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 - ../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0 # cat /sys/devices/platform/physmap-flash.0/uevent DRIVER=physmap-flash MODALIAS=platform:physmap-flash # cat /sys/devices/platform/physmap-flash.0/driver_override (null) So, it is saying that the driver is physmap-flash, right? It looks like the device name is physmap-flash.0. You're partitioning the device, not the driver. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
Hi, Scott and others.
On Apr 09 2015, Rogério Brito wrote:
On Apr 09 2015, Scott Wood wrote:
On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
What is myflash? You need to match the device name that the kernel
uses.
From the documentation that I read, it *seemed* to be an arbitrary name and,
to be screamingly different from anything else, I just picked myflash.
So, in my case (see dmesg snippet below), I would use physmap-flash.0,
right? Or would that be physmap-flash? Or something else entirely?
Is there any proper way for me to discover what device name the kernel
uses? I have tried the following command lines without success:
1 -
mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
2 -
mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
3 -
mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
The first one is the one from my previous post. The next ones had the name
of the device changed *and* the 4MB at the start removed.
Do you want my config file? Do you want any dmesg output? Anything else
that I can provide?
What is allflash? If the flash is only 4 MiB and you're trying to
make the first partition refer to the entire flash, it won't work.
It'll see that 4 MiB partition and ignore the rest as being beyond the
end of the device.
OK, I was just trying to mimic the layout that you can see here:
http://buffalo.nas-central.org/wiki/Flash_ROM#Checking_the_layout_.28with_kernel_2.6.x.29
I have removed that parameter from the command line.
Thanks a lot for your help,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote: Hi, Scott and others. On Apr 09 2015, Rogério Brito wrote: On Apr 09 2015, Scott Wood wrote: On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote: mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) What is myflash? You need to match the device name that the kernel uses. From the documentation that I read, it *seemed* to be an arbitrary name and, to be screamingly different from anything else, I just picked myflash. So, in my case (see dmesg snippet below), I would use physmap-flash.0, right? Or would that be physmap-flash? Or something else entirely? Is there any proper way for me to discover what device name the kernel uses? I have tried the following command lines without success: 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf) Look in sysfs. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, 2015-04-17 at 10:54 +1000, Michael Ellerman wrote: On Thu, 2015-04-09 at 21:52 +, Lijun Pan wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? I don't like that the user has to manually run merge_config.sh. How does a user even know that it's an option? It also breaks scripts that auto build the kernel, which expect to be able to do: $ make foo_defconfig $ make Scripts like mine for example :) http://kisskb.ellerman.id.au/kisskb/head/8734/ What I'd be happy with is something that does merge_config under the covers. So a user still runs 'make fsl_plat_foo_defconfig', but under the covers it does a merge config. kvmconfig and tinyconfig are implemented that way already, so with a bit more work hopefully you can do that for arch configs also. kvmconfig and tinyconfig are still separate user-visible steps to be applied after running a base defconfig. For breaking a platform defconfig into components, we could do something like this in arch/powerpc/Makefile: # Can't call mergeconfig directly as it isn't defined at this point define domerge @$(MAKE) -f $(srctree)/scripts/kconfig/Makefile $(1).config endef corenet64_smp_defconfig: corenet64_basic_defconfig $(call domerge,smp) $(call domerge,altivec) $(call domerge,corenet_drivers) $(call domerge,embedded_misc) # filesystems etc And this in scripts/kconfig/Makefile: %.config: $(call mergeconfig,$*) One issue with this is that we'd lose the ability to use savedefconfig (at least without manual manipulation of the results) to maintain the defconfigs/fragments. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Thu, 2015-04-16 at 00:44 -0400, Bob Cochran wrote: As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). We do use Yocto for our SDK, but there's always going to be a need to be able to build kernels outside of Yocto. The kernel should be self-contained regarding its own configuration. merge_config.sh isn't rolling our own solution. It's a standard kernel tool. x86 already has a couple config fragments defined. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
