[PATCH 2/2] powerpc: Remove map_/unmap_single() from dma_mapping_ops
Now that all of the remaining dma_mapping_ops have had their map_/unmap_single
functions updated to become map/unmap_page functions, there is no need to have
the map_/unmap_single function pointers in the dma_mapping_ops.
So, take this opportunity to remove them and also remove the code that does
the checking for which set of functions to use.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
---
This is just a cleanup so can wait for 2.6.29
arch/powerpc/include/asm/dma-mapping.h | 36 -
1 file changed, 5 insertions(+), 31 deletions(-)
Index: upstream/arch/powerpc/include/asm/dma-mapping.h
===
--- upstream.orig/arch/powerpc/include/asm/dma-mapping.h
+++ upstream/arch/powerpc/include/asm/dma-mapping.h
@@ -60,12 +60,6 @@ struct dma_mapping_ops {
dma_addr_t *dma_handle, gfp_t flag);
void(*free_coherent)(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle);
- dma_addr_t (*map_single)(struct device *dev, void *ptr,
- size_t size, enum dma_data_direction direction,
- struct dma_attrs *attrs);
- void(*unmap_single)(struct device *dev, dma_addr_t dma_addr,
- size_t size, enum dma_data_direction direction,
- struct dma_attrs *attrs);
int (*map_sg)(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction,
struct dma_attrs *attrs);
@@ -149,10 +143,9 @@ static inline int dma_set_mask(struct de
}
/*
- * TODO: map_/unmap_single will ideally go away, to be completely
- * replaced by map/unmap_page. Until then, we allow dma_ops to have
- * one or the other, or both by checking to see if the specific
- * function requested exists; and if not, falling back on the other set.
+ * map_/unmap_single actually call through to map/unmap_page now that all the
+ * dma_mapping_ops have been converted over. We just have to get the page and
+ * offset to pass through to map_page
*/
static inline dma_addr_t dma_map_single_attrs(struct device *dev,
void *cpu_addr,
@@ -164,10 +157,6 @@ static inline dma_addr_t dma_map_single_
BUG_ON(!dma_ops);
- if (dma_ops->map_single)
- return dma_ops->map_single(dev, cpu_addr, size, direction,
- attrs);
-
return dma_ops->map_page(dev, virt_to_page(cpu_addr),
(unsigned long)cpu_addr % PAGE_SIZE, size,
direction, attrs);
@@ -183,11 +172,6 @@ static inline void dma_unmap_single_attr
BUG_ON(!dma_ops);
- if (dma_ops->unmap_single) {
- dma_ops->unmap_single(dev, dma_addr, size, direction, attrs);
- return;
- }
-
dma_ops->unmap_page(dev, dma_addr, size, direction, attrs);
}
@@ -201,12 +185,7 @@ static inline dma_addr_t dma_map_page_at
BUG_ON(!dma_ops);
- if (dma_ops->map_page)
- return dma_ops->map_page(dev, page, offset, size, direction,
-attrs);
-
- return dma_ops->map_single(dev, page_address(page) + offset, size,
- direction, attrs);
+ return dma_ops->map_page(dev, page, offset, size, direction, attrs);
}
static inline void dma_unmap_page_attrs(struct device *dev,
@@ -219,12 +198,7 @@ static inline void dma_unmap_page_attrs(
BUG_ON(!dma_ops);
- if (dma_ops->unmap_page) {
- dma_ops->unmap_page(dev, dma_address, size, direction, attrs);
- return;
- }
-
- dma_ops->unmap_single(dev, dma_address, size, direction, attrs);
+ dma_ops->unmap_page(dev, dma_address, size, direction, attrs);
}
static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Update remaining dma_mapping_ops to use map/unmap_page
After the merge of the 32 and 64bit DMA code, dma_direct_ops lost their
map/unmap_single() functions but gained map/unmap_page(). This caused a
problem for Cell because Cell's dma_iommu_fixed_ops called the dma_direct_ops
if the fixed linear mapping was to be used or the iommu ops if the dynamic
window was to be used. So in order to fix this problem we need to update the
64bit DMA code to use map/unmap_page.
First, we update the generic IOMMU code so that iommu_map_single() becomes
iommu_map_page() and iommu_unmap_single() becomes iommu_unmap_page(). Then we
propagate these changes up through all the callers of these two functions and
in the process update all the dma_mapping_ops so that they have map/unmap_page
rahter than map/unmap_single. We can do this because on 64bit there is no
HIGHMEM memory so map/unmap_page ends up performing exactly the same function
as map/unmap_single, just taking different arguments.
This has no effect on drivers because the dma_map_single_attrs() just ends up
calling the map_page() function of the appropriate dma_mapping_ops and
similarly the dma_unmap_single_attrs() calls unmap_page().
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
---
Is it possible to get this in for 2.6.28 because currently Cell blades oops
on boot because they're calling dma_direct_ops.map_single (which is NULL)?
arch/powerpc/include/asm/iommu.h| 15 ++--
arch/powerpc/kernel/dma-iommu.c | 34 +
arch/powerpc/kernel/ibmebus.c | 29 -
arch/powerpc/kernel/iommu.c | 22 ++-
arch/powerpc/kernel/vio.c | 25 +++--
arch/powerpc/platforms/cell/iommu.c | 37 +++-
arch/powerpc/platforms/iseries/iommu.c |7 +++---
arch/powerpc/platforms/ps3/system-bus.c | 36 ---
8 files changed, 105 insertions(+), 100 deletions(-)
Index: upstream/arch/powerpc/include/asm/iommu.h
===
--- upstream.orig/arch/powerpc/include/asm/iommu.h
+++ upstream/arch/powerpc/include/asm/iommu.h
@@ -92,13 +92,14 @@ extern void *iommu_alloc_coherent(struct
unsigned long mask, gfp_t flag, int node);
extern void iommu_free_coherent(struct iommu_table *tbl, size_t size,
void *vaddr, dma_addr_t dma_handle);
-extern dma_addr_t iommu_map_single(struct device *dev, struct iommu_table *tbl,
- void *vaddr, size_t size, unsigned long mask,
- enum dma_data_direction direction,
- struct dma_attrs *attrs);
-extern void iommu_unmap_single(struct iommu_table *tbl, dma_addr_t dma_handle,
- size_t size, enum dma_data_direction direction,
- struct dma_attrs *attrs);
+extern dma_addr_t iommu_map_page(struct device *dev, struct iommu_table *tbl,
+struct page *page, unsigned long offset,
+size_t size, unsigned long mask,
+enum dma_data_direction direction,
+struct dma_attrs *attrs);
+extern void iommu_unmap_page(struct iommu_table *tbl, dma_addr_t dma_handle,
+size_t size, enum dma_data_direction direction,
+struct dma_attrs *attrs);
extern void iommu_init_early_pSeries(void);
extern void iommu_init_early_iSeries(void);
Index: upstream/arch/powerpc/kernel/dma-iommu.c
===
--- upstream.orig/arch/powerpc/kernel/dma-iommu.c
+++ upstream/arch/powerpc/kernel/dma-iommu.c
@@ -30,28 +30,26 @@ static void dma_iommu_free_coherent(stru
}
/* Creates TCEs for a user provided buffer. The user buffer must be
- * contiguous real kernel storage (not vmalloc). The address of the buffer
- * passed here is the kernel (virtual) address of the buffer. The buffer
- * need not be page aligned, the dma_addr_t returned will point to the same
- * byte within the page as vaddr.
+ * contiguous real kernel storage (not vmalloc). The address passed here
+ * comprises a page address and offset into that page. The dma_addr_t
+ * returned will point to the same byte within the page as was passed in.
*/
-static dma_addr_t dma_iommu_map_single(struct device *dev, void *vaddr,
- size_t size,
- enum dma_data_direction direction,
- struct dma_attrs *attrs)
+static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
+unsigned long offset, size_t size,
+enum dma_data_direction direction,
+struct dma_attrs *attrs)
{
Re: [PATCH 0/10] powerpc/pci: Fix PCI Hotplug
On Tue, 2008-10-28 at 16:48 +1100, Benjamin Herrenschmidt wrote: > This series of patches is aimed at fixing all sort of issues > with the PCI hotplug support on pSeries. The meant is in the > second to last patch, but it relies on a whole bunch of small > changes to separate the bus fixup operation in two that are > needed to fix the root of most problems. > > Please review/test asap as I would like that in 2.6.28 despite > being a bit late, as without these, PCI hotplug on pseries pretty > much doesn't work. It should also make it easier in the future to > implement hotplug support on other platforms. Specifically, Kumar and Josh, can you give a couple of spins of kernels with those patches on your respective platforms to make sure I haven't broken something ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 10/10] powerpc/pci: Cosmetic cleanups of pci-common.c
This does a few costmetic cleanups, moving a couple of things
around but without actually changing what the code does.
(There is a minor change in ordering of operations in
pcibios_setup_bus_devices but it should have no impact).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c | 77 ++-
1 file changed, 36 insertions(+), 41 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
16:39:53.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 16:39:54.0
+1100
@@ -202,25 +202,6 @@ char __devinit *pcibios_setup(char *str)
return str;
}
-static void __devinit pcibios_setup_new_device(struct pci_dev *dev)
-{
- struct dev_archdata *sd = &dev->dev.archdata;
-
- sd->of_node = pci_device_to_OF_node(dev);
-
- pr_debug("PCI: device %s OF node: %s\n", pci_name(dev),
-sd->of_node ? sd->of_node->full_name : "");
-
- sd->dma_ops = pci_dma_ops;
-#ifdef CONFIG_PPC32
- sd->dma_data = (void *)PCI_DRAM_OFFSET;
-#endif
- set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
-
- if (ppc_md.pci_dma_dev_setup)
- ppc_md.pci_dma_dev_setup(dev);
-}
-
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -1076,33 +1057,14 @@ static void __devinit pcibios_fixup_brid
}
}
-void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- pr_debug("PCI: Fixup bus %d (%s)\n",
-bus->number, bus->self ? pci_name(bus->self) : "PHB");
-
- /* Setup DMA for all PCI devices on that bus */
- list_for_each_entry(dev, &bus->devices, bus_list)
- pcibios_setup_new_device(dev);
-
- /* Read default IRQs and fixup if necessary */
- list_for_each_entry(dev, &bus->devices, bus_list) {
- pci_read_irq_line(dev);
- if (ppc_md.pci_irq_fixup)
- ppc_md.pci_irq_fixup(dev);
- }
-}
-
void __devinit pcibios_setup_bus_self(struct pci_bus *bus)
{
- /* Fix up the bus resources */
+ /* Fix up the bus resources for P2P bridges */
if (bus->self != NULL)
pcibios_fixup_bridge(bus);
/* Platform specific bus fixups. This is currently only used
-* by fsl_pci and I'm hoping getting rid of it at some point
+* by fsl_pci and I'm hoping to get rid of it at some point
*/
if (ppc_md.pcibios_fixup_bus)
ppc_md.pcibios_fixup_bus(bus);
@@ -1112,10 +1074,43 @@ void __devinit pcibios_setup_bus_self(st
ppc_md.pci_dma_bus_setup(bus);
}
+void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ pr_debug("PCI: Fixup bus devices %d (%s)\n",
+bus->number, bus->self ? pci_name(bus->self) : "PHB");
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ struct dev_archdata *sd = &dev->dev.archdata;
+
+ /* Setup OF node pointer in archdata */
+ sd->of_node = pci_device_to_OF_node(dev);
+
+ /* Fixup NUMA node as it may not be setup yet by the generic
+* code and is needed by the DMA init
+*/
+ set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
+
+ /* Hook up default DMA ops */
+ sd->dma_ops = pci_dma_ops;
+ sd->dma_data = (void *)PCI_DRAM_OFFSET;
+
+ /* Additional platform DMA/iommu setup */
+ if (ppc_md.pci_dma_dev_setup)
+ ppc_md.pci_dma_dev_setup(dev);
+
+ /* Read default IRQs and fixup if necessary */
+ pci_read_irq_line(dev);
+ if (ppc_md.pci_irq_fixup)
+ ppc_md.pci_irq_fixup(dev);
+ }
+}
+
void __devinit pcibios_fixup_bus(struct pci_bus *bus)
{
/* When called from the generic PCI probe, read PCI<->PCI bridge
-* bases. This isn't called when generating the PCI tree from
+* bases. This is -not- called when generating the PCI tree from
* the OF device-tree.
*/
if (bus->self != NULL)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/10] powerpc/pci: Fix various pseries PCI Hotplug issues
The pseries PCI Hotplug code has a number of issues, ranging from
incorrect resource setup to crashes, depending on what is added,
when, whether it contains a bridge, etc etc
This patch fixes a whole bunch of these, while actually simplifying
the code a bit, using more generic code in the process and factoring
out common code between adding of a PHB, a slot or a device.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/pci-bridge.h |3
arch/powerpc/include/asm/pci.h |7 -
arch/powerpc/kernel/pci-common.c | 41 ++-
arch/powerpc/kernel/rtas_pci.c | 48
arch/powerpc/platforms/pseries/pci_dlpar.c | 164 ++---
drivers/pci/hotplug/rpadlpar_core.c| 69 +---
6 files changed, 150 insertions(+), 182 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pci-bridge.h 2008-10-28
14:56:52.0 +1100
+++ linux-work/arch/powerpc/include/asm/pci-bridge.h2008-10-28
14:58:54.0 +1100
@@ -241,9 +241,6 @@ extern void pcibios_remove_pci_devices(s
/** Discover new pci devices under this bus, and add them */
extern void pcibios_add_pci_devices(struct pci_bus *bus);
-extern void pcibios_fixup_new_pci_devices(struct pci_bus *bus);
-
-extern int pcibios_remove_root_bus(struct pci_controller *phb);
static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
{
Index: linux-work/arch/powerpc/include/asm/pci.h
===
--- linux-work.orig/arch/powerpc/include/asm/pci.h 2008-10-28
14:56:52.0 +1100
+++ linux-work/arch/powerpc/include/asm/pci.h 2008-10-28 14:58:54.0
+1100
@@ -204,15 +204,12 @@ static inline struct resource *pcibios_s
return root;
}
-extern void pcibios_setup_new_device(struct pci_dev *dev);
-
-extern void pcibios_claim_one_bus(struct pci_bus *b);
-
-extern void pcibios_allocate_bus_resources(struct pci_bus *bus);
+extern void pcibios_finish_adding_to_bus(struct pci_bus *bus);
extern void pcibios_resource_survey(void);
extern struct pci_controller *init_phb_dynamic(struct device_node *dn);
+extern int remove_phb_dynamic(struct pci_controller *phb);
extern struct pci_dev *of_create_pci_dev(struct device_node *node,
struct pci_bus *bus, int devfn);
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
14:58:48.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 14:59:16.0
+1100
@@ -202,7 +202,7 @@ char __devinit *pcibios_setup(char *str)
return str;
}
-void __devinit pcibios_setup_new_device(struct pci_dev *dev)
+static void __devinit pcibios_setup_new_device(struct pci_dev *dev)
{
struct dev_archdata *sd = &dev->dev.archdata;
@@ -220,7 +220,6 @@ void __devinit pcibios_setup_new_device(
if (ppc_md.pci_dma_dev_setup)
ppc_md.pci_dma_dev_setup(dev);
}
-EXPORT_SYMBOL(pcibios_setup_new_device);
/*
* Reads the interrupt pin to determine if interrupt is use by card.
@@ -1399,9 +1398,10 @@ void __init pcibios_resource_survey(void
#ifdef CONFIG_HOTPLUG
-/* This is used by the pSeries hotplug driver to allocate resource
+/* This is used by the PCI hotplug driver to allocate resource
* of newly plugged busses. We can try to consolidate with the
- * rest of the code later, for now, keep it as-is
+ * rest of the code later, for now, keep it as-is as our main
+ * resource allocation function doesn't deal with sub-trees yet.
*/
static void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
{
@@ -1416,6 +1416,14 @@ static void __devinit pcibios_claim_one_
if (r->parent || !r->start || !r->flags)
continue;
+
+ pr_debug("PCI: Claiming %s: "
+"Resource %d: %016llx..%016llx [%x]\n",
+pci_name(dev), i,
+(unsigned long long)r->start,
+(unsigned long long)r->end,
+(unsigned int)r->flags);
+
pci_claim_resource(dev, i);
}
}
@@ -1423,6 +1431,31 @@ static void __devinit pcibios_claim_one_
list_for_each_entry(child_bus, &bus->children, node)
pcibios_claim_one_bus(child_bus);
}
+
+
+/* pcibios_finish_adding_to_bus
+ *
+ * This is to be called by the hotplug code after devices have been
+ * added to a bus, this include calling it for a PHB that is just
+ * being added
+ */
+void pcibios_finish_adding_to_bus(struct pci_bus *bus)
+{
+ pr_debug("PCI: Finishing adding to hotplug bus %04x:%02x\n",
+pci_domain_nr(bus), bus->number);
+
+ /* Allocate bus a
[PATCH 8/10] powerpc/pci: Fix unmapping of IO space on 64-bit
A typo/thinko made us pass the wrong argument to __flush_hash_table_range when unplugging bridges, thus not flushing all the translations for the IO space on unplug. This causes the hypervisor to refuse unplugging slots. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/kernel/pci_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/kernel/pci_64.c2008-10-28 16:33:48.0 +1100 +++ linux-work/arch/powerpc/kernel/pci_64.c 2008-10-28 16:38:45.0 +1100 @@ -426,7 +426,7 @@ int pcibios_unmap_io_space(struct pci_bu pci_name(bus->self)); __flush_hash_table_range(&init_mm, res->start + _IO_BASE, -res->end - res->start + 1); +res->end + _IO_BASE + 1); return 0; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/10] powerpc/pci: Make pcibios_allocate_bus_resources more robust
To properly fix PCI hotplug, it's useful to be able to make
the fixup passes on all devices whether they were just hot
plugged or already there.
However, pcibios_allocate_bus_resources() wouldn't cope well
with being called twice for a given bus. This patch makes it
ignore resources that have already been allocated, along with
adding a bit of debug output.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
14:04:45.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 14:04:57.0
+1100
@@ -1245,9 +1245,12 @@ static void pcibios_allocate_bus_resourc
int i;
struct resource *res, *pr;
+ pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
+pci_domain_nr(bus), bus->number);
+
for (i = 0; i < PCI_BUS_NUM_RESOURCES; ++i) {
if ((res = bus->resource[i]) == NULL || !res->flags
- || res->start > res->end)
+ || res->start > res->end || res->parent)
continue;
if (bus->parent == NULL)
pr = (res->flags & IORESOURCE_IO) ?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/10] powerpc/eeh: Make EEH device add/remove more robust
To properly fix PCI hotplug, it's useful to be able to make
the fixup passes on all devices whether they were just hot
plugged or already there.
The EEH code however used to not be very friendly with calling
eeh_add_device_late() multiple time, and not very rebust in
the way it generally tests whether a device is in the expected
state vs. the EEH code.
This improves it, along with cleaning up a couple of debug printk's
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/eeh.h |9 +++
arch/powerpc/platforms/pseries/eeh.c | 44 +++
2 files changed, 29 insertions(+), 24 deletions(-)
--- linux-work.orig/arch/powerpc/platforms/pseries/eeh.c2008-10-23
14:41:05.0 +1100
+++ linux-work/arch/powerpc/platforms/pseries/eeh.c 2008-10-28
14:03:26.0 +1100
@@ -21,6 +21,8 @@
* Please address comments and feedback to Linas Vepstas <[EMAIL PROTECTED]>
*/
+#undef DEBUG
+
#include
#include
#include
@@ -488,10 +490,8 @@ int eeh_dn_check_failure(struct device_n
if (!(pdn->eeh_mode & EEH_MODE_SUPPORTED) ||
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
-#ifdef DEBUG
- printk ("EEH:ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
-#endif
+ pr_debug("EEH: Ignored check (%x) for %s %s\n",
+pdn->eeh_mode, pci_name (dev), dn->full_name);
return 0;
}
@@ -1014,10 +1014,9 @@ static void *early_enable_eeh(struct dev
eeh_subsystem_enabled = 1;
pdn->eeh_mode |= EEH_MODE_SUPPORTED;
-#ifdef DEBUG
- printk(KERN_DEBUG "EEH: %s: eeh enabled, config=%x
pe_config=%x\n",
- dn->full_name, pdn->eeh_config_addr,
pdn->eeh_pe_config_addr);
-#endif
+ pr_debug("EEH: %s: eeh enabled, config=%x
pe_config=%x\n",
+dn->full_name, pdn->eeh_config_addr,
+pdn->eeh_pe_config_addr);
} else {
/* This device doesn't support EEH, but it may have an
@@ -1161,13 +1160,17 @@ static void eeh_add_device_late(struct p
if (!dev || !eeh_subsystem_enabled)
return;
-#ifdef DEBUG
- printk(KERN_DEBUG "EEH: adding device %s\n", pci_name(dev));
-#endif
+ pr_debug("EEH: Adding device %s\n", pci_name(dev));
- pci_dev_get (dev);
dn = pci_device_to_OF_node(dev);
pdn = PCI_DN(dn);
+ if (pdn->pcidev == dev) {
+ pr_debug("EEH: Already referenced !\n");
+ return;
+ }
+ WARN_ON(pdn->pcidev);
+
+ pci_dev_get (dev);
pdn->pcidev = dev;
pci_addr_cache_insert_device(dev);
@@ -1206,17 +1209,18 @@ static void eeh_remove_device(struct pci
return;
/* Unregister the device with the EEH/PCI address search system */
-#ifdef DEBUG
- printk(KERN_DEBUG "EEH: remove device %s\n", pci_name(dev));
-#endif
- pci_addr_cache_remove_device(dev);
- eeh_sysfs_remove_device(dev);
+ pr_debug("EEH: Removing device %s\n", pci_name(dev));
dn = pci_device_to_OF_node(dev);
- if (PCI_DN(dn)->pcidev) {
- PCI_DN(dn)->pcidev = NULL;
- pci_dev_put (dev);
+ if (PCI_DN(dn)->pcidev == NULL) {
+ pr_debug("EEH: Not referenced !\n");
+ return;
}
+ PCI_DN(dn)->pcidev = NULL;
+ pci_dev_put (dev);
+
+ pci_addr_cache_remove_device(dev);
+ eeh_sysfs_remove_device(dev);
}
void eeh_remove_bus_device(struct pci_dev *dev)
Index: linux-work/arch/powerpc/include/asm/eeh.h
===
--- linux-work.orig/arch/powerpc/include/asm/eeh.h 2008-10-28
14:07:47.0 +1100
+++ linux-work/arch/powerpc/include/asm/eeh.h 2008-10-28 14:08:44.0
+1100
@@ -17,8 +17,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#ifndef _PPC64_EEH_H
-#define _PPC64_EEH_H
+#ifndef _POWERPC_EEH_H
+#define _POWERPC_EEH_H
#ifdef __KERNEL__
#include
@@ -110,6 +110,7 @@ static inline void eeh_remove_bus_device
#define EEH_IO_ERROR_VALUE(size) (-1UL)
#endif /* CONFIG_EEH */
+#ifdef CONFIG_PPC64
/*
* MMIO read/write operations with EEH support.
*/
@@ -206,6 +207,6 @@ static inline void eeh_readsl(const vola
if (EEH_POSSIBLE_ERROR((*(((u32*)buf)+nl-1)), u32))
eeh_check_failure(addr, *(u32*)buf);
}
-
+#endif /* CONFIG_PPC64 */
#endif /* __KERNEL__ */
-#endif /* _PPC64_EEH_H */
+#endif /* _POWERPC_EEH_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/10] powerpc/pci: Split pcibios_fixup_bus() into bus setup and devices setup
Currently, or PCI code uses the pcibios_fixup_bus() callback, which is
called by the generic code when probing PCI busses, for two different
thnings.
One is to setup things related to the bus itself, such as
reading bridge resources for P2P bridges, fixing them up, or setting
up the iommu's associated with bridges on some platfornms.
The other does some setup for each individual device under that
bridge, mostly setting up DMA mappings and interrupts.
The problem is that this approach doesn't work well with PCI hotplug
when an existing bus is re-probed for new children. This patch allows
this to be fixed by splitting it into two routines:
pcibios_setup_bus_self() is now called to setup the bus itself
pcibios_setup_bus_devices() is now called to setup devices
pcibios_fixup_bus() is then modified to call these two after reading the
bridge bases, and the OF based PCI probe is modified to avoid calling
into the first one when rescanning an existing bridge.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/pci.h |5 +--
arch/powerpc/kernel/pci-common.c | 59 +++
arch/powerpc/kernel/pci_64.c | 27 ++---
3 files changed, 55 insertions(+), 36 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
12:06:00.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 14:58:41.0
+1100
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
static DEFINE_SPINLOCK(hose_spinlock);
@@ -1076,31 +1077,17 @@ static void __devinit pcibios_fixup_brid
}
}
-static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
+void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
{
struct pci_dev *dev;
pr_debug("PCI: Fixup bus %d (%s)\n",
bus->number, bus->self ? pci_name(bus->self) : "PHB");
- /* Fixup PCI<->PCI bridges. Host bridges are handled separately, for
-* now differently between 32 and 64 bits.
-*/
- if (bus->self != NULL)
- pcibios_fixup_bridge(bus);
-
- /* Setup bus DMA mappings */
- if (ppc_md.pci_dma_bus_setup)
- ppc_md.pci_dma_bus_setup(bus);
-
/* Setup DMA for all PCI devices on that bus */
list_for_each_entry(dev, &bus->devices, bus_list)
pcibios_setup_new_device(dev);
- /* Platform specific bus fixups */
- if (ppc_md.pcibios_fixup_bus)
- ppc_md.pcibios_fixup_bus(bus);
-
/* Read default IRQs and fixup if necessary */
list_for_each_entry(dev, &bus->devices, bus_list) {
pci_read_irq_line(dev);
@@ -1109,25 +1096,39 @@ static void __devinit __pcibios_fixup_bu
}
}
+void __devinit pcibios_setup_bus_self(struct pci_bus *bus)
+{
+ /* Fix up the bus resources */
+ if (bus->self != NULL)
+ pcibios_fixup_bridge(bus);
+
+ /* Platform specific bus fixups. This is currently only used
+* by fsl_pci and I'm hoping getting rid of it at some point
+*/
+ if (ppc_md.pcibios_fixup_bus)
+ ppc_md.pcibios_fixup_bus(bus);
+
+ /* Setup bus DMA mappings */
+ if (ppc_md.pci_dma_bus_setup)
+ ppc_md.pci_dma_bus_setup(bus);
+}
+
void __devinit pcibios_fixup_bus(struct pci_bus *bus)
{
/* When called from the generic PCI probe, read PCI<->PCI bridge
-* bases before proceeding
+* bases. This isn't called when generating the PCI tree from
+* the OF device-tree.
*/
if (bus->self != NULL)
pci_read_bridge_bases(bus);
- __pcibios_fixup_bus(bus);
-}
-EXPORT_SYMBOL(pcibios_fixup_bus);
-/* When building a bus from the OF tree rather than probing, we need a
- * slightly different version of the fixup which doesn't read the
- * bridge bases using config space accesses
- */
-void __devinit pcibios_fixup_of_probed_bus(struct pci_bus *bus)
-{
- __pcibios_fixup_bus(bus);
+ /* Now fixup the bus bus */
+ pcibios_setup_bus_self(bus);
+
+ /* Now fixup devices on that bus */
+ pcibios_setup_bus_devices(bus);
}
+EXPORT_SYMBOL(pcibios_fixup_bus);
static int skip_isa_ioresource_align(struct pci_dev *dev)
{
@@ -1238,7 +1239,7 @@ static int __init reparent_resources(str
* as well.
*/
-void pcibios_allocate_bus_resources(struct pci_bus *bus)
+static void pcibios_allocate_bus_resources(struct pci_bus *bus)
{
struct pci_bus *b;
int i;
@@ -1394,11 +1395,12 @@ void __init pcibios_resource_survey(void
}
#ifdef CONFIG_HOTPLUG
+
/* This is used by the pSeries hotplug driver to allocate resource
* of newly plugged busses. We can try to consolidate with the
* rest of the code later, for now, keep it as-is
*/
-void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
+static void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
{
[PATCH 4/10] powerpc/pci: Remove pcibios_do_bus_setup()
The function pcibios_do_bus_setup() was used by pcibios_fixup_bus()
to perform setup that is different between the 32-bit and 64-bit
code. This difference no longer exist, thus the function is removed
and the setup now done directly from pci-common.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/pci.h |1 -
arch/powerpc/kernel/pci-common.c | 16 +++-
arch/powerpc/kernel/pci_32.c | 11 ---
arch/powerpc/kernel/pci_64.c | 11 ---
4 files changed, 11 insertions(+), 28 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pci.h 2008-10-28
11:56:18.0 +1100
+++ linux-work/arch/powerpc/include/asm/pci.h 2008-10-28 11:56:46.0
+1100
@@ -235,7 +235,6 @@ extern void pci_resource_to_user(const s
const struct resource *rsrc,
resource_size_t *start, resource_size_t *end);
-extern void pcibios_do_bus_setup(struct pci_bus *bus);
extern void pcibios_fixup_of_probed_bus(struct pci_bus *bus);
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
11:56:45.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 11:56:46.0
+1100
@@ -1078,18 +1078,24 @@ static void __devinit pcibios_fixup_brid
static void __devinit __pcibios_fixup_bus(struct pci_bus *bus)
{
- struct pci_dev *dev = bus->self;
+ struct pci_dev *dev;
- pr_debug("PCI: Fixup bus %d (%s)\n", bus->number, dev ? pci_name(dev) :
"PHB");
+ pr_debug("PCI: Fixup bus %d (%s)\n",
+bus->number, bus->self ? pci_name(bus->self) : "PHB");
/* Fixup PCI<->PCI bridges. Host bridges are handled separately, for
* now differently between 32 and 64 bits.
*/
- if (dev != NULL)
+ if (bus->self != NULL)
pcibios_fixup_bridge(bus);
- /* Additional setup that is different between 32 and 64 bits for now */
- pcibios_do_bus_setup(bus);
+ /* Setup bus DMA mappings */
+ if (ppc_md.pci_dma_bus_setup)
+ ppc_md.pci_dma_bus_setup(bus);
+
+ /* Setup DMA for all PCI devices on that bus */
+ list_for_each_entry(dev, &bus->devices, bus_list)
+ pcibios_setup_new_device(dev);
/* Platform specific bus fixups */
if (ppc_md.pcibios_fixup_bus)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2008-10-28
11:56:45.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2008-10-28 11:56:46.0
+1100
@@ -446,17 +446,6 @@ static int __init pcibios_init(void)
subsys_initcall(pcibios_init);
-void __devinit pcibios_do_bus_setup(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- if (ppc_md.pci_dma_bus_setup)
- ppc_md.pci_dma_bus_setup(bus);
-
- list_for_each_entry(dev, &bus->devices, bus_list)
- pcibios_setup_new_device(dev);
-}
-
/* the next one is stolen from the alpha port... */
void __init
pcibios_update_irq(struct pci_dev *dev, int irq)
Index: linux-work/arch/powerpc/kernel/pci_64.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_64.c2008-10-28
11:56:45.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_64.c 2008-10-28 11:56:46.0
+1100
@@ -502,17 +502,6 @@ int __devinit pcibios_map_io_space(struc
}
EXPORT_SYMBOL_GPL(pcibios_map_io_space);
-void __devinit pcibios_do_bus_setup(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- if (ppc_md.pci_dma_bus_setup)
- ppc_md.pci_dma_bus_setup(bus);
-
- list_for_each_entry(dev, &bus->devices, bus_list)
- pcibios_setup_new_device(dev);
-}
-
unsigned long pci_address_to_pio(phys_addr_t address)
{
struct pci_controller *hose, *tmp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/10] powerpc/pci: Use commont PHB resource hookup
The 32-bit and 64-bit powerpc PCI code used to setup the resource
pointers of the root bus of a given PHB in completely different
places.
This unifies this in large part, but making 32-bit use a routine very
similar to what 64-bit does when initially scanning the PCI busses.
The actual setup of the PHB resources itself is then moved to a
common function in pci-common.c
This should cause no functional change on 64-bit. On 32-bit, the effect
is that the PHB resources are going to be setup a bit earlier, instead
of being setup from pcibios_fixup_bus().
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
This is a pre-requisite to be able to remove pcibios_do_bus_setup()
in order to make the pcibios_fixup_bus() codepath common.
arch/powerpc/include/asm/pci-bridge.h |1
arch/powerpc/kernel/pci-common.c | 58 +
arch/powerpc/kernel/pci_32.c | 78 ++
arch/powerpc/kernel/pci_64.c | 19 +---
4 files changed, 96 insertions(+), 60 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pci-bridge.h 2008-10-28
15:35:56.0 +1100
+++ linux-work/arch/powerpc/include/asm/pci-bridge.h2008-10-28
15:37:23.0 +1100
@@ -290,6 +290,7 @@ extern void pci_process_bridge_OF_ranges
/* Allocate & free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
+extern void pcibios_setup_phb_resources(struct pci_controller *hose);
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
15:35:56.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 15:37:23.0
+1100
@@ -1423,3 +1423,61 @@ int pcibios_enable_device(struct pci_dev
return pci_enable_resources(dev, mask);
}
+
+void __devinit pcibios_setup_phb_resources(struct pci_controller *hose)
+{
+ struct pci_bus *bus = hose->bus;
+ struct resource *res;
+ int i;
+
+ /* Hookup PHB IO resource */
+ bus->resource[0] = res = &hose->io_resource;
+
+ if (!res->flags) {
+ printk(KERN_WARNING "PCI: I/O resource not set for host"
+ " bridge %s (domain %d)\n",
+ hose->dn->full_name, hose->global_number);
+#ifdef CONFIG_PPC32
+ /* Workaround for lack of IO resource only on 32-bit */
+ res->start = (unsigned long)hose->io_base_virt - isa_io_base;
+ res->end = res->start + IO_SPACE_LIMIT;
+ res->flags = IORESOURCE_IO;
+#endif /* CONFIG_PPC32 */
+ }
+
+ pr_debug("PCI: PHB IO resource= %016llx-%016llx [%lx]\n",
+(unsigned long long)res->start,
+(unsigned long long)res->end,
+(unsigned long)res->flags);
+
+ /* Hookup PHB Memory resources */
+ for (i = 0; i < 3; ++i) {
+ res = &hose->mem_resources[i];
+ if (!res->flags) {
+ if (i > 0)
+ continue;
+ printk(KERN_ERR "PCI: Memory resource 0 not set for "
+ "host bridge %s (domain %d)\n",
+ hose->dn->full_name, hose->global_number);
+#ifdef CONFIG_PPC32
+ /* Workaround for lack of MEM resource only on 32-bit */
+ res->start = hose->pci_mem_offset;
+ res->end = (resource_size_t)-1LL;
+ res->flags = IORESOURCE_MEM;
+#endif /* CONFIG_PPC32 */
+ }
+ bus->resource[i+1] = res;
+
+ pr_debug("PCI: PHB MEM resource %d = %016llx-%016llx [%lx]\n",
i,
+(unsigned long long)res->start,
+(unsigned long long)res->end,
+(unsigned long)res->flags);
+ }
+
+ pr_debug("PCI: PHB MEM offset = %016llx\n",
+(unsigned long long)hose->pci_mem_offset);
+ pr_debug("PCI: PHB IO offset = %08lx\n",
+(unsigned long)hose->io_base_virt - _IO_BASE);
+
+}
+
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2008-10-28
15:35:56.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2008-10-28 15:42:13.0
+1100
@@ -373,10 +373,41 @@ void pcibios_make_OF_bus_map(void)
}
#endif /* CONFIG_PPC_OF */
+static void __devinit pcibios_scan_phb(struct pci_controller *hose)
+{
+ struct pci_bus *bus;
+ struct device_node *node = hose->dn;
+ unsigned long io_offset;
+ struct resource *res = &hose->io_reso
[PATCH 2/10] powerpc/pci: Cleanup debug printk's
This removes the various DBG() macro from the powerpc PCI code and
make it use the standard pr_debug instead.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c | 77 +++--
arch/powerpc/kernel/pci_32.c | 12 +
arch/powerpc/kernel/pci_64.c | 90 ++-
3 files changed, 82 insertions(+), 97 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
11:56:18.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 11:56:41.0
+1100
@@ -38,13 +38,6 @@
#include
#include
-#ifdef DEBUG
-#include
-#define DBG(fmt...) printk(fmt)
-#else
-#define DBG(fmt...)
-#endif
-
static DEFINE_SPINLOCK(hose_spinlock);
/* XXX kill that some day ... */
@@ -214,8 +207,8 @@ void __devinit pcibios_setup_new_device(
sd->of_node = pci_device_to_OF_node(dev);
- DBG("PCI: device %s OF node: %s\n", pci_name(dev),
- sd->of_node ? sd->of_node->full_name : "");
+ pr_debug("PCI: device %s OF node: %s\n", pci_name(dev),
+sd->of_node ? sd->of_node->full_name : "");
sd->dma_ops = pci_dma_ops;
#ifdef CONFIG_PPC32
@@ -252,7 +245,7 @@ int pci_read_irq_line(struct pci_dev *pc
return -1;
#endif
- DBG("Try to map irq for %s...\n", pci_name(pci_dev));
+ pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
#ifdef DEBUG
memset(&oirq, 0xff, sizeof(oirq));
@@ -276,26 +269,26 @@ int pci_read_irq_line(struct pci_dev *pc
line == 0xff || line == 0) {
return -1;
}
- DBG(" -> no map ! Using line %d (pin %d) from PCI config\n",
- line, pin);
+ pr_debug(" No map ! Using line %d (pin %d) from PCI config\n",
+line, pin);
virq = irq_create_mapping(NULL, line);
if (virq != NO_IRQ)
set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
} else {
- DBG(" -> got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
- oirq.size, oirq.specifier[0], oirq.specifier[1],
+ pr_debug(" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
+oirq.size, oirq.specifier[0], oirq.specifier[1],
oirq.controller->full_name);
virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
oirq.size);
}
if(virq == NO_IRQ) {
- DBG(" -> failed to map !\n");
+ pr_debug(" Failed to map !\n");
return -1;
}
- DBG(" -> mapped to linux irq %d\n", virq);
+ pr_debug(" Mapped to linux irq %d\n", virq);
pci_dev->irq = virq;
@@ -451,8 +444,8 @@ pgprot_t pci_phys_mem_access_prot(struct
pci_dev_put(pdev);
}
- DBG("non-PCI map for %llx, prot: %lx\n",
- (unsigned long long)offset, prot);
+ pr_debug("PCI: Non-PCI map for %llx, prot: %lx\n",
+(unsigned long long)offset, prot);
return __pgprot(prot);
}
@@ -1198,10 +1191,10 @@ static int __init reparent_resources(str
*pp = NULL;
for (p = res->child; p != NULL; p = p->sibling) {
p->parent = res;
- DBG(KERN_INFO "PCI: reparented %s [%llx..%llx] under %s\n",
- p->name,
- (unsigned long long)p->start,
- (unsigned long long)p->end, res->name);
+ pr_debug("PCI: Reparented %s [%llx..%llx] under %s\n",
+p->name,
+(unsigned long long)p->start,
+(unsigned long long)p->end, res->name);
}
return 0;
}
@@ -1271,14 +1264,14 @@ void pcibios_allocate_bus_resources(stru
}
}
- DBG("PCI: %s (bus %d) bridge rsrc %d: %016llx-%016llx "
- "[0x%x], parent %p (%s)\n",
- bus->self ? pci_name(bus->self) : "PHB",
- bus->number, i,
- (unsigned long long)res->start,
- (unsigned long long)res->end,
- (unsigned int)res->flags,
- pr, (pr && pr->name) ? pr->name : "nil");
+ pr_debug("PCI: %s (bus %d) bridge rsrc %d: %016llx-%016llx "
+"[0x%x], parent %p (%s)\n",
+bus->self ? pci_name(bus->self) : "PHB",
+bus->number, i,
+(unsigned long long)res->start,
+(unsigned long long)res->end,
+(unsigned int)res->flags,
+pr, (pr && pr->name) ? pr->name : "nil");
if (pr && !(pr->flags & IORESOURCE_UNSET)) {
if (request_resource(pr,
[PATCH 1/10] powerpc/pci: Properly allocate bus resources for hotplug PHBs
From: Nathan Fontenot <[EMAIL PROTECTED]>
Resources for PHB's that are dynamically added to a system are not
properly allocated in the resource tree.
Not having these resources allocated causes an oops when removing
the PHB when we try to release them.
The patch appears a bit messy, this is mainly due to moving everything
one tab to the left in the pcibios_allocate_bus_resources routine. The
big functionality change in this routine is only that the
list_for_each_entry() loop is pulled out and moved to the necessary
calling routine.
Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/pci.h |2
arch/powerpc/kernel/pci-common.c | 110 ++---
arch/powerpc/platforms/pseries/pci_dlpar.c |2
3 files changed, 59 insertions(+), 55 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2008-10-28
15:02:27.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-10-28 15:02:50.0
+1100
@@ -1239,69 +1239,66 @@ static int __init reparent_resources(str
* as well.
*/
-static void __init pcibios_allocate_bus_resources(struct list_head *bus_list)
+void pcibios_allocate_bus_resources(struct pci_bus *bus)
{
- struct pci_bus *bus;
+ struct pci_bus *b;
int i;
struct resource *res, *pr;
- /* Depth-First Search on bus tree */
- list_for_each_entry(bus, bus_list, node) {
- for (i = 0; i < PCI_BUS_NUM_RESOURCES; ++i) {
- if ((res = bus->resource[i]) == NULL || !res->flags
- || res->start > res->end)
- continue;
- if (bus->parent == NULL)
- pr = (res->flags & IORESOURCE_IO) ?
- &ioport_resource : &iomem_resource;
- else {
- /* Don't bother with non-root busses when
-* re-assigning all resources. We clear the
-* resource flags as if they were colliding
-* and as such ensure proper re-allocation
-* later.
+ for (i = 0; i < PCI_BUS_NUM_RESOURCES; ++i) {
+ if ((res = bus->resource[i]) == NULL || !res->flags
+ || res->start > res->end)
+ continue;
+ if (bus->parent == NULL)
+ pr = (res->flags & IORESOURCE_IO) ?
+ &ioport_resource : &iomem_resource;
+ else {
+ /* Don't bother with non-root busses when
+* re-assigning all resources. We clear the
+* resource flags as if they were colliding
+* and as such ensure proper re-allocation
+* later.
+*/
+ if (ppc_pci_flags & PPC_PCI_REASSIGN_ALL_RSRC)
+ goto clear_resource;
+ pr = pci_find_parent_resource(bus->self, res);
+ if (pr == res) {
+ /* this happens when the generic PCI
+* code (wrongly) decides that this
+* bridge is transparent -- paulus
*/
- if (ppc_pci_flags & PPC_PCI_REASSIGN_ALL_RSRC)
- goto clear_resource;
- pr = pci_find_parent_resource(bus->self, res);
- if (pr == res) {
- /* this happens when the generic PCI
-* code (wrongly) decides that this
-* bridge is transparent -- paulus
-*/
- continue;
- }
+ continue;
}
+ }
- DBG("PCI: %s (bus %d) bridge rsrc %d: %016llx-%016llx "
- "[0x%x], parent %p (%s)\n",
- bus->self ? pci_name(bus->self) : "PHB",
- bus->number, i,
- (unsigned long long)res->start,
- (unsigned long long)res->end,
- (unsigned int)res->flags,
- pr, (pr && pr->name) ? pr->name : "nil");
-
- if (pr && !(pr->flags & IORESOURCE_UNSET)) {
- if (request_resource(pr, res) == 0)
- continue;
- /*
-* Must be a conflict with an existing entry.
-* Mo
[PATCH 0/10] powerpc/pci: Fix PCI Hotplug
This series of patches is aimed at fixing all sort of issues with the PCI hotplug support on pSeries. The meant is in the second to last patch, but it relies on a whole bunch of small changes to separate the bus fixup operation in two that are needed to fix the root of most problems. Please review/test asap as I would like that in 2.6.28 despite being a bit late, as without these, PCI hotplug on pseries pretty much doesn't work. It should also make it easier in the future to implement hotplug support on other platforms. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <[EMAIL PROTECTED]> wrote: > > > David Gibson wrote: >> >> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote: >> >> So, you use >>gpios = <&controller pin1-specifier &controller pin8-specifier >> &controller pin9-specifier &controller pin11-specifier >> &controller pin15-specifier &controller pin30-specifier>; > > Okay that makes some more sense to me. > > So now my qualm is back to the beginning of the discussion. How do > we encode the purpose of those pins reliably and within some > standard framework, without getting *driver* specific? > > Take the example of an LCD controller with an 8-bit bus and two > control pins, if you put all 10 into a gpios property, explicit > knowledge of the purpose of those pins is lost. It must then be > encoded directly into the driver.. I disagree. With the approach we've been following the meaning of those 10 gpio pins is not lost because we make a point of documenting it (granted in the Linux kernel tree at the moment which is far from ideal). The knowledge of what those GPIOs are for is all bound up with the documented binding attached to the compatible value. > I liked Anton's suggestion of grouping them and creating new nodes, > but you didn't like it when it was suggested before, so, I'm > wondering if there's a middle ground.. I've got no problem with this myself, but I don't think it really adds much in terms of additional information because users still need to refer to binding documentation to figure out what it actually means. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] Add SPE/EFP math emulation for E500v1/v2 processors.
This patch add the handlers of SPE/EFP exceptions.
The code is used to emulate float point arithmetic,
when MSR(SPE) is enabled and receive EFP data interrupt or EFP round interrupt.
This patch has no conflict with or dependence on FP math-emu.
The code has been tested by TestFloat.
Now the code doesn't support SPE/EFP instructions emulation
(it won't be called when receive program interrupt),
but it could be easily added.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/processor.h |6 +
arch/powerpc/include/asm/sfp-machine.h | 36 ++-
arch/powerpc/kernel/head_fsl_booke.S |7 +-
arch/powerpc/kernel/traps.c| 62 +++-
arch/powerpc/math-emu/Makefile |2 +
arch/powerpc/math-emu/math_efp.c | 720
6 files changed, 813 insertions(+), 20 deletions(-)
create mode 100644 arch/powerpc/math-emu/math_efp.c
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 101ed87..cd7a478 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -207,6 +207,11 @@ struct thread_struct {
#define INIT_SP_LIMIT \
(_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) &init_stack)
+#ifdef CONFIG_SPE
+#define SPEFSCR_INIT .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE
| SPEFSCR_FOVFE,
+#else
+#define SPEFSCR_INIT
+#endif
#ifdef CONFIG_PPC32
#define INIT_THREAD { \
@@ -215,6 +220,7 @@ struct thread_struct {
.fs = KERNEL_DS, \
.pgdir = swapper_pg_dir, \
.fpexc_mode = MSR_FE0 | MSR_FE1, \
+ SPEFSCR_INIT \
}
#else
#define INIT_THREAD { \
diff --git a/arch/powerpc/include/asm/sfp-machine.h
b/arch/powerpc/include/asm/sfp-machine.h
index 88af036..3d9f831 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -97,6 +97,20 @@
#define _FP_KEEPNANFRACP 1
+#ifdef FP_EX_BOOKE_E500_SPE
+#define FP_EX_INEXACT (1 << 21)
+#define FP_EX_INVALID (1 << 20)
+#define FP_EX_DIVZERO (1 << 19)
+#define FP_EX_UNDERFLOW(1 << 18)
+#define FP_EX_OVERFLOW (1 << 17)
+#define FP_INHIBIT_RESULTS 0
+
+#define __FPU_FPSCR(current->thread.spefscr)
+#define __FPU_ENABLED_EXC \
+({ \
+ (__FPU_FPSCR >> 2) & 0x1f; \
+})
+#else
/* Exception flags. We use the bit positions of the appropriate bits
in the FPSCR, which also correspond to the FE_* bits. This makes
everything easier ;-). */
@@ -111,6 +125,18 @@
#define FP_EX_DIVZERO (1 << (31 - 5))
#define FP_EX_INEXACT (1 << (31 - 6))
+#define __FPU_FPSCR(current->thread.fpscr.val)
+
+/* We only actually write to the destination register
+ * if exceptions signalled (if any) will not trap.
+ */
+#define __FPU_ENABLED_EXC \
+({ \
+ (__FPU_FPSCR >> 3) & 0x1f; \
+})
+
+#endif
+
/*
* If one NaN is signaling and the other is not,
* we choose that one, otherwise we choose X.
@@ -135,16 +161,6 @@
#include
#include
-#define __FPU_FPSCR(current->thread.fpscr.val)
-
-/* We only actually write to the destination register
- * if exceptions signalled (if any) will not trap.
- */
-#define __FPU_ENABLED_EXC \
-({ \
- (__FPU_FPSCR >> 3) & 0x1f; \
-})
-
#define __FPU_TRAP_P(bits) \
((__FPU_ENABLED_EXC & (bits)) != 0)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index 1751882..8075afb 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -1027,12 +1027,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_BIG_PHYS)
/* SPE Floating Point Data */
#ifdef CONFIG_SPE
EXCEPTION(0x2030, SPEFloatingPointData, SPEFloatingPointException,
EXC_XFER_EE);
-#else
- EXCEPTION(0x2040, SPEFloatingPointData, unknown_exception, EXC_XFER_EE)
-#endif /* CONFIG_SPE */
/* SPE Floating Point Round */
+ EXCEPTION(0x2050, SPEFloatingPointRound,
SPEFloatingPointRoundException, EXC_XFER_EE)
+#else
+ EXCEPTION(0x2040, SPEFloatingPointData, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x2050, SPEFloatingPointRound, unknown_exception, EXC_XFER_EE)
+#endif /* CONFIG_SPE */
/* Performance Monitor */
EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception,
EXC_XFER_STD)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 81ccb8d..cab88aa 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1161,37 +1161,85 @@ void CacheLockingException(struct pt_regs *regs,
unsigned long address,
#ifdef CONFIG_SPE
void SPEFloatingPointException(struct pt_regs *regs)
{
+ extern int do_spe_mathemu(struct pt_regs *regs);
unsigned long spefscr;
int fpexc_mode;
int code = 0;
+ int err
[PATCH 3/4] math-emu: Remove redundant 'ret'
FP_DECL_EX is already used, so ret is redundant.
And FP_SET_EXCEPTION will add status into return value.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/math-emu/fadd.c|1 -
arch/powerpc/math-emu/fcmpo.c |5 ++---
arch/powerpc/math-emu/fdiv.c|9 -
arch/powerpc/math-emu/fdivs.c |9 -
arch/powerpc/math-emu/fmadd.c |5 ++---
arch/powerpc/math-emu/fmadds.c |5 ++---
arch/powerpc/math-emu/fmsub.c |5 ++---
arch/powerpc/math-emu/fmsubs.c |5 ++---
arch/powerpc/math-emu/fmul.c|3 +--
arch/powerpc/math-emu/fmuls.c |3 +--
arch/powerpc/math-emu/fnmadd.c |5 ++---
arch/powerpc/math-emu/fnmadds.c |5 ++---
arch/powerpc/math-emu/fnmsub.c |5 ++---
arch/powerpc/math-emu/fnmsubs.c |5 ++---
arch/powerpc/math-emu/fsqrt.c |5 ++---
arch/powerpc/math-emu/fsqrts.c |5 ++---
arch/powerpc/math-emu/fsub.c|3 +--
arch/powerpc/math-emu/fsubs.c |3 +--
18 files changed, 34 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/math-emu/fadd.c b/arch/powerpc/math-emu/fadd.c
index 04d3b4a..0158a16 100644
--- a/arch/powerpc/math-emu/fadd.c
+++ b/arch/powerpc/math-emu/fadd.c
@@ -13,7 +13,6 @@ fadd(void *frD, void *frA, void *frB)
FP_DECL_D(B);
FP_DECL_D(R);
FP_DECL_EX;
- int ret = 0;
#ifdef DEBUG
printk("%s: %p %p %p\n", __func__, frD, frA, frB);
diff --git a/arch/powerpc/math-emu/fcmpo.c b/arch/powerpc/math-emu/fcmpo.c
index b5dc449..5bce011 100644
--- a/arch/powerpc/math-emu/fcmpo.c
+++ b/arch/powerpc/math-emu/fcmpo.c
@@ -14,7 +14,6 @@ fcmpo(u32 *ccr, int crfD, void *frA, void *frB)
FP_DECL_EX;
int code[4] = { (1 << 3), (1 << 1), (1 << 2), (1 << 0) };
long cmp;
- int ret = 0;
#ifdef DEBUG
printk("%s: %p (%08x) %d %p %p\n", __func__, ccr, *ccr, crfD, frA, frB);
@@ -29,7 +28,7 @@ fcmpo(u32 *ccr, int crfD, void *frA, void *frB)
#endif
if (A_c == FP_CLS_NAN || B_c == FP_CLS_NAN)
- ret |= EFLAG_VXVC;
+ FP_SET_EXCEPTION(EFLAG_VXVC);
FP_CMP_D(cmp, A, B, 2);
cmp = code[(cmp + 1) & 3];
@@ -44,5 +43,5 @@ fcmpo(u32 *ccr, int crfD, void *frA, void *frB)
printk("CR: %08x\n", *ccr);
#endif
- return ret;
+ return FP_CUR_EXCEPTIONS;
}
diff --git a/arch/powerpc/math-emu/fdiv.c b/arch/powerpc/math-emu/fdiv.c
index 2db1509..a29239c 100644
--- a/arch/powerpc/math-emu/fdiv.c
+++ b/arch/powerpc/math-emu/fdiv.c
@@ -13,7 +13,6 @@ fdiv(void *frD, void *frA, void *frB)
FP_DECL_D(B);
FP_DECL_D(R);
FP_DECL_EX;
- int ret = 0;
#ifdef DEBUG
printk("%s: %p %p %p\n", __func__, frD, frA, frB);
@@ -28,22 +27,22 @@ fdiv(void *frD, void *frA, void *frB)
#endif
if (A_c == FP_CLS_ZERO && B_c == FP_CLS_ZERO) {
- ret |= EFLAG_VXZDZ;
+ FP_SET_EXCEPTION(EFLAG_VXZDZ);
#ifdef DEBUG
printk("%s: FPSCR_VXZDZ raised\n", __func__);
#endif
}
if (A_c == FP_CLS_INF && B_c == FP_CLS_INF) {
- ret |= EFLAG_VXIDI;
+ FP_SET_EXCEPTION(EFLAG_VXIDI);
#ifdef DEBUG
printk("%s: FPSCR_VXIDI raised\n", __func__);
#endif
}
if (B_c == FP_CLS_ZERO && A_c != FP_CLS_ZERO) {
- ret |= EFLAG_DIVZERO;
+ FP_SET_EXCEPTION(EFLAG_DIVZERO);
if (__FPU_TRAP_P(EFLAG_DIVZERO))
- return ret;
+ return FP_CUR_EXCEPTIONS;
}
FP_DIV_D(R, A, B);
diff --git a/arch/powerpc/math-emu/fdivs.c b/arch/powerpc/math-emu/fdivs.c
index 797f6a9..526bc26 100644
--- a/arch/powerpc/math-emu/fdivs.c
+++ b/arch/powerpc/math-emu/fdivs.c
@@ -14,7 +14,6 @@ fdivs(void *frD, void *frA, void *frB)
FP_DECL_D(B);
FP_DECL_D(R);
FP_DECL_EX;
- int ret = 0;
#ifdef DEBUG
printk("%s: %p %p %p\n", __func__, frD, frA, frB);
@@ -29,22 +28,22 @@ fdivs(void *frD, void *frA, void *frB)
#endif
if (A_c == FP_CLS_ZERO && B_c == FP_CLS_ZERO) {
- ret |= EFLAG_VXZDZ;
+ FP_SET_EXCEPTION(EFLAG_VXZDZ);
#ifdef DEBUG
printk("%s: FPSCR_VXZDZ raised\n", __func__);
#endif
}
if (A_c == FP_CLS_INF && B_c == FP_CLS_INF) {
- ret |= EFLAG_VXIDI;
+ FP_SET_EXCEPTION(EFLAG_VXIDI);
#ifdef DEBUG
printk("%s: FPSCR_VXIDI raised\n", __func__);
#endif
}
if (B_c == FP_CLS_ZERO && A_c != FP_CLS_ZERO) {
- ret |= EFLAG_DIVZERO;
+ FP_SET_EXCEPTION(EFLAG_DIVZERO);
if (__FPU_TRAP_P(EFLAG_DIVZERO))
- return ret;
+ return FP_CUR_EXCEPTIONS;
}
FP_DIV_D(R, A, B);
diff --git a/arch/powerpc/math-emu/fmadd.c b/arch/powerpc/math-emu/fmadd.c
index 925313a..8c3f20a 100644
--- a/arch/powerpc/math-emu/fmadd.c
+++ b/arch/powerpc/math-emu/fmadd.c
@@ -1
[PATCH 1/4] math-emu: Fix single float point division bug
PowerPC float point division emulation is derived from gcc. I reported this problem on gcc maillist and got this reply: http://gcc.gnu.org/ml/gcc/2008-03/msg00543.html Since UDIV_NEEDS_NORMALIZATION is not used by kernel, we should use _FP_DIV_MEAT_1_udiv_norm to make sure the single float point is normalized before udiv_qrnnd. Signed-off-by: Liu Yu <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/sfp-machine.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h index ced34f1..da12ea7 100644 --- a/arch/powerpc/include/asm/sfp-machine.h +++ b/arch/powerpc/include/asm/sfp-machine.h @@ -82,7 +82,7 @@ #define _FP_MUL_MEAT_S(R,X,Y) _FP_MUL_MEAT_1_wide(_FP_WFRACBITS_S,R,X,Y,umul_ppmm) #define _FP_MUL_MEAT_D(R,X,Y) _FP_MUL_MEAT_2_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm) -#define _FP_DIV_MEAT_S(R,X,Y) _FP_DIV_MEAT_1_udiv(S,R,X,Y) +#define _FP_DIV_MEAT_S(R,X,Y) _FP_DIV_MEAT_1_udiv_norm(S,R,X,Y) #define _FP_DIV_MEAT_D(R,X,Y) _FP_DIV_MEAT_2_udiv(D,R,X,Y) /* These macros define what NaN looks like. They're supposed to expand to -- 1.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] math-emu: Adopt new version of _FP_CHOOSENAN
Move to using the same macro definition for _FP_CHOOSENAN as s390,
sh, sparc32/64. The original author didn't understand this and
matched what sparc64 was doing and they have updated to this definition.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/sfp-machine.h | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/sfp-machine.h
b/arch/powerpc/include/asm/sfp-machine.h
index da12ea7..88af036 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -111,16 +111,24 @@
#define FP_EX_DIVZERO (1 << (31 - 5))
#define FP_EX_INEXACT (1 << (31 - 6))
-/* This macro appears to be called when both X and Y are NaNs, and
- * has to choose one and copy it to R. i386 goes for the larger of the
- * two, sparc64 just picks Y. I don't understand this at all so I'll
- * go with sparc64 because it's shorter :-> -- PMM
+/*
+ * If one NaN is signaling and the other is not,
+ * we choose that one, otherwise we choose X.
*/
-#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP) \
- do { \
-R##_s = Y##_s; \
-_FP_FRAC_COPY_##wc(R,Y); \
-R##_c = FP_CLS_NAN;\
+#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP) \
+ do { \
+if ((_FP_FRAC_HIGH_RAW_##fs(Y) & _FP_QNANBIT_##fs) \
+ && !(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs)) \
+ {\
+ R##_s = X##_s; \
+ _FP_FRAC_COPY_##wc(R,X);\
+ }\
+else \
+ {\
+ R##_s = Y##_s; \
+ _FP_FRAC_COPY_##wc(R,Y);\
+ }\
+R##_c = FP_CLS_NAN;\
} while (0)
--
1.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch 0/4] math-emu
These patches are related to math-emu. [Patch 1/4] Fix a fdiv bug of FP math-emu [Patch 2/4] Update a macro to new version [Patch 3/4] Remove redundant code [Patch 4/4] Add SPE/EFP handlers for E500v1/v2 processors ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> Are there any plans for a mechanism to allow the kernel to figure out (or be told) what packets cpu-affined tasks are interested in and route the interrupts appropriately? No, not at all. Now there are plans to allow the user to add classification rules into the chip for specific flows, on hardware that supports this, via ethtool. Okay, that sounds reasonable. Good to know where you're planning on going. Your driver is weak and doesn't support the hardware correctly, and you want to put the onus on everyone else with sane hardware and drivers? I'm not expecting any action...I was just objecting somewhat to "Networking interrupts should lock onto a single CPU, unconditionally." Add "for a particular flow" into that and I wouldn't have said anything. It's not an ideal situation, but we're sort of stuck unless we do custom driver work. Wouldn't want you to get your hands dirty or anything like that now, would we? :-))) I'd love to. But other things take time too, so we live with it for now. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Add new CPU feature: CPU_FTR_UNALIGNED_LD_STD
Kumar Gala writes: > not that I have anything against this patch but is there anything we > can do about the CPU_FTR_ usage for one of things like this? Can you express that a little more coherently for us, please? :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Work around ld bug in older binutils
Sean MacLennan writes: > I'd like to try this. I did a git revert to back out the aforementioned > commit. How do I get it back? Do I git revert again? You could revert the reversion, or else rebase any patches you have on top of the reversion onto the commit before the reversion. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 08:11:12PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
>>>
>>> A bunch of things spring to mind:
>>>
>>> * How do you define a GPIO bank in a device tree, not a controller
>>
>> Not a controller? What do you mean by "bank"? There is no such
>> thing. There are GPIO controllers, and _maybe_ _their_ banks of
>> GPIOs.
>
> I don't know what you want to call it, I don't know what the official
> Linux term might be for a grouped bunch of GPIO used for a peripheral.
You don't know this term because there isn't any. There is no term
for "bunch of GPIO used for a peripheral".
But there are:
- gpio controllers;
- devices that use some gpios;
- gpios = <>; property that is used to denote which gpios the device
is using.
What's so hard about that?
>>> but a grouping of pins which fit that pattern, of which there
>>> may be multiple groupings for multiple peripheral functions
>>
>> Why do you need this, _exactly_? What problem this would solve? But
>> see below, this is still possible to implement.
>
> I made a pretty good example with the lcd controller, I thought..
Yes, thanks for the example. And I don't see any problems with
describing the lcd controller.
>> But I still wonder what problem exactly you're trying to solve
>> here? Prevent requesting reserved gpios? I don't see any point
>> in this, really.
>
> There's plenty of reason for it, it's totally wrong to be able
> to request a GPIO which has been multiplexed to another device
> in the SoC, and probably completely undefined behaviour if you
> start toggling a pin that's been assigned to an internal
> controller.
Then just don't specify the wrong GPIO in the gpios = <>! It is
that simple.
You don't specify the SOC's peripheral memory in the /memory node,
do you? I bet you don't. Can you? Yes. Bad things will happen? Sure.
You may bring the gpio sysfs example. But I can answer back with the
/dev/mem example. There are plenty of things you can do bad things
with, even being in the userspace.
> Since you have no way of knowing except intimate board design
> knowledge in the driver.. well, that defeats the purpose of the
> device tree in general and is a step back into hardcoded information
> in board support from arch/ppc days etc..
>
> This information SHOULD be in the device tree specifically because
> there is one very popular chip here which has GPIO multiplexed with
> other very-often-used peripherals, and I can think of at least 5
> other chips which also have device trees and GPIO potential (4 of
> which we have designed boards around) which fit the same model and
> would have the same requirement.
>
> There are two ways you can do it; implicit and explicit. If a
> pin is not defined for a peripheral in the device tree, it is
> not requestable from GPIOLIB. Or, you make sure that you specify
This is doable and _maybe_ a good idea. Though I don't see much
value in this.
>> No problem. Define bindings for "8 GPIOs data group".
>>
>> /* 8bit Parallel I/O port using arbitrary gpios */
>> byte_pio: byte-pio {
>> compatible = "byte-pio";
>> gpios = <&controller1 0 1 /* data line 0 */
>> &controller2 12 0 /* data line 1 */
>> ...>;
>> };
>>
>> lcd-controller {
>> /* the lcd controller can simply use the pio_out_8(),
>> * pio_in_8() API. The API is easily implemented. */
>> lcd-data-port = <&byte_pio>;
>> }
>>
>>> and 1 for data/control selection, it would be nice for the
>>> software to know which pin is which and, slightly unrelated,
>>> which way around the data pins went - MSB first or LSB first
>>> - from the device tree, as this is a BOARD LEVEL DESIGN DECISION
>>> which is what the device tree is meant to abstract - in the same
>>> way we define i2c controllers and clients?)
>
> And this? What about the other two control lines? Do they just get
> set in the gpios property of the lcd-controller? How do you determine
> which is which?
This depends on how will you write the bindings.
> Comments don't get compiled..
If you _really_ want to complicate things, you can write gpios for
devices like this:
device {
data0-gpio = <&controller1 1 1>;
...
rw-gpio = <&controller1 2 1>;
}
This _will_ get compiled in. This is insane, but this is more friendly
to a device tree reader, if you like.
> and a driver will have
> to be written FROM the comments, hardcoding the pins into it, again.
What do you mean by "hardcoding"? Let's see: interrupts = <33 32>;
and then extracting them via
of_irq_to_resource(node, 0, &tx_irq),
of_irq_to_resource(node, 1, &rx_irq).
Does this mean "hard-coding"?
[...]
>>> I don't feel the current spec actually takes this into account
>>> and the patch submission the other day from Wolfgang made me
>>> think that if a "base" register is the obvious solution to some
>>> problem, then it either can't be that clear to others (i.e. it
>>> is n
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 07:51:23PM -0500, Matt Sealey wrote: > > > David Gibson wrote: >> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote: >> >> Uh.. no. The gpio specifier has a format that's gpio controller >> specific, but it must include the actual pin number, although exactly >> how it's encoded might vary. >> >> So, you use >> gpios = <&controller pin1-specifier &controller pin8-specifier >> &controller pin9-specifier &controller pin11-specifier >> &controller pin15-specifier &controller pin30-specifier>; > > Okay that makes some more sense to me. > > So now my qualm is back to the beginning of the discussion. How do > we encode the purpose of those pins reliably and within some > standard framework, without getting *driver* specific? Um.. I fail to see how the purpose of a pin can be not driver specific. > Take the example of an LCD controller with an 8-bit bus and two > control pins, if you put all 10 into a gpios property, explicit > knowledge of the purpose of those pins is lost. It must then be > encoded directly into the driver.. Yes, this is normal. Just as the driver for a device must know the function of each entry in 'reg' for its specific device, and what each interrupt in 'interrupts' is used for. > I liked Anton's suggestion of grouping them and creating new nodes, > but you didn't like it when it was suggested before, so, I'm > wondering if there's a middle ground.. I have no problem with the suggestion of gpio_header nodes, if that's what you're referring to (although I do suspect occasions on which they are useful would be limited). -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller? What do you mean by "bank"? There is no such
thing. There are GPIO controllers, and _maybe_ _their_ banks of
GPIOs.
I don't know what you want to call it, I don't know what the official
Linux term might be for a grouped bunch of GPIO used for a peripheral.
but a grouping of pins which fit that pattern, of which there
may be multiple groupings for multiple peripheral functions
Why do you need this, _exactly_? What problem this would solve? But
see below, this is still possible to implement.
I made a pretty good example with the lcd controller, I thought..
But I still wonder what problem exactly you're trying to solve
here? Prevent requesting reserved gpios? I don't see any point
in this, really.
There's plenty of reason for it, it's totally wrong to be able
to request a GPIO which has been multiplexed to another device
in the SoC, and probably completely undefined behaviour if you
start toggling a pin that's been assigned to an internal
controller.
Since you have no way of knowing except intimate board design
knowledge in the driver.. well, that defeats the purpose of the
device tree in general and is a step back into hardcoded information
in board support from arch/ppc days etc..
This information SHOULD be in the device tree specifically because
there is one very popular chip here which has GPIO multiplexed with
other very-often-used peripherals, and I can think of at least 5
other chips which also have device trees and GPIO potential (4 of
which we have designed boards around) which fit the same model and
would have the same requirement.
There are two ways you can do it; implicit and explicit. If a
pin is not defined for a peripheral in the device tree, it is
not requestable from GPIOLIB. Or, you make sure that you specify
No problem. Define bindings for "8 GPIOs data group".
/* 8bit Parallel I/O port using arbitrary gpios */
byte_pio: byte-pio {
compatible = "byte-pio";
gpios = <&controller1 0 1 /* data line 0 */
&controller2 12 0 /* data line 1 */
...>;
};
lcd-controller {
/* the lcd controller can simply use the pio_out_8(),
* pio_in_8() API. The API is easily implemented. */
lcd-data-port = <&byte_pio>;
}
and 1 for data/control selection, it would be nice for the
software to know which pin is which and, slightly unrelated,
which way around the data pins went - MSB first or LSB first
- from the device tree, as this is a BOARD LEVEL DESIGN DECISION
which is what the device tree is meant to abstract - in the same
way we define i2c controllers and clients?)
And this? What about the other two control lines? Do they just get
set in the gpios property of the lcd-controller? How do you determine
which is which? Comments don't get compiled.. and a driver will have
to be written FROM the comments, hardcoding the pins into it, again.
I refer you to the little discussion about Xilinx cores and GPIO
which may change from build to build due to pin mapping requirements
and autofitting. There are plenty of cases where you'd implement
some board design where you do not want to rewrite and recompile a
driver after you've just revised your FPGA design for some reason.
* At the end of the day the GPIO device tree binding is barely
20 lines at the bottom of a file that has been superceded by
the ePAPR standard now, so where do we stand on this anyway?
(I will ask that same last question of the i2c guys, I have never
seen the Linux i2c device binding in the tree - maybe I am not
looking hard enough - and the Sun binding seems to be a secret
that only special people are allowed to see)
Please don't mix threads. Start a new thread for i2c guys.
It's simply a reference to a similar problem.
I don't feel the current spec actually takes this into account
and the patch submission the other day from Wolfgang made me
think that if a "base" register is the obvious solution to some
problem, then it either can't be that clear to others (i.e. it
is not just me being stupid) or it is simply not possible under
the current binding.
Wolfgang's patch proved to be unnecessary, you haven't seen
the solution?
Wolfgang's patch would never have been considered by Wolfgang
if the solution wasn't more obvious... this is why I started
the thread :D
At the very least it needs documenting better,
Feel free to write a better documentation.
I'm more confused now about how this is meant to be done than
I was when I started.
Device tree authors may as well just make shit up on the spot
at this point... write an entirely specific driver for their
effort, and it will still get in, and everyone will be using
that hack as an example of what is right.
That happens too often by my book.
I don't know how did
Re: [PATCH] Work around ld bug in older binutils
On Thu, 23 Oct 2008 15:43:45 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Commit 549e8152de8039506f69c677a4546e5427aa6ae7 ("powerpc: Make the
> 64-bit kernel as a position-independent executable") added lines to
> vmlinux.lds.S to add the extra sections needed to implement a
> relocatable kernel. However, those lines seem to trigger a bug in
> older versions of GNU ld (such as 2.16.1) when building a
> non-relocatable kernel. Since ld 2.16.1 is still a popular choice for
> cross-toolchains, this adds an #ifdef to vmlinux.lds.S so the added
> lines are only included when building a relocatable kernel.
I'd like to try this. I did a git revert to back out the aforementioned
commit. How do I get it back? Do I git revert again?
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
David Gibson wrote: On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote: Uh.. no. The gpio specifier has a format that's gpio controller specific, but it must include the actual pin number, although exactly how it's encoded might vary. So, you use gpios = <&controller pin1-specifier &controller pin8-specifier &controller pin9-specifier &controller pin11-specifier &controller pin15-specifier &controller pin30-specifier>; Okay that makes some more sense to me. So now my qualm is back to the beginning of the discussion. How do we encode the purpose of those pins reliably and within some standard framework, without getting *driver* specific? Take the example of an LCD controller with an 8-bit bus and two control pins, if you put all 10 into a gpios property, explicit knowledge of the purpose of those pins is lost. It must then be encoded directly into the driver.. I liked Anton's suggestion of grouping them and creating new nodes, but you didn't like it when it was suggested before, so, I'm wondering if there's a middle ground.. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Anton Vorontsov wrote: On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote: [...] * How do you stop GPIOLIB from blindly approving requests to use pins marked X, without making it "controller-specific"? Btw, as for pins marked X... If the gpio controller has some register that specify which pins are not available to use as GPIOs, then just read that register, check its value and return -ENODEV from the .request() gpiolib callback. It doesn't. At least not close by. This is easily doable for QE/CPM gpio controllers (they have option registers), but nobody cares to check them. There are plenty of examples where this information is encoded somewhere else in the chip and Ben Herrenschmidt et al. have recommended that it be put in the device tree so that drivers do not have to go and check registers in other units to get that information. However there is no standard way to expose it. And people just grab a pin they "know" is free on their particular board. Are you sure you do NOT see any shortcomings here? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 12:54:15PM -0500, Scott Wood wrote: > Matt Sealey wrote: >> Scott Wood wrote: >>> It's deprecated *in the context of flat device trees*. Anything not >>> using flat device trees is out-of-scope with respect to ePAPR. >> >> Isn't the beauty of a device tree that every firmware no matter what >> type can present it in whatever form it chooses, but still be describing >> the same hardware in the same way? > > When run-time services are not involved, yes. device_type was used by > 1275 in the context of run-time services, which we don't have, so we > didn't copy that property over (except for memory and cpu, to avoid > gratuitous divergence). > >> I'm curious, is it the remit of the ePAPR TSC to publish and act as >> a registration authority for device tree bindings for specific SoCs >> or is that devolved to the SoC maker itself (be they a member of >> Power.org or not) and, more prudent, two other questions; where are >> Freescale and IBM publishing these if it is their responsibility, >> are things like the mysterious i2c binding going to be published >> under this TSC? > > There has been talk about setting up such a repository, but I'm not sure > what the status of it is. Progressing intermittently when people get small packets of time to actually do something about it. We do really want this, it's just no-one's yet had the spare cycles to make it happen. At the moment things are published in the kernel documentation (booting-without-of.txt, although I think it's now been split up into multiple files), which is far from ideal, but better than nothing. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 11:12:07AM -0500, Matt Sealey wrote: > > > David Gibson wrote: >> On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote: >>> >>> Mitch Bradley wrote: >> >> device_type in 1275 defines the runtime method interface. It's *not* >> for declaring the general class of the device, although it often >> matches that in practice. > > It *is* for declaring the general class of the device, even if it's > purpose is to make it known that it implements all the required > methods and therefore acts in a certain predefined way when those > methods are used; it's not a necessary property but it is a USEFUL > property: No, it's really not. There are only two ways device class information can be useful: - for human readability. For this purpose the node name with the generic names convention suffices. - for manipulating the device without having a driver specific to the device. This works *only* if there is a class-defined protocol for doing this manipulation. Clearly, this can't exist unless the firmware provides some sort of runtime service to abstract away differences between devices. Flat trees cannot of themselves provide such a thing, and so should not advertise that they can with device_type. Even if a firmware did provide run time services, but they weren't in the form of the OF defined method interface, they should not use device_type, but some other property to advertise their own particular brand of runtime service interface. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote: > > > David Gibson wrote: > >> Um.. I can't actually follow what you're getting at there, sorry. > > Imagine in your head that you have a GPIO controller that has a > 32-bit register potentially controlling 32 pins on the chip. > > Imagine that rather than being able to allocate 6 GPIO pins > *right next to each other* in the register and saying that > you start at "pin" 15 and use the next 6 "pins", you have to > spread it around and use pin 1, pin 8, pin 9, pin 11, pin 15, > pin 30, to make up this peripheral. > > As far as I can tell there is no way at all to specify a set of > GPIO pins which are NOT consecutive because the current GPIO > spec stops after specifying a controller bank (the 32-bit > register). Uh.. no. The gpio specifier has a format that's gpio controller specific, but it must include the actual pin number, although exactly how it's encoded might vary. So, you use gpios = <&controller pin1-specifier &controller pin8-specifier &controller pin9-specifier &controller pin11-specifier &controller pin15-specifier &controller pin30-specifier>; -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] oops in net_rx_action on 64-bit powerpc
David Miller wrote:
> Probably the simplest fix is to get rid of the rx_not_empty label and
> protect the entire:
>
>/* Receive descriptor is empty now */
>spin_lock_irqsave(&lp->lock, flags);
>__netif_rx_complete(dev, napi);
>writel(VAL0|RINTEN0, mmio + INTEN0);
>writel(VAL2 | RDMD0, mmio + CMD0);
>spin_unlock_irqrestore(&lp->lock, flags);
>
> code block with a test such as:
>
>if (rx_pkt_limit > 0)
>
> (yes, greater than zero, not >= 0)
>
> then replace the rx_not_empty goto with a simple break.
Are you sure about that? Doing that, if we "--rx_pkt_limit < 0" we'll only
break out of the inner while loop. We then check then interrupt status
register and potentially loop through the do/while loop again (maybe
decrementing rx_pkt_limit again) even though we've used up our budget.
If I leave the label and jump and just add the "rx_pkt_limit > 0" test, it
seems to work.
Chris
From: Chris Friesen<[EMAIL PROTECTED]>
Subject: [PATCH] fix amd8111e rx return code
The amd8111e rx poll routine currently mishandles the case when we process
exactly the number of packets specified in the budget.
This patch is basically as suggested by David Miller.
Signed-off-by: Chris Friesen <[EMAIL PROTECTED]>
diff --git a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
index c54967f..ba1be0b 100644
--- a/drivers/net/amd8111e.c
+++ b/drivers/net/amd8111e.c
@@ -833,12 +833,14 @@ static int amd8111e_rx_poll(struct napi_struct *napi,
int budget)
} while(intr0 & RINT0);
- /* Receive descriptor is empty now */
- spin_lock_irqsave(&lp->lock, flags);
- __netif_rx_complete(dev, napi);
- writel(VAL0|RINTEN0, mmio + INTEN0);
- writel(VAL2 | RDMD0, mmio + CMD0);
- spin_unlock_irqrestore(&lp->lock, flags);
+ if (rx_pkt_limit > 0) {
+ /* Receive descriptor is empty now */
+ spin_lock_irqsave(&lp->lock, flags);
+ __netif_rx_complete(dev, napi);
+ writel(VAL0|RINTEN0, mmio + INTEN0);
+ writel(VAL2 | RDMD0, mmio + CMD0);
+ spin_unlock_irqrestore(&lp->lock, flags);
+ }
rx_not_empty:
return num_rx_pkt;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C mux and device tree
Hi, Scott Scott Wood wrote: [added linuxppc-dev for a wider audience] Felix Radensky wrote: I run linux-2.6.26 on custom 460EX based board. This platform has PCA9548 I2C mux on I2C bus 0. I was wondering how can I describe the mux itself and devices behind it (e.g RTC and temperature sensors) in the device tree. Describe it as a node that is both an i2c client and an i2c controller. The Sun i2c binding says that i2c devices should have two reg cells, the first being the bus number within the controller, and the second being a shifted-left-by-one i2c bus address (as opposed to the one-cell non-shifted address we currently use, because the Sun binding wasn't known to us at the time). We could extend of_register_i2c_devices to understand two-cell addresses, and call it once for each sub-bus with the bus number as a parameter. That would be nice. I have everything working now, using platform data and i2c_register_board_info() in board setup code. But it would be great to have everything defined in device tree. If this is impossible at the moment, what other means exist to work with devices behind the mux ? I have found the pca954x patch and related virtual i2c patch and was able to integrate them intro my kernel. You'll have to update it to be a new-style i2c device, unless there's a newer version floating around that what a quick google search turned up. The latest version uses new-style i2c device, see http://www.mail-archive.com/i2c%40lm-sensors.org/msg01538.html Unfortunately it was not accepted. -Scott ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Blue G3: v2.3 kernel
Hello I am trying to contact Roger W Brown Can you be of any assistance? Thank you Thom Gascoigne ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote: [...] > > * How do you stop GPIOLIB from blindly approving requests to use > > pins marked X, without making it "controller-specific"? Btw, as for pins marked X... If the gpio controller has some register that specify which pins are not available to use as GPIOs, then just read that register, check its value and return -ENODEV from the .request() gpiolib callback. This is easily doable for QE/CPM gpio controllers (they have option registers), but nobody cares to check them. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> Can you _simply_ describe the problem you're trying to solve,
>> w/o that much emotions? Can you give examples of what
>> you've tried, and describe why you don't like it?
>
> I've not tried anything because I don't feel confident that the
> documentation or device tree examples explain the situation at
> all.
>
> Here's the basic premise;
>
> MPC5200B has three GPIO banks, one for standard, one for wakeups,
> one for timer GPIO. They're all implemented as 32-bit registers
> (but each bank does not necessarily have 32 pins escaping the
> chip). Several of the GPIO are multiplexed with other devices
> which can and does leave gaping holes of GPIO in the 32-bit
> register where anything up to 7 pins are given over to another
> device and therefore are no longer GPIO (this example is held
> up by the implementation of ethernet on the MPC5200B).
>
> Given GPIO functionality where you need more pins than a single
> device mux can offer, and some device muxing making those holes
> splitting up a contiguous allocation of pins that can be defined
> by a base pin number and a count of pins to assign, you may have
> to allocate several GPIO pins out of the register which are NOT
> contiguous.
>
> So in a 32-bit register, let's say 0 is a GPIO we don't need (or
> available but used for some other GPIO peripheral), and X is a
> GPIO muxed to another device (therefore not GPIO anymore) and 1
> is one we do want to use:
>
> 00011XXX111XXXXX0XX1
>
> (imagine them routed to a 12-pin connector with VCC and GND
> and 10 data pins. This may be an LCD display controller such
> as you can buy from Sparkfun or CrystalFontz, if you need a
> physical example)
>
> A bunch of things spring to mind:
>
> * How do you define a GPIO bank in a device tree, not a controller
Not a controller? What do you mean by "bank"? There is no such
thing. There are GPIO controllers, and _maybe_ _their_ banks of
GPIOs.
> but a grouping of pins which fit that pattern, of which there
> may be multiple groupings for multiple peripheral functions
Why do you need this, _exactly_? What problem this would solve? But
see below, this is still possible to implement.
> (for instance an LED controller, and an IR receiver, and a bitbang
> SPI implemented using these GPIO pins)?
So you need indirect GPIOs to use with devices? I.e. you want
to reference a GPIO header's GPIOs? Don't see any point in this
(other than just introducing the indirectness), but anyway this
will look like this:
cpu_pio: cpu-gpio-controller {
#gpio-cells = <2>;
gpio-controller;
};
header_pio: gpio-header {
/*
* This controller defines a group of GPIOs wired to a
* external header. The header enumerates pins from 1
* to 12. So gpio-spec "&header_pio 4 0" will reference
* the 5-th pin, no matter what underlaying GPIO controller
* provides it.
*/
#gpio-cells = <2>;
gpio-controller;
gpios = <&cpu_pio 12 0
&cpu_pio 21 0
&i2c_controller 2 0
...>
}
spi-controller {
/* We want to _not_ care what underlaying GPIOs there are,
* we reference the header pins instead. */
gpios = <&header_pio 0 0 /* MISO */
&header_pio 1 0 /* MOSI */
...
&header_pio 11 0 /* CS0 */
...>;
}
> * How do you stop GPIOLIB from blindly approving requests to use
> pins marked X, without making it "controller-specific"?
Driver can implement a .request() hook, and check for compatible
entries for this specific gpio controller. If this particular
gpio controller doesn't provide some pin it can return -ENODEV.
But I still wonder what problem exactly you're trying to solve
here? Prevent requesting reserved gpios? I don't see any point
in this, really.
> GPIOLIB
> can be as controller-specific as it likes, but having 20 different
> ways to define "X pins" or "available pins" complicates a
> device tree unnecessarily.
>
> (I've been implementing a "gpio-mask" property in MY device trees
> because I thought of this problem ages ago but just never had any
> reason to make use of it. But it's very controller-specific, and
> therefore pretty useless (and actually on other GPIO controllers
> which use a register-per-pin is not actually any use at all, but
> the question above remains!))
>
> * Since we're looking at an example where we interface a fairly
> complex device which is technically a bus, with a subordinate
> device which may or may not be probe-able, could you define
> that GPIO configuration in such a way that it is a device node
> of it's own, that the pins are marked for their purpose
>
> (on such an LCD example, 8 data pins in a group, 1 for r/w selection
No problem. Define bindings for "8 GPIOs data group".
/* 8bit Parallel
Re: GPIO - marking individual pins (not) available in device tree
Anton Vorontsov wrote: Can you _simply_ describe the problem you're trying to solve, w/o that much emotions? Can you give examples of what you've tried, and describe why you don't like it? I've not tried anything because I don't feel confident that the documentation or device tree examples explain the situation at all. Here's the basic premise; MPC5200B has three GPIO banks, one for standard, one for wakeups, one for timer GPIO. They're all implemented as 32-bit registers (but each bank does not necessarily have 32 pins escaping the chip). Several of the GPIO are multiplexed with other devices which can and does leave gaping holes of GPIO in the 32-bit register where anything up to 7 pins are given over to another device and therefore are no longer GPIO (this example is held up by the implementation of ethernet on the MPC5200B). Given GPIO functionality where you need more pins than a single device mux can offer, and some device muxing making those holes splitting up a contiguous allocation of pins that can be defined by a base pin number and a count of pins to assign, you may have to allocate several GPIO pins out of the register which are NOT contiguous. So in a 32-bit register, let's say 0 is a GPIO we don't need (or available but used for some other GPIO peripheral), and X is a GPIO muxed to another device (therefore not GPIO anymore) and 1 is one we do want to use: 00011XXX111XXXXX0XX1 (imagine them routed to a 12-pin connector with VCC and GND and 10 data pins. This may be an LCD display controller such as you can buy from Sparkfun or CrystalFontz, if you need a physical example) A bunch of things spring to mind: * How do you define a GPIO bank in a device tree, not a controller but a grouping of pins which fit that pattern, of which there may be multiple groupings for multiple peripheral functions (for instance an LED controller, and an IR receiver, and a bitbang SPI implemented using these GPIO pins)? * How do you stop GPIOLIB from blindly approving requests to use pins marked X, without making it "controller-specific"? GPIOLIB can be as controller-specific as it likes, but having 20 different ways to define "X pins" or "available pins" complicates a device tree unnecessarily. (I've been implementing a "gpio-mask" property in MY device trees because I thought of this problem ages ago but just never had any reason to make use of it. But it's very controller-specific, and therefore pretty useless (and actually on other GPIO controllers which use a register-per-pin is not actually any use at all, but the question above remains!)) * Since we're looking at an example where we interface a fairly complex device which is technically a bus, with a subordinate device which may or may not be probe-able, could you define that GPIO configuration in such a way that it is a device node of it's own, that the pins are marked for their purpose (on such an LCD example, 8 data pins in a group, 1 for r/w selection and 1 for data/control selection, it would be nice for the software to know which pin is which and, slightly unrelated, which way around the data pins went - MSB first or LSB first - from the device tree, as this is a BOARD LEVEL DESIGN DECISION which is what the device tree is meant to abstract - in the same way we define i2c controllers and clients?) * At the end of the day the GPIO device tree binding is barely 20 lines at the bottom of a file that has been superceded by the ePAPR standard now, so where do we stand on this anyway? (I will ask that same last question of the i2c guys, I have never seen the Linux i2c device binding in the tree - maybe I am not looking hard enough - and the Sun binding seems to be a secret that only special people are allowed to see) I don't feel the current spec actually takes this into account and the patch submission the other day from Wolfgang made me think that if a "base" register is the obvious solution to some problem, then it either can't be that clear to others (i.e. it is not just me being stupid) or it is simply not possible under the current binding. At the very least it needs documenting better, worst case is it needs a damn good rethink taking into account a set of controllers which comprise a representative number of GPIO controller types and potential uses. I actually saw the voltage controller framework go into 2.6.27 and they have designed it around the operation of two PMUI chips which are pretty much the industry standard. GPIO device tree does not seem to have gotten the same amount of attention. Yes, your idea, Mitch's discussion was great, I just don't think anything will get done about it (emotional moment) as usual. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fs_enet: Add missing irq free in error path.
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
Reposting to CC netdev list. (Thanks, Kumar)
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c
NEW/drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:54:31.0 -0700
+++ NEW/drivers/net/fs_enet/fs_enet-main.c 2008-10-24 17:57:03.0
-0700
@@ -795,6 +795,7 @@ static int fs_enet_open(struct net_devic
err = fs_init_phy(dev);
if (err) {
+ free_irq(fep->interrupt, dev);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return err;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Oct 27, 2008, at 2:49 PM, David Miller wrote: From: Kumar Gala <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 14:43:29 -0500 I haven't been following the netdev patches, but what about HW that does flow separation w/o multiple interrupts? We (Freescale) are working on such a device: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?fastpreview=1&code=P4080 It could probably tie into the software based flow seperation support. Will have to look at the code.. we might be able to fit in the HW irq scheme. We effective have a way of getting a per cpu interrupt for the flow. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Oct 27, 2008, at 3:27 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-10-27 at 08:43 -0500, Kumar Gala wrote: While we have the comment the code appears not to really follow it. We appear to write 1 << hard_smp_processor_id(). That code is called by each CPU that gets onlined and OR's it's bit in the mask. ahh, I see now. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C mux and device tree
[added linuxppc-dev for a wider audience] Felix Radensky wrote: I run linux-2.6.26 on custom 460EX based board. This platform has PCA9548 I2C mux on I2C bus 0. I was wondering how can I describe the mux itself and devices behind it (e.g RTC and temperature sensors) in the device tree. Describe it as a node that is both an i2c client and an i2c controller. The Sun i2c binding says that i2c devices should have two reg cells, the first being the bus number within the controller, and the second being a shifted-left-by-one i2c bus address (as opposed to the one-cell non-shifted address we currently use, because the Sun binding wasn't known to us at the time). We could extend of_register_i2c_devices to understand two-cell addresses, and call it once for each sub-bus with the bus number as a parameter. If this is impossible at the moment, what other means exist to work with devices behind the mux ? I have found the pca954x patch and related virtual i2c patch and was able to integrate them intro my kernel. You'll have to update it to be a new-style i2c device, unless there's a newer version floating around that what a quick google search turned up. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Mon, 2008-10-27 at 08:43 -0500, Kumar Gala wrote: > > While we have the comment the code appears not to really follow it. > We appear to write 1 << hard_smp_processor_id(). That code is called by each CPU that gets onlined and OR's it's bit in the mask. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rebasing master branch of galak/powerpc.git
On Mon, 2008-10-27 at 08:24 -0400, [EMAIL PROTECTED] wrote: > On Fri, Oct 24, 2008 at 11:01:45AM -0500, Kumar Gala wrote: > > Now that 2.6.28-rc1 is out I'm rebasing my master branch against it. > > Sorry for any pains this causes. > > Unless the powerpc tree moves up to .28-rc2 today-ish, I'll probably do > this for my tree as well so I can get some defconfig updates done. I'll move it forward today. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 01:56:03PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> The GPIO spec doesn't specify a controller bank. It says
>>
>> - - - -
>> gpio-specifier may encode: bank, pin position inside the bank,
>> whether pin is open-drain and whether pin is logically inverted.
>> - - - -
>>
>> May encode. Or may not encode. FYI, for most (all) SOC GPIO
>> controllers we don't use "bank" encoding in the gpio-specifier.
>
> This is exactly 100% precisely why I asked about it, there should at
> least be a binding for each specific controller where this is
> relevant, but since there is very little variation on "use pin 15
> please with these flags" (only what "pin 15" means is undefined
> so far, and left to the driver/controller variation) there must
> be a generic way to specify groups of IO pins which may not be
> consecutive.
>
> I don't get your example;
>
> > device {
> > gpios = <&gpio 0 0 &gpio 1 0 &gpio 2 0>;
> > }
> >
> > ^^ Three gpios, 0, 1, 2. Based on a compatible entry Linux can
> > translate them in any way.
> >
> > For example GPIO0 - bit 15, GPIO1 - bit 20, GPIO2 - bit 1.
>
> This kind of defeats the object. While the pin numbering may well
> be board-specific, it makes sense to maintain it as it relates to
> offsets into a register or offsets into a bank of registers the
> same way that interrupt mappings on the MPC5200B are ripped out of a
> table in the MPC5200B documentation.
>
> What the above example does is give a completely arbitrary
> number which only maps to a real pin or offset *inside the driver*
> meaning 10 boards with the same chip all have to have different
> drivers, gpio_chip libraries to allocate the pins - the driver
> to note which pin is for which purpose, and gpiolib to make sure
> some driver accessing them has not been loaded twice.
>
> Right?
>
> Even if I have my Efika sitting here I want to share my GPIO
> library code between it and the lite5200b - be that making the
> "sleep switch" code look for a certain gpio pin marker in the
> device tree so it knows what to allocate (so the number isn't
> hardcoded into the driver as a compile-time switch or a check
> for the /soc node model)
>
> The current model seems to me like it is not getting any benefit
> whatsoever from being defined in a device tree, in fact it is
> making certain GPIO functionality go back to the hardcoded-per-board
> stuff we used to have in arch/ppc.
>
> This is just proving the point that nobody is forward-thinking
> about this stuff, and is just implementing hack over hack over
> hack to get something to work, and refining it later. We're
> already running kernels which need to be specially built for
> specially built U-Boot versions, special options for the dtc,
> and device trees which change every other week. Specifying the
> bare minimum here for the functionality a single user uses
> defeats the object of having a descriptive device tree.
Sorry, your mail doesn't make any sense to me.
That makes me think that you you didn't understand the whole
GPIO thing... Or maybe I misunderstood you completely.
Can you _simply_ describe the problem you're trying to solve,
w/o that much emotions? Can you give examples of what
you've tried, and describe why you don't like it?
Am I understand correctly that some 52xx boards have an
external GPIOs header, and you need to describe it, and
maybe write some driver to do something with a device called
_GPIO header_ with a _pin_ named "wakeup" that connects to
a CPU _pin_ that pinmuxed to a _GPIO_ that can wakeup the CPU?
I remember I purposed the solution to this problem, what was
wrong with it?
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
From: Kumar Gala <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 14:43:29 -0500 > I haven't been following the netdev patches, but what about HW that does flow > separation w/o multiple interrupts? > > We (Freescale) are working on such a device: > > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?fastpreview=1&code=P4080 It could probably tie into the software based flow seperation support. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Oct 27, 2008, at 1:28 PM, David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 11:36:21 -0600 David Miller wrote: From: Kevin Diggs <[EMAIL PROTECTED]> Date: Sat, 25 Oct 2008 15:53:46 -0700 What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this thing supposed to be able to spread irq between its cpus? Networking interrupts should lock onto a single CPU, unconditionally. That's the optimal way to handle networking interrupts, especially with multiqueue chips. What about something like the Cavium Octeon, where we have 16 cores but a single core isn't powerful enough to keep up with a gigE device? Hello, we either have hardware that does flow seperation and has multiple RX queues going to multiple MSI-X interrupts or we do flow seperation in software (work in progress patches were posted for that about a month ago, maybe something final will land in 2.6.29) Just moving the interrupt around when not doing flow seperation is as suboptimal as you can possibly get. You'll get out of order packet processing within the same flow, TCP will retransmit when the reordering gets deep enough, and then you're totally screwed performance wise. I haven't been following the netdev patches, but what about HW that does flow separation w/o multiple interrupts? We (Freescale) are working on such a device: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?fastpreview=1&code=P4080 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 13:10:55 -0600 > David Miller wrote: > > From: "Chris Friesen" <[EMAIL PROTECTED]> > > > Hello, we either have hardware that does flow seperation and has multiple > > RX queues going to multiple MSI-X interrupts or we do flow seperation in > > software (work in progress patches were posted for that about a month ago, > > maybe something final will land in 2.6.29) > > Are there any plans for a mechanism to allow the kernel to figure > out (or be told) what packets cpu-affined tasks are interested in > and route the interrupts appropriately? No, not at all. Now there are plans to allow the user to add classification rules into the chip for specific flows, on hardware that supports this, via ethtool. > Ideally I agree with you. In this particular case however the > hardware is capable of doing flow separation, but the vendor driver > doesn't support it (and isn't in mainline). Packet rates are high > enough that a single core cannot keep up, but are low enough that > they can be handled by multiple cores without reordering if > interrupt mitigation is not used. Your driver is weak and doesn't support the hardware correctly, and you want to put the onus on everyone else with sane hardware and drivers? > It's not an ideal situation, but we're sort of stuck unless we do > custom driver work. Wouldn't want you to get your hands dirty or anything like that now, would we? :-))) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
David Miller wrote: From: "Chris Friesen" <[EMAIL PROTECTED]> What about something like the Cavium Octeon, where we have 16 cores but a single core isn't powerful enough to keep up with a gigE device? Hello, we either have hardware that does flow seperation and has multiple RX queues going to multiple MSI-X interrupts or we do flow seperation in software (work in progress patches were posted for that about a month ago, maybe something final will land in 2.6.29) Are there any plans for a mechanism to allow the kernel to figure out (or be told) what packets cpu-affined tasks are interested in and route the interrupts appropriately? Just moving the interrupt around when not doing flow seperation is as suboptimal as you can possibly get. You'll get out of order packet processing within the same flow, TCP will retransmit when the reordering gets deep enough, and then you're totally screwed performance wise. Ideally I agree with you. In this particular case however the hardware is capable of doing flow separation, but the vendor driver doesn't support it (and isn't in mainline). Packet rates are high enough that a single core cannot keep up, but are low enough that they can be handled by multiple cores without reordering if interrupt mitigation is not used. It's not an ideal situation, but we're sort of stuck unless we do custom driver work. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V3][powerpc] GPIO: Adding new Xilinx driver
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
V2 - Updated based on Anton's comments
V3 - Cleaned up Kconfig badness in patch generation and added Grant's signoff
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 235
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 7f2ee27..48f49d9 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -65,6 +65,14 @@ config GPIO_SYSFS
# put expanders in the right section, in alphabetical order
+comment "Memory mapped GPIO expanders:"
+
+config GPIO_XILINX
+ bool "Xilinx GPIO support"
+ depends on PPC_OF
+ help
+ Say yes here to support the Xilinx FPGA GPIO device
+
comment "I2C GPIO expanders:"
config GPIO_MAX732X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6aafdeb..49ac64e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
+obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index 000..3c1177a
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,235 @@
+/*
+ * Xilinx gpio driver
+ *
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register Offset Definitions */
+#define XGPIO_DATA_OFFSET (0x0) /* Data register */
+#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
+
+struct xgpio_instance {
+ struct of_mm_gpio_chip mmchip;
+ u32 gpio_state; /* GPIO state shadow register */
+ u32 gpio_dir; /* GPIO direction shadow register */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+};
+
+/**
+ * xgpio_get - Read the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function reads the specified signal of the GPIO device. It returns 0 if
+ * the signal clear, 1 if signal is set or negative value on error.
+ */
+static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return (in_be32(mm_gc->regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
+}
+
+/**
+ * xgpio_set - Write the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ * @val:Value to be written to specified signal.
+ *
+ * This function writes the specified value in to the specified signal of the
+ * GPIO device.
+ */
+static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(&chip->gpio_lock, flags);
+
+ /* Write to GPIO signal and set its direction to output */
+ if (val)
+ chip->gpio_state |= 1 << gpio;
+ else
+ chip->gpio_state &= ~(1 << gpio);
+ out_be32(mm_gc->regs + XGPIO_DATA_OFFSET, chip->gpio_state);
+
+ spin_unlock_irqrestore(&chip->gpio_lock, flags);
+}
+
+/**
+ * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function sets the direction of specified GPIO signal as input.
+ * It returns 0 if direction of GPIO signals is set as input otherwise it
+ * returns negative error value.
+ */
+static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(&chip->gpio_lock, flags);
+
+ /* Set the GPIO bit in shadow register and set direction as input */
+ chip->gpio_dir |= (1 << gpio
Re: GPIO - marking individual pins (not) available in device tree
Anton Vorontsov wrote:
The GPIO spec doesn't specify a controller bank. It says
- - - -
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
- - - -
May encode. Or may not encode. FYI, for most (all) SOC GPIO
controllers we don't use "bank" encoding in the gpio-specifier.
This is exactly 100% precisely why I asked about it, there should at
least be a binding for each specific controller where this is
relevant, but since there is very little variation on "use pin 15
please with these flags" (only what "pin 15" means is undefined
so far, and left to the driver/controller variation) there must
be a generic way to specify groups of IO pins which may not be
consecutive.
I don't get your example;
> device {
>gpios = <&gpio 0 0 &gpio 1 0 &gpio 2 0>;
> }
>
> ^^ Three gpios, 0, 1, 2. Based on a compatible entry Linux can
> translate them in any way.
>
> For example GPIO0 - bit 15, GPIO1 - bit 20, GPIO2 - bit 1.
This kind of defeats the object. While the pin numbering may well
be board-specific, it makes sense to maintain it as it relates to
offsets into a register or offsets into a bank of registers the
same way that interrupt mappings on the MPC5200B are ripped out of a
table in the MPC5200B documentation.
What the above example does is give a completely arbitrary
number which only maps to a real pin or offset *inside the driver*
meaning 10 boards with the same chip all have to have different
drivers, gpio_chip libraries to allocate the pins - the driver
to note which pin is for which purpose, and gpiolib to make sure
some driver accessing them has not been loaded twice.
Right?
Even if I have my Efika sitting here I want to share my GPIO
library code between it and the lite5200b - be that making the
"sleep switch" code look for a certain gpio pin marker in the
device tree so it knows what to allocate (so the number isn't
hardcoded into the driver as a compile-time switch or a check
for the /soc node model)
The current model seems to me like it is not getting any benefit
whatsoever from being defined in a device tree, in fact it is
making certain GPIO functionality go back to the hardcoded-per-board
stuff we used to have in arch/ppc.
This is just proving the point that nobody is forward-thinking
about this stuff, and is just implementing hack over hack over
hack to get something to work, and refining it later. We're
already running kernels which need to be specially built for
specially built U-Boot versions, special options for the dtc,
and device trees which change every other week. Specifying the
bare minimum here for the functionality a single user uses
defeats the object of having a descriptive device tree.
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fix typo in flow control config option
Josh Boyer wrote:
The recent build fix for ibm_newemac has a typo in the config
option #ifdef used for disabling flow control. This corrects
it to the proper Kconfig option name.
Reported-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 2ee2622..901212a 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2605,7 +2605,7 @@ static int __devinit emac_init_config(struct
emac_instance *dev)
of_device_is_compatible(np, "ibm,emac-440gr"))
dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
if (of_device_is_compatible(np, "ibm,emac-405ez")) {
-#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CONTROL
+#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL
dev->features |= EMAC_FTR_NO_FLOW_CONTROL_40x;
#else
printk(KERN_ERR "%s: Flow control not disabled!\n",
applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: Add hugepage detection
Thomas Klein wrote: All kernel memory which is used for kernel/hardware data transfer must be registered with firmware using "memory regions". 16GB hugepages may not be part of a memory region due to firmware restrictions. This patch modifies the walk_memory_resource callback fn to filter hugepages and add only standard memory to the busmap which is later on used for MR registration. Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> --- This reworked patch accounts for comments I got. It's based on davem's net-2.6.git. applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][for 2.6.28] powerpc/mpic: Add support for MPICs that only support a single CPU destination
>From 20a2290553a1921a13449f9b7c597bcc76ec2c03 Mon Sep 17 00:00:00 2001
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 09:08:11 -0500
Subject: [PATCH] powerpc/mpic: Add support for MPICs that only support a single
CPU destination
The Freescale implementation of MPIC only allows a single CPU destination
for non-IPI interrupts. We add a flag to the mpic_init to distinquish
these variants of MPIC. Additionally, we will flag a warning if the
user tries to set the affinity on such an interrupts to more than one
CPU.
This is to deal with the fact that the default smp affinity was
changed by commit 18404756765c713a0be4eb1082920c04822ce588.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Ben, please review and see if this is an acceptable solution to the fact
that FSL mpic's can't deal with more than one CPU destination bit being
set. If so please queue up and forward onto linus for 2.6.28.
- k
arch/powerpc/include/asm/mpic.h |2 ++
arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 ++-
arch/powerpc/platforms/86xx/pic.c|3 ++-
arch/powerpc/sysdev/mpic.c | 15 +++
4 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index 34d9ac4..c2ccca5 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -355,6 +355,8 @@ struct mpic
#define MPIC_NO_BIAS 0x0400
/* Ignore NIRQS as reported by FRR */
#define MPIC_BROKEN_FRR_NIRQS 0x0800
+/* Destination only supports a single CPU at a time */
+#define MPIC_SINGLE_DEST_CPU 0x1000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 483b65c..613bf8c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -78,7 +78,8 @@ void __init mpc85xx_ds_pic_init(void)
mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
- MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
+ MPIC_SINGLE_DEST_CPU,
0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
of_node_put(np);
diff --git a/arch/powerpc/platforms/86xx/pic.c
b/arch/powerpc/platforms/86xx/pic.c
index 8881c5d..668275d 100644
--- a/arch/powerpc/platforms/86xx/pic.c
+++ b/arch/powerpc/platforms/86xx/pic.c
@@ -44,7 +44,8 @@ void __init mpc86xx_init_irq(void)
mpic = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
- MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
+ MPIC_SINGLE_DEST_CPU,
0, 256, " MPIC ");
of_node_put(np);
BUG_ON(mpic == NULL);
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8e3478c..b91a736 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -781,6 +781,16 @@ void mpic_set_affinity(unsigned int irq, cpumask_t cpumask)
cpus_and(tmp, cpumask, cpu_online_map);
+ if ((mpic->flags & MPIC_SINGLE_DEST_CPU) && (cpus_weight(tmp) != 1)) {
+ int first_cpu = first_cpu(tmp);
+
+ printk(KERN_WARNING "mpic: attempting to set cpu affinity to "
+ "more than one cpu, setting to CPU %d\n", first_cpu);
+ cpus_clear(tmp);
+ cpu_set(first_cpu, tmp);
+ irq_desc[irq].affinity = tmp;
+ }
+
mpic_irq_write(src, MPIC_INFO(IRQ_DESTINATION),
mpic_physmask(cpus_addr(tmp)[0]));
}
@@ -920,6 +930,8 @@ static int mpic_host_map(struct irq_host *h, unsigned int
virq,
handle_percpu_irq);
return 0;
}
+ if (mpic->flags & MPIC_SINGLE_DEST_CPU)
+ irq_set_affinity(virq, irq_default_affinity);
#endif /* CONFIG_SMP */
if (hw >= mpic->irq_count)
@@ -1037,6 +1049,9 @@ struct mpic * __init mpic_alloc(struct device_node *node,
#ifdef CONFIG_SMP
mpic->hc_ipi = mpic_ipi_chip;
mpic->hc_ipi.typename = name;
+
+ if (flags & MPIC_SINGLE_DEST_CPU)
+ irq_default_affinity = CPU_MASK_CPU0;
#endif /* CONFIG_SMP */
mpic->flags = flags;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>
>> Um.. I can't actually follow what you're getting at there, sorry.
>
> Imagine in your head that you have a GPIO controller that has a
> 32-bit register potentially controlling 32 pins on the chip.
>
> Imagine that rather than being able to allocate 6 GPIO pins
> *right next to each other* in the register and saying that
> you start at "pin" 15 and use the next 6 "pins", you have to
> spread it around and use pin 1, pin 8, pin 9, pin 11, pin 15,
> pin 30, to make up this peripheral.
Isn't this some implementation detail of a gpio controller?
gpio: [EMAIL PROTECTED] {
#gpio-cells = <2>;
compatible = "gpio-bank-with-funny-mapping"; <- notice this
reg = <123 4>;
gpio-controller;
}
device {
gpios = <&gpio 0 0 &gpio 1 0 &gpio 2 0>;
}
^^ Three gpios, 0, 1, 2. Based on a compatible entry Linux can
translate them in any way.
For example GPIO0 - bit 15, GPIO1 - bit 20, GPIO2 - bit 1.
> As far as I can tell there is no way at all to specify a set of
> GPIO pins which are NOT consecutive because the current GPIO
> spec stops after specifying a controller bank (the 32-bit
> register).
The GPIO spec doesn't specify a controller bank. It says
- - - -
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
- - - -
May encode. Or may not encode. FYI, for most (all) SOC GPIO
controllers we don't use "bank" encoding in the gpio-specifier.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
From: "Chris Friesen" <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 11:36:21 -0600 > David Miller wrote: > > From: Kevin Diggs <[EMAIL PROTECTED]> > > Date: Sat, 25 Oct 2008 15:53:46 -0700 > > > >> What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this > >> thing supposed to be able to spread irq between its cpus? > > Networking interrupts should lock onto a single CPU, unconditionally. > > That's the optimal way to handle networking interrupts, especially > > with multiqueue chips. > > What about something like the Cavium Octeon, where we have 16 cores but a > single core isn't powerful enough to keep up with a gigE device? Hello, we either have hardware that does flow seperation and has multiple RX queues going to multiple MSI-X interrupts or we do flow seperation in software (work in progress patches were posted for that about a month ago, maybe something final will land in 2.6.29) Just moving the interrupt around when not doing flow seperation is as suboptimal as you can possibly get. You'll get out of order packet processing within the same flow, TCP will retransmit when the reordering gets deep enough, and then you're totally screwed performance wise. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function
On 24.10.08 11:47:29, Carl Love wrote: > > The size of the pm_signal_local array should be equal to the > number of SPUs being configured in the call. Currently, the > array is of size 4 (NR_PHYS_CTRS) but being indexed by a for > loop from 0 to 7 (NUM_SPUS_PER_NODE). > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> I applied your patch to oprofile/oprofile-for-tip. Thanks Carl. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Matt Sealey wrote: Scott Wood wrote: It's deprecated *in the context of flat device trees*. Anything not using flat device trees is out-of-scope with respect to ePAPR. Isn't the beauty of a device tree that every firmware no matter what type can present it in whatever form it chooses, but still be describing the same hardware in the same way? When run-time services are not involved, yes. device_type was used by 1275 in the context of run-time services, which we don't have, so we didn't copy that property over (except for memory and cpu, to avoid gratuitous divergence). I'm curious, is it the remit of the ePAPR TSC to publish and act as a registration authority for device tree bindings for specific SoCs or is that devolved to the SoC maker itself (be they a member of Power.org or not) and, more prudent, two other questions; where are Freescale and IBM publishing these if it is their responsibility, are things like the mysterious i2c binding going to be published under this TSC? There has been talk about setting up such a repository, but I'm not sure what the status of it is. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Scott Wood wrote: They did always work. The real sore points here are device bindings and a grand total of nothing changed between OF and now with that. The assertion in ePAPR that device_type is deprecated and ignored because ePAPR doesn't support FCode is naive at best. It's deprecated *in the context of flat device trees*. Anything not using flat device trees is out-of-scope with respect to ePAPR. Isn't the beauty of a device tree that every firmware no matter what type can present it in whatever form it chooses, but still be describing the same hardware in the same way? Designing a tree for OF and one for U-Boot should be an absolutely identical process, internal firmware methodologies notwithstanding be it pure Forth in Firmworks, C API in Codegen, or output of dtc for U-Boot, the exact same tree should be output, device_type and all, within reason. I don't think "it's not real Open Firmware" is a valid reason. Not as valid as "our firmware doesn't support this hardware yet so we can't probe or initialize, only describe the bus", for example (USB on Efika is filled out, USB on U-Boot for Lite5200B is not). I'm curious, is it the remit of the ePAPR TSC to publish and act as a registration authority for device tree bindings for specific SoCs or is that devolved to the SoC maker itself (be they a member of Power.org or not) and, more prudent, two other questions; where are Freescale and IBM publishing these if it is their responsibility, are things like the mysterious i2c binding going to be published under this TSC? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
David Miller wrote: From: Kevin Diggs <[EMAIL PROTECTED]> Date: Sat, 25 Oct 2008 15:53:46 -0700 What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this thing supposed to be able to spread irq between its cpus? Networking interrupts should lock onto a single CPU, unconditionally. That's the optimal way to handle networking interrupts, especially with multiqueue chips. What about something like the Cavium Octeon, where we have 16 cores but a single core isn't powerful enough to keep up with a gigE device? Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Matt Sealey wrote: I say ANY firmware environment because at the end of the day what methods the OF implements, or even if the firmware (like a U-Boot modification) "lies" about it being device_type serial or device_type network, Linux completely f**ks over the client interface at the first opportunity it gets and does not call ANY appreciable method anyway. That's Linux's choice; what does that have to do with how the firmware expresses the functionality it provides? So, it is not a lie to say it's a certain device_type, It's not a lie because Linux doesn't care that it's a lie? and I really do focus here on the between-the-lines reading of the OF spec where devices which ARE useful for booting, console and probing (for instance marking detected disks as "block", ethernet as "network", serial consoles as "serial" and displays and keyboards are present in the tree if they are present on the machine) is more relevant here than the Open Firmware client interface methods which Linux is steadfastly resolved never to use anyway. If you're not going to use the method interface, then what *do* you use device_type for? So let's just take the basic premise of the device_type and not the literal truth of it (hey, the world wasn't created in 7 days after all, who'd have thunk?) and use it to the advantage of the Linux kernel instead of ditching it as legacy. What advantage would that be? Define "they", "used", and "firmware environment". Obviously u-boot may use the serial port for its console, but there's no method interface defined by the device tree, nor is there any firmware resident at all after starting the kernel. However it is a serial port, and when it boots it says "input: serial" and "output: serial" - or it could be netconsole or so. Or even screen and keyboard! These are put into /chosen/stdin and /chosen/stdout when the system is booted with the device tree. And how, exactly, do /chosen/stdin and /chosen/stdout depend on device_type? Should a platform be extremely specific and check compatible properties for every kind of serial port it could ever support Of course it should check compatible -- how else would it know how to drive the thing? (including PCI, ISA/LPC, and otherwise connected GPIO implementations or crazy designs) just so that it can carry over the firmware choices reported in the device tree to the booting system, or should it simply be looking for those generic device classes? And what do you propose it do with a generic "serial" in the absence of a method interface? Just assume it's ns16550? A simple way to check what is in use and what basic sort of peripheral it is, without knowing the ultimate specifics of the device (since you would not be in a driver, early_init is too early of course in the examples, but I could probably think of a bunch of othe reasons you'd want to check some of the /chosen nodes or make a quick check if the device was purposed by the firmware for some reason) -EPARSE 2. 1275 did not appear to be actively maintained and updated. But, it did not suddenly break in the last 14 years, did it? New hardware came along that is not described. Details that fall out of the use of flat trees are not addressed (no ihandles, phandles as properties, etc). ePAPR doesn't resolve a single thing we didn't already know, The primary intent was to codify existing practice. Don't get me started on how useless and ineffectual Power.org technical subcommittees are.. there is no reason why PAPR and ePAPR couldn't have been the same specification. When you start thinking about U-Boot with RTAS or the IBM Hypervisor this is going to kick you in the backside. Agreed; that's more of a political issue than a technical one. 3. It standardized the flattened device tree interface, which did not exist in 1275. This is about all it did but it is not like we've not been using flattened device trees for the past 2 or so years *anyway*. ...in Linux and u-boot. ePAPR gives us a self-contained document that we can point other firmware and OS developers to. They did always work. The real sore points here are device bindings and a grand total of nothing changed between OF and now with that. The assertion in ePAPR that device_type is deprecated and ignored because ePAPR doesn't support FCode is naive at best. It's deprecated *in the context of flat device trees*. Anything not using flat device trees is out-of-scope with respect to ePAPR. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Scott Wood wrote: Matt Sealey wrote: Nobody is saying that device_type should not be used in real OF when an appropriate method interface exists. What we're saying is that flat device trees, which are incapable of providing a method interface, should not lie and claim that they have one. As for "ANY firmware environment", I'd suggest that any new method interfaces, where backwards compatibility isn't an issue, use some relevant compatible rather than device_type, so that multiple supported interfaces can be listed. What do you have against vendor namespaces (don't make the device binding guess which firmware type it's on) and multiple interfaces per node? I say ANY firmware environment because at the end of the day what methods the OF implements, or even if the firmware (like a U-Boot modification) "lies" about it being device_type serial or device_type network, Linux completely f**ks over the client interface at the first opportunity it gets and does not call ANY appreciable method anyway. So, it is not a lie to say it's a certain device_type, and I really do focus here on the between-the-lines reading of the OF spec where devices which ARE useful for booting, console and probing (for instance marking detected disks as "block", ethernet as "network", serial consoles as "serial" and displays and keyboards are present in the tree if they are present on the machine) is more relevant here than the Open Firmware client interface methods which Linux is steadfastly resolved never to use anyway. Other operating systems might be a little less pleased about the lack of methods but we've been pushing them to ignore the CI for a long, long time as it causes way too many problems with differences in MMU mapping (even in virtual-mode) when booting the system, to try and access a disk through the client interface or use a polled ethernet driver which has to go through an egregious context switch to load significant amounts of data. So let's just take the basic premise of the device_type and not the literal truth of it (hey, the world wasn't created in 7 days after all, who'd have thunk?) and use it to the advantage of the Linux kernel instead of ditching it as legacy. Define "they", "used", and "firmware environment". Obviously u-boot may use the serial port for its console, but there's no method interface defined by the device tree, nor is there any firmware resident at all after starting the kernel. However it is a serial port, and when it boots it says "input: serial" and "output: serial" - or it could be netconsole or so. Or even screen and keyboard! These are put into /chosen/stdin and /chosen/stdout when the system is booted with the device tree. Should a platform be extremely specific and check compatible properties for every kind of serial port it could ever support (including PCI, ISA/LPC, and otherwise connected GPIO implementations or crazy designs) just so that it can carry over the firmware choices reported in the device tree to the booting system, or should it simply be looking for those generic device classes? A simple way to check what is in use and what basic sort of peripheral it is, without knowing the ultimate specifics of the device (since you would not be in a driver, early_init is too early of course in the examples, but I could probably think of a bunch of othe reasons you'd want to check some of the /chosen nodes or make a quick check if the device was purposed by the firmware for some reason) It fixes three primary concerns: 1. The 1275 documentation is scattered in many places, some of which are not easily accessible to the general public (just look at the i2c mess). To be honest I didn't know i2c had ever been defined at all, so I see your point there. 2. 1275 did not appear to be actively maintained and updated. But, it did not suddenly break in the last 14 years, did it? This simply exposes the endemic problem of Linux developers subscribing to the Not Invented Here philosophy and making subtle yet intrusive changes to suit themselves and brighten their name in lights while, in the end, ignoring their own statements to whit the benefits and reasons why they wanted to change something. I am still kind of sore that the policy swung from "the firmware is responsible" to "we will accept any crazy patch for prom_init.c which will fix up a device even though there is an easy way to fix it from the firmware side and not clutter Linux, and even though the patch doesn't ACTUALLY work" and many other 180's in the history of the device tree specifications and the support Linux implements. ePAPR doesn't resolve a single thing we didn't already know, and considering it was written by the IBM and Freescale engineers who implemented and maintain the support and the firmware.. I wonder how much thought went into it besides how to format it as a PDF. Don't get me started on how useless and ineffectual Power.org technical subcommittees are.. there is no reason why
Re: [PATCH][V2] [powerpc] GPIO: Adding new Xilinx driver
On Mon, Oct 27, 2008 at 10:39 AM, John Linn <[EMAIL PROTECTED]> wrote: > This driver supports the Xilinx XPS GPIO IP core which has the typical > GPIO features. > > Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]> > Signed-off-by: John Linn <[EMAIL PROTECTED]> > --- > V2 - Updated based on Anton's comments > > drivers/gpio/Kconfig | 15 ++-- > drivers/gpio/Makefile |1 + > drivers/gpio/xilinx_gpio.c | 235 > > 3 files changed, 244 insertions(+), 7 deletions(-) > create mode 100644 drivers/gpio/xilinx_gpio.c > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > index 7f2ee27..12a8006 100644 > --- a/drivers/gpio/Kconfig > +++ b/drivers/gpio/Kconfig > @@ -127,13 +135,6 @@ config GPIO_PCF857X > This driver provides an in-kernel interface to those GPIOs using > platform-neutral GPIO calls. > > -config GPIO_TWL4030 > - tristate "TWL4030, TWL5030, and TPS659x0 GPIOs" > - depends on TWL4030_CORE > - help > - Say yes here to access the GPIO signals of various multi-function > - power management chips from Texas Instruments. > - Looks like you've got some colateral damage in here. Otherwise looks right to me. When you repost, please add my Signed-off-by line between yours and Kiran's since I did a bunch of hacking on this driver too. Also, make use you post it to the LKML. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][V2] [powerpc] GPIO: Adding new Xilinx driver
This driver supports the Xilinx XPS GPIO IP core which has the typical
GPIO features.
Signed-off-by: Kiran Sutariya <[EMAIL PROTECTED]>
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
V2 - Updated based on Anton's comments
drivers/gpio/Kconfig | 15 ++--
drivers/gpio/Makefile |1 +
drivers/gpio/xilinx_gpio.c | 235
3 files changed, 244 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpio/xilinx_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 7f2ee27..12a8006 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -65,6 +65,14 @@ config GPIO_SYSFS
# put expanders in the right section, in alphabetical order
+comment "Memory mapped GPIO expanders:"
+
+config GPIO_XILINX
+ bool "Xilinx GPIO support"
+ depends on PPC_OF
+ help
+ Say yes here to support the Xilinx FPGA GPIO device
+
comment "I2C GPIO expanders:"
config GPIO_MAX732X
@@ -127,13 +135,6 @@ config GPIO_PCF857X
This driver provides an in-kernel interface to those GPIOs using
platform-neutral GPIO calls.
-config GPIO_TWL4030
- tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
- depends on TWL4030_CORE
- help
- Say yes here to access the GPIO signals of various multi-function
- power management chips from Texas Instruments.
-
comment "PCI GPIO expanders:"
config GPIO_BT8XX
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6aafdeb..49ac64e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_GPIO_MCP23S08) += mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
+obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
new file mode 100644
index 000..3c1177a
--- /dev/null
+++ b/drivers/gpio/xilinx_gpio.c
@@ -0,0 +1,235 @@
+/*
+ * Xilinx gpio driver
+ *
+ * Copyright 2008 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register Offset Definitions */
+#define XGPIO_DATA_OFFSET (0x0) /* Data register */
+#define XGPIO_TRI_OFFSET(0x4) /* I/O direction register */
+
+struct xgpio_instance {
+ struct of_mm_gpio_chip mmchip;
+ u32 gpio_state; /* GPIO state shadow register */
+ u32 gpio_dir; /* GPIO direction shadow register */
+ spinlock_t gpio_lock; /* Lock used for synchronization */
+};
+
+/**
+ * xgpio_get - Read the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function reads the specified signal of the GPIO device. It returns 0 if
+ * the signal clear, 1 if signal is set or negative value on error.
+ */
+static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return (in_be32(mm_gc->regs + XGPIO_DATA_OFFSET) >> gpio) & 1;
+}
+
+/**
+ * xgpio_set - Write the specified signal of the GPIO device.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ * @val:Value to be written to specified signal.
+ *
+ * This function writes the specified value in to the specified signal of the
+ * GPIO device.
+ */
+static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ unsigned long flags;
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct xgpio_instance *chip =
+ container_of(mm_gc, struct xgpio_instance, mmchip);
+
+ spin_lock_irqsave(&chip->gpio_lock, flags);
+
+ /* Write to GPIO signal and set its direction to output */
+ if (val)
+ chip->gpio_state |= 1 << gpio;
+ else
+ chip->gpio_state &= ~(1 << gpio);
+ out_be32(mm_gc->regs + XGPIO_DATA_OFFSET, chip->gpio_state);
+
+ spin_unlock_irqrestore(&chip->gpio_lock, flags);
+}
+
+/**
+ * xgpio_dir_in - Set the direction of the specified GPIO signal as input.
+ * @gc: Pointer to gpio_chip device structure.
+ * @gpio: GPIO signal number.
+ *
+ * This function sets the direction of specified GPIO signal as input.
+ * It returns 0 if direction of GPIO signals is set as input otherwise it
+ * returns negative error value.
+ */
+static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ unsigned long
Re: GPIO - marking individual pins (not) available in device tree
Matt Sealey wrote: I'm all for it being legacy and optional but marking ethernet ports as network, and serial ports as serial, is a wonderfully good idea especially if they were used in ANY firmware environment to bring up the console, drag in the boot files, or provide a framebuffer display. Nobody is saying that device_type should not be used in real OF when an appropriate method interface exists. What we're saying is that flat device trees, which are incapable of providing a method interface, should not lie and claim that they have one. As for "ANY firmware environment", I'd suggest that any new method interfaces, where backwards compatibility isn't an issue, use some relevant compatible rather than device_type, so that multiple supported interfaces can be listed. What do you have against vendor namespaces (don't make the device binding guess which firmware type it's on) and multiple interfaces per node? matches the stated device_type. However, flattened trees clearly can't provide the method interface, and so shouldn't declare the device_type. Even if they are used in the firmware environment for console, booting or probing? :D Define "they", "used", and "firmware environment". Obviously u-boot may use the serial port for its console, but there's no method interface defined by the device tree, nor is there any firmware resident at all after starting the kernel. In practice, we do suggest including device_type in certain, limited, circumstances precisely because there are a whole bunch of buggy drivers out there which match (at least partly) on device_type. > We don't want to break these gratuitously, Oh that's rich. If you were that concerned you'd rip the device_type out and fix all the drivers in a huge patch, like everyone else does when they change the ABI. This isn't internal ABI, it's an external interface with firmware. driver matching. Hence the current policy. I might say that the policy on device trees has changed by the month for the last 2 years and ePAPR didn't fix down a single concern that wasn't already documented in the original IEEE 1275 specification. It fixes three primary concerns: 1. The 1275 documentation is scattered in many places, some of which are not easily accessible to the general public (just look at the i2c mess). 2. 1275 did not appear to be actively maintained and updated. 3. It standardized the flattened device tree interface, which did not exist in 1275. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
David Gibson wrote: On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote: Mitch Bradley wrote: device_type in 1275 defines the runtime method interface. It's *not* for declaring the general class of the device, although it often matches that in practice. It *is* for declaring the general class of the device, even if it's purpose is to make it known that it implements all the required methods and therefore acts in a certain predefined way when those methods are used; it's not a necessary property but it is a USEFUL property: ~~ It is not necessary for every node to have a “device_type” property. If a particular device is not useful for any Open Firmware function (e.g., booting, console, probing) then it need not have a device type. For example, Open Firmware has no use for a FAX modem, so such a device does not need a device type. However, there is no restriction preventing it from having a device type so long as its device type is not the same as one of the standard types (i.e., a device should not claim to be something that it is not). ~~ I'm all for it being legacy and optional but marking ethernet ports as network, and serial ports as serial, is a wonderfully good idea especially if they were used in ANY firmware environment to bring up the console, drag in the boot files, or provide a framebuffer display. It's quite possible that a generic framebuffer driver be written that only needs to know that it is a "display", read a property to find out where the memory starts, and gain some rudimentary information about the dimensions. Oh, wait, it already exists, it's offb.c (if you strip out the ATI hacks, it'll work on *a n y* framebuffer that is defined as such, and needn't have any specific compatible to do it) Drivers which attempt to use it this way are buggy. I'm more concerned about code that lives specifically outside of the driver itself - examples; http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg11772.html http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg11773.html When you're about to take control of the system and do your board setup, it is usually a great idea to use what the firmware was using, you do not want to go through and find out that you were using a serial console but Linux has inited a display and expects a keyboard on a framebuffer console, because that is what "most people get" when they boot Linux. (I will concede that using "serial" as the VGA textmode console is, while a semi-accurate abstraction of an ANSI-capable terminal with no framebuffer, is kind of braindead when it comes to giving the OS accurate information about which devices are in use) matches the stated device_type. However, flattened trees clearly can't provide the method interface, and so shouldn't declare the device_type. Even if they are used in the firmware environment for console, booting or probing? :D In practice, we do suggest including device_type in certain, limited, circumstances precisely because there are a whole bunch of buggy drivers out there which match (at least partly) on device_type. > We don't want to break these gratuitously, Oh that's rich. If you were that concerned you'd rip the device_type out and fix all the drivers in a huge patch, like everyone else does when they change the ABI. driver matching. Hence the current policy. I might say that the policy on device trees has changed by the month for the last 2 years and ePAPR didn't fix down a single concern that wasn't already documented in the original IEEE 1275 specification. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
David Gibson wrote: Um.. I can't actually follow what you're getting at there, sorry. Imagine in your head that you have a GPIO controller that has a 32-bit register potentially controlling 32 pins on the chip. Imagine that rather than being able to allocate 6 GPIO pins *right next to each other* in the register and saying that you start at "pin" 15 and use the next 6 "pins", you have to spread it around and use pin 1, pin 8, pin 9, pin 11, pin 15, pin 30, to make up this peripheral. As far as I can tell there is no way at all to specify a set of GPIO pins which are NOT consecutive because the current GPIO spec stops after specifying a controller bank (the 32-bit register). -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Add missing irq free in fs_enet error path.
On Oct 24, 2008, at 8:03 PM, Mike Ditto wrote:
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
I just noticed this file has already been touched in -rc1 so here is
the
patch again, adjusted accordingly.
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c NEW/
drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:54:31.0 -0700
+++ NEW/drivers/net/fs_enet/fs_enet-main.c 2008-10-24
17:57:03.0 -0700
@@ -795,6 +795,7 @@ static int fs_enet_open(struct net_devic
err = fs_init_phy(dev);
if (err) {
+ free_irq(fep->interrupt, dev);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
return err;
Please copy Jeff Garizk and the netdev list as such patches normally
go though that path.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Add new CPU feature: CPU_FTR_UNALIGNED_LD_STD
On Oct 27, 2008, at 5:43 AM, Mark Nelson wrote: Add a new CPU feature bit, CPU_FTR_UNALIGNED_LD_STD, to be added to the 64bit powerpc chips that can do unaligned load double and store double (and not take a performance hit from it). This is added to Power6 and Cell and will be used in an upcoming patch to do the alignment in memcpy() only on CPUs that require it. Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/cputable.h |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) not that I have anything against this patch but is there anything we can do about the CPU_FTR_ usage for one of things like this? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Oct 26, 2008, at 1:33 AM, Benjamin Herrenschmidt wrote: On Sat, 2008-10-25 at 21:04 -0700, David Miller wrote: But back to my original wonder, since I've always tipped off of this generic IRQ layer cpu mask, when was it ever defaulting to zero and causing the behvaior your powerpc guys actually want? :-) Well, I'm not sure what Kumar wants. Most powerpc SMP setups actually want to spread interrupts to all CPUs, and those who can't tend to just not implement set_affinity... So Kumar must have a special case of MPIC usage here on FSL platforms. In any case, the platform limitations should be dealt with there or the user could break it by manipulating affinity via /proc anyway. By yeah, I do expect default affinity to be all CPUs and in fact, I even have an -OLD- comment in the code that says /* let the mpic know we want intrs. default affinitya is 0x ... While we have the comment the code appears not to really follow it. We appear to write 1 << hard_smp_processor_id(). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rebasing master branch of galak/powerpc.git
On Fri, Oct 24, 2008 at 11:01:45AM -0500, Kumar Gala wrote: > Now that 2.6.28-rc1 is out I'm rebasing my master branch against it. > Sorry for any pains this causes. Unless the powerpc tree moves up to .28-rc2 today-ish, I'll probably do this for my tree as well so I can get some defconfig updates done. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Update 64bit memcpy() using CPU_FTR_UNALIGNED_LD_STD
Update memcpy() to add two new feature sections: one for aligning the destination before copying and one for copying using aligned load and store doubles. These new feature sections will only affect Power6 and Cell because the CPU feature bit was only added to these two processors. Power6 gets its best performance in memcpy() when aligning neither the source nor the destination, while Cell gets its best performance when just the destination is aligned. But in order to save on CPU feature bits we can use the previously added CPU_FTR_CP_USE_DCBTZ feature bit to differentiate between Power6 and Cell (because CPU_FTR_CP_USE_DCBTZ was added to Cell but not Power6). The first feature section acts to nop out the branch that takes us to the code that aligns us to an eight byte boundary for the destination. We only want to nop out this branch on Power6. So the ALT_FTR_SECTION_END() for this feature section creates a test mask of the two feature bits ORed together and provides an expected result of just CPU_FTR_UNALIGNED_LD_STD, thus we nop out the branch if we're on a CPU that has CPU_FTR_UNALIGNED_LD_STD set and CPU_FTR_CP_USE_DCBTZ unset. For the second feature section added, if we're on a CPU that has the CPU_FTR_UNALIGNED_LD_STD bit set then we don't want to do the copy with aligned loads and stores (and the appropriate shifting left and right instructions), so we want to nop out the branch to .Lsrc_unaligned. The andi. used for this branch is moved to just above the branch because this allows us to nop out both instructions with just one feature section which gives us better performance and doesn't hurt readability which two separate feature sections did. Moving the andi. to just above the branch doesn't have any noticeable negative effect on the remaining 64bit processors (the ones that didn't have this feature bit added). On Cell this simple modification results in an improvement to measured memcpy() bandwidth of up to 50% in the hot cache case and up to 15% in the cold cache case On Power6 we get memory bandwidth results that are up to three times faster in the hot cache case and up to 50% faster in the cold cache case. CPU_FTR_CP_USE_DCBTZ was added in commit 2a9294369bd020db89bfdf78b84c3615b39a5c84. To say that Cell gets its best performance in memcpy() with just the destination aligned is true but only for the reason that the indirect shift and rotate instructions, sld and srd, are microcoded on Cell. This means that either the destination or the source can be aligned, but not both, and seeing as we get better performance with the destination aligned we choose this option. While we're at it make a one line change from cmpldi r1,... to cmpldi cr1,... for consistency. Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> --- arch/powerpc/lib/memcpy_64.S | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) Index: upstream/arch/powerpc/lib/memcpy_64.S === --- upstream.orig/arch/powerpc/lib/memcpy_64.S +++ upstream/arch/powerpc/lib/memcpy_64.S @@ -18,11 +18,23 @@ _GLOBAL(memcpy) andi. r6,r6,7 dcbt0,r4 blt cr1,.Lshort_copy +/* Below we want to nop out the bne if we're on a CPU that has the + CPU_FTR_UNALIGNED_LD_STD bit set and the CPU_FTR_CP_USE_DCBTZ bit + cleared. + At the time of writing the only CPU that has this combination of bits + set is Power6. */ +BEGIN_FTR_SECTION + nop +FTR_SECTION_ELSE bne .Ldst_unaligned +ALT_FTR_SECTION_END(CPU_FTR_UNALIGNED_LD_STD | CPU_FTR_CP_USE_DCBTZ, \ +CPU_FTR_UNALIGNED_LD_STD) .Ldst_aligned: - andi. r0,r4,7 addir3,r3,-16 +BEGIN_FTR_SECTION + andi. r0,r4,7 bne .Lsrc_unaligned +END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_LD_STD) srdir7,r5,4 ld r9,0(r4) addir4,r4,-8 @@ -131,7 +143,7 @@ _GLOBAL(memcpy) PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7 subfr5,r6,r5 li r7,0 - cmpldi r1,r5,16 + cmpldi cr1,r5,16 bf cr7*4+3,1f lbz r0,0(r4) stb r0,0(r3) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Add new CPU feature: CPU_FTR_UNALIGNED_LD_STD
Add a new CPU feature bit, CPU_FTR_UNALIGNED_LD_STD, to be added to the 64bit powerpc chips that can do unaligned load double and store double (and not take a performance hit from it). This is added to Power6 and Cell and will be used in an upcoming patch to do the alignment in memcpy() only on CPUs that require it. Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/cputable.h |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index: upstream/arch/powerpc/include/asm/cputable.h === --- upstream.orig/arch/powerpc/include/asm/cputable.h +++ upstream/arch/powerpc/include/asm/cputable.h @@ -194,6 +194,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_VSXLONG_ASM_CONST(0x0010) #define CPU_FTR_SAOLONG_ASM_CONST(0x0020) #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040) +#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080) #ifndef __ASSEMBLY__ @@ -404,7 +405,7 @@ extern const char *powerpc_base_platform CPU_FTR_MMCRA | CPU_FTR_SMT | \ CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \ CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ - CPU_FTR_DSCR) + CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD) #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_MMCRA | CPU_FTR_SMT | \ @@ -415,7 +416,8 @@ extern const char *powerpc_base_platform CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \ CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | \ - CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ) + CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ | \ + CPU_FTR_UNALIGNED_LD_STD) #define CPU_FTRS_PA6T (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Add hugepage detection
All kernel memory which is used for kernel/hardware data transfer must be
registered
with firmware using "memory regions". 16GB hugepages may not be part of a
memory region
due to firmware restrictions.
This patch modifies the walk_memory_resource callback fn to filter hugepages
and add
only standard memory to the busmap which is later on used for MR registration.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
This reworked patch accounts for comments I got. It's based on davem's
net-2.6.git.
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.27/drivers/net/ehea/ehea.h2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-10-27 09:27:46.0
+0100
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0094"
+#define DRV_VERSION"EHEA_0095"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.c
patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.c2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-10-27 09:27:46.0
+0100
@@ -632,10 +632,13 @@ static void ehea_rebuild_busmap(void)
}
}
-static int ehea_update_busmap(unsigned long pfn, unsigned long pgnum, int add)
+static int ehea_update_busmap(unsigned long pfn, unsigned long nr_pages, int
add)
{
unsigned long i, start_section, end_section;
+ if (!nr_pages)
+ return 0;
+
if (!ehea_bmap) {
ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
if (!ehea_bmap)
@@ -643,7 +646,7 @@ static int ehea_update_busmap(unsigned l
}
start_section = (pfn * PAGE_SIZE) / EHEA_SECTSIZE;
- end_section = start_section + ((pgnum * PAGE_SIZE) / EHEA_SECTSIZE);
+ end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE);
/* Mark entries as valid or invalid only; address is assigned later */
for (i = start_section; i < end_section; i++) {
u64 flag;
@@ -692,10 +695,54 @@ int ehea_rem_sect_bmap(unsigned long pfn
return ret;
}
-static int ehea_create_busmap_callback(unsigned long pfn,
- unsigned long nr_pages, void *arg)
+static int ehea_is_hugepage(unsigned long pfn)
+{
+ int page_order;
+
+ if (pfn & EHEA_HUGEPAGE_PFN_MASK)
+ return 0;
+
+ page_order = compound_order(pfn_to_page(pfn));
+ if (page_order + PAGE_SHIFT != EHEA_HUGEPAGESHIFT)
+ return 0;
+
+ return 1;
+}
+
+static int ehea_create_busmap_callback(unsigned long initial_pfn,
+ unsigned long total_nr_pages, void *arg)
{
- return ehea_update_busmap(pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
+ int ret;
+ unsigned long pfn, start_pfn, end_pfn, nr_pages;
+
+ if ((total_nr_pages * PAGE_SIZE) < EHEA_HUGEPAGE_SIZE)
+ return ehea_update_busmap(initial_pfn, total_nr_pages,
+ EHEA_BUSMAP_ADD_SECT);
+
+ /* Given chunk is >= 16GB -> check for hugepages */
+ start_pfn = initial_pfn;
+ end_pfn = initial_pfn + total_nr_pages;
+ pfn = start_pfn;
+
+ while (pfn < end_pfn) {
+ if (ehea_is_hugepage(pfn)) {
+ /* Add mem found in front of the hugepage */
+ nr_pages = pfn - start_pfn;
+ ret = ehea_update_busmap(start_pfn, nr_pages,
+EHEA_BUSMAP_ADD_SECT);
+ if (ret)
+ return ret;
+
+ /* Skip the hugepage */
+ pfn += (EHEA_HUGEPAGE_SIZE / PAGE_SIZE);
+ start_pfn = pfn;
+ } else
+ pfn += (EHEA_SECTSIZE / PAGE_SIZE);
+ }
+
+ /* Add mem found behind the hugepage(s) */
+ nr_pages = pfn - start_pfn;
+ return ehea_update_busmap(start_pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
}
int ehea_create_busmap(void)
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.h
patched_kernel/drivers/net/ehea/ehea_qmr.h
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.h2008-10-24 09:29:19.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.h 2008-10-27 09:27:46.0
+0100
@@ -40,6 +40,9 @@
#define EHEA_PAGESIZE (1UL << EHEA_PAGESHIFT)
#define EHEA_SECTSIZE (1UL << 24)
#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
+#define EHEA_HUGEPAGESHIFT 34
+#define EHEA_HUGEPAGE_SIZE (1UL << EHEA_HUGEPAGESHIFT)
+#define EHEA_HUGEPAGE_PFN_MASK ((EHEA_HUGEPAGE_SIZE - 1) >> PAGE_SHIFT)
#if ((1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE)
#error eHEA module cannot work if kernel sectionsize < ehea sectionsize
Re: [PATCH] ehea: Add hugepage detection
Dave,
thanks for your valuable comments - see mine below. I'll send a reworked patch
asap.
Thomas
On Friday 24 October 2008 08:55:37 pm you wrote:
> On Fri, 2008-10-24 at 13:07 +0200, Thomas Klein wrote:
> > 16GB hugepages may not be part of a memory region (firmware restriction).
> > This patch
> > modifies the walk_memory_resource callback fn to filter hugepages and add
> > only standard
> > memory to the busmap which is later on used for MR registration.
>
> Does this support a case where a userspace app is reading network
> packets into a 16GB page backed area? I think you need to elaborate on
> what kind of memory you need to have registered in these memory regions.
> It's hard to review what you've done here otherwise.
>
> > --- linux-2.6.27/drivers/net/ehea/ehea_qmr.c2008-10-24
> > 09:29:19.0 +0200
> > +++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-10-24
> > 09:45:15.0 +0200
> > @@ -636,6 +636,9 @@ static int ehea_update_busmap(unsigned l
> > {
> > unsigned long i, start_section, end_section;
> >
> > + if (!pgnum)
> > + return 0;
>
> This probably needs a comment. It's not obvious what it is doing.
I decided to just rename the var to nr_pages as it is used in all other
busmap-related functions in our code. That makes the condition check quite
obvious.
>
> > if (!ehea_bmap) {
> > ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
> > if (!ehea_bmap)
> > @@ -692,10 +695,47 @@ int ehea_rem_sect_bmap(unsigned long pfn
> > return ret;
> > }
> >
> > -static int ehea_create_busmap_callback(unsigned long pfn,
> > - unsigned long nr_pages, void *arg)
> > +static int ehea_is_hugepage(unsigned long pfn)
> > +{
> > + return pfn << PAGE_SHIFT) & (EHEA_HUGEPAGE_SIZE - 1)) == 0)
> > + && (compound_order(pfn_to_page(pfn)) + PAGE_SHIFT
> > + == EHEA_HUGEPAGESHIFT) );
> > +}
>
> Whoa. That's dense. Can you actually read that in less than 5 minutes?
> Seriously.
Thanks for this comment. I totally agree - and I'm happy to aerate it a bit.
I had been urged to make it dense during our internal review ;-)
>
> I'm not sure what else you use EHEA_HUGEPAGE_SIZE for or if this gets
> duplicated, but this would look nicer if you just had a:
>
> #define EHEA_HUGEPAGE_PFN_MASK ((EHEA_HUGEPAGE_SIZE - 1) >> PAGE_SHIFT)
>
> if (pfn & EHEA_HUGEPAGE_PFN_MASK)
> return 0;
>
> Or, with no new macro:
>
> if ((pfn << PAGE_SHIFT) & (EHEA_HUGEPAGE_SIZE - 1) != 0)
> return 0;
>
> page_order = compound_order(pfn_to_page(pfn));
> if (page_order + PAGE_SHIFT != EHEA_HUGEPAGESHIFT)
> return 0;
> return 1;
> }
>
> Please break that up into something that is truly readable. gcc will
> generate the exact same code.
>
> > +static int ehea_create_busmap_callback(unsigned long initial_pfn,
> > + unsigned long total_nr_pages, void *arg)
> > {
> > - return ehea_update_busmap(pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
> > + int ret;
> > + unsigned long pfn, start_pfn, end_pfn, nr_pages;
> > +
> > + if ((total_nr_pages * PAGE_SIZE) < EHEA_HUGEPAGE_SIZE)
> > + return ehea_update_busmap(initial_pfn, total_nr_pages,
> > + EHEA_BUSMAP_ADD_SECT);
> > +
> > + /* Given chunk is >= 16GB -> check for hugepages */
> > + start_pfn = initial_pfn;
> > + end_pfn = initial_pfn + total_nr_pages;
> > + pfn = start_pfn;
> > +
> > + while (pfn < end_pfn) {
> > + if (ehea_is_hugepage(pfn)) {
> > + /* Add mem found in front of the hugepage */
> > + nr_pages = pfn - start_pfn;
> > + ret = ehea_update_busmap(start_pfn, nr_pages,
> > +EHEA_BUSMAP_ADD_SECT);
> > + if (ret)
> > + return ret;
> > +
> > + /* Skip the hugepage */
> > + pfn += (EHEA_HUGEPAGE_SIZE / PAGE_SIZE);
> > + start_pfn = pfn;
> > + } else
> > + pfn += (EHEA_SECTSIZE / PAGE_SIZE);
> > + }
> > +
> > + /* Add mem found behind the hugepage(s) */
> > + nr_pages = pfn - start_pfn;
> > + return ehea_update_busmap(start_pfn, nr_pages, EHEA_BUSMAP_ADD_SECT);
> > }
> >
> > int ehea_create_busmap(void)
> > diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.h
> > patched_kernel/drivers/net/ehea/ehea_qmr.h
> > --- linux-2.6.27/drivers/net/ehea/ehea_qmr.h2008-10-24
> > 09:29:19.0 +0200
> > +++ patched_kernel/drivers/net/ehea/ehea_qmr.h 2008-10-24
> > 09:45:15.0 +0200
> > @@ -40,6 +40,8 @@
> > #define EHEA_PAGESIZE (1UL << EHEA_PAGESHIFT)
> > #define EHEA_SECTSIZE (1UL << 24)
> > #define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
> > +#define EHEA_HUGEPAGESHIFT
[PATCH] OF-device: Don't overwrite numa_node in device registration
Currently, the numa_node of OF-devices will be overwritten during
device_register, which simply sets the node to -1. On cell machines,
this means that devices can't find their IOMMU, which is referenced
through the device's numa node.
Set the numa node for OF devices with no parent, and use the
lower-level device_initialize and device_add functions, so that the
node is preserved.
We can remove the call to set_dev_node in of_device_alloc, as it
will be overwritten during register.
Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]>
---
Ben: please apply pending davem's approval - this fixes a
regression in 2.6.28
---
arch/powerpc/kernel/of_device.c |1 -
drivers/of/device.c | 11 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/of_device.c b/arch/powerpc/kernel/of_device.c
index 93ae5b1..f3c9cae 100644
--- a/arch/powerpc/kernel/of_device.c
+++ b/arch/powerpc/kernel/of_device.c
@@ -78,7 +78,6 @@ struct of_device *of_device_alloc(struct device_node *np,
dev->dev.parent = parent;
dev->dev.release = of_release_dev;
dev->dev.archdata.of_node = np;
- set_dev_node(&dev->dev, of_node_to_nid(np));
if (bus_id)
strlcpy(dev->dev.bus_id, bus_id, BUS_ID_SIZE);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 51e5214..224ae6b 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,7 +105,16 @@ EXPORT_SYMBOL(of_release_dev);
int of_device_register(struct of_device *ofdev)
{
BUG_ON(ofdev->node == NULL);
- return device_register(&ofdev->dev);
+
+ device_initialize(&ofdev->dev);
+
+ /* device_add will assume that this device is on the same node as
+* the parent. If there is no parent defined, set the node
+* explicitly */
+ if (!ofdev->dev.parent)
+ set_dev_node(&ofdev->dev, of_node_to_nid(ofdev->node));
+
+ return device_add(&ofdev->dev);
}
EXPORT_SYMBOL(of_device_register);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
