* [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-19 5:22 UTC (permalink / raw)
To: linux-i2c, linuxppc-dev
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads. With this patch, it is possible to do an i2c_transfer() with
additional i2c_msg's following the I2C_M_RD messages.
It still needs to be resolved if it is possible to fix this issue
by removing the STOP condition after reads in a robust way.
Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
---
drivers/i2c/busses/i2c-mpc.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4af5c09..0199f9a 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
}
for (i = 0; ret >= 0 && i < num; i++) {
+ int restart = i;
pmsg = &msgs[i];
dev_dbg(i2c->dev,
"Doing %s %d bytes to 0x%02x - %d of %d messages\n",
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
+ if (i > 0 && ((pmsg - 1)->flags & I2C_M_RD))
+ restart = 0;
if (pmsg->flags & I2C_M_RD)
ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
else
ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: FUJITA Tomonori @ 2009-05-19 5:27 UTC (permalink / raw)
To: beckyb; +Cc: fujita.tomonori, linuxppc-dev, linux-kernel
In-Reply-To: <1242340949-16369-2-git-send-email-beckyb@kernel.crashing.org>
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -0500
Becky Bruce <beckyb@kernel.crashing.org> wrote:
> This patch includes the basic infrastructure to use swiotlb
> bounce buffering on 32-bit powerpc. It is not yet enabled on
> any platforms. Probably the most interesting bit is the
> addition of addr_needs_map to dma_ops - we need this as
> a dma_op because the decision of whether or not an addr
> can be mapped by a device is device-specific.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/Kconfig | 12 ++-
> arch/powerpc/include/asm/dma-mapping.h | 11 ++
> arch/powerpc/include/asm/swiotlb.h | 27 +++++
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/dma-swiotlb.c | 163 ++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/dma.c | 2 +-
> arch/powerpc/kernel/setup_32.c | 6 +
> arch/powerpc/kernel/setup_64.c | 6 +
> 8 files changed, 226 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/include/asm/swiotlb.h
> create mode 100644 arch/powerpc/kernel/dma-swiotlb.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a0d1146..54e519a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -296,9 +296,19 @@ config IOMMU_VMERGE
> config IOMMU_HELPER
> def_bool PPC64
>
> +config SWIOTLB
> + bool "SWIOTLB support"
> + default n
> + select IOMMU_HELPER
> + ---help---
> + Support for IO bounce buffering for systems without an IOMMU.
> + This allows us to DMA to the full physical address space on
> + platforms where the size of a physical address is larger
> + than the bus address. Not all platforms support this.
> +
> config PPC_NEED_DMA_SYNC_OPS
> def_bool y
> - depends on NOT_COHERENT_CACHE
> + depends on (NOT_COHERENT_CACHE || SWIOTLB)
>
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index c69f2b5..71bbc17 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -15,9 +15,18 @@
> #include <linux/scatterlist.h>
> #include <linux/dma-attrs.h>
> #include <asm/io.h>
> +#include <asm/swiotlb.h>
>
> #define DMA_ERROR_CODE (~(dma_addr_t)0x0)
>
> +/* Some dma direct funcs must be visible for use in other dma_ops */
> +extern void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flag);
> +extern void dma_direct_free_coherent(struct device *dev, size_t size,
> + void *vaddr, dma_addr_t dma_handle);
> +
> +extern unsigned long get_dma_direct_offset(struct device *dev);
> +
> #ifdef CONFIG_NOT_COHERENT_CACHE
> /*
> * DMA-consistent mapping functions for PowerPCs that don't support
> @@ -76,6 +85,8 @@ struct dma_mapping_ops {
> dma_addr_t dma_address, size_t size,
> enum dma_data_direction direction,
> struct dma_attrs *attrs);
> + int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
> + size_t size);
> #ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
> void (*sync_single_range_for_cpu)(struct device *hwdev,
> dma_addr_t dma_handle, unsigned long offset,
> diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/include/asm/swiotlb.h
> new file mode 100644
> index 0000000..30891d6
> --- /dev/null
> +++ b/arch/powerpc/include/asm/swiotlb.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#ifndef __ASM_SWIOTLB_H
> +#define __ASM_SWIOTLB_H
> +
> +#include <linux/swiotlb.h>
> +
> +extern struct dma_mapping_ops swiotlb_dma_ops;
> +extern struct dma_mapping_ops swiotlb_pci_dma_ops;
> +
> +int swiotlb_arch_address_needs_mapping(struct device *, dma_addr_t,
> + size_t size);
> +
> +static inline void dma_mark_clean(void *addr, size_t size) {}
> +
> +extern unsigned int ppc_swiotlb_enable;
> +int __init swiotlb_setup_bus_notifier(void);
> +
> +#endif /* __ASM_SWIOTLB_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 71901fb..34c0a95 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_KPROBES) += kprobes.o
> obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
> obj-$(CONFIG_STACKTRACE) += stacktrace.o
> +obj-$(CONFIG_SWIOTLB) += dma-swiotlb.o
>
> pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
> obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
> diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
> new file mode 100644
> index 0000000..68ccf11
> --- /dev/null
> +++ b/arch/powerpc/kernel/dma-swiotlb.c
> @@ -0,0 +1,163 @@
> +/*
> + * Contains routines needed to support swiotlb for ppc.
> + *
> + * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/pfn.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/pci.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/swiotlb.h>
> +#include <asm/dma.h>
> +#include <asm/abs_addr.h>
> +
> +int swiotlb __read_mostly;
> +unsigned int ppc_swiotlb_enable;
> +
> +void *swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t addr)
> +{
> + unsigned long pfn = PFN_DOWN(swiotlb_bus_to_phys(hwdev, addr));
> + void *pageaddr = page_address(pfn_to_page(pfn));
> +
> + if (pageaddr != NULL)
> + return pageaddr + (addr % PAGE_SIZE);
> + return NULL;
> +}
> +
> +dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
> +{
> + return paddr + get_dma_direct_offset(hwdev);
> +}
> +
> +phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
> +
> +{
> + return baddr - get_dma_direct_offset(hwdev);
> +}
> +
> +/*
> + * Determine if an address needs bounce buffering via swiotlb.
> + * Going forward I expect the swiotlb code to generalize on using
> + * a dma_ops->addr_needs_map, and this function will move from here to the
> + * generic swiotlb code.
> + */
> +int
> +swiotlb_arch_address_needs_mapping(struct device *hwdev, dma_addr_t addr,
> + size_t size)
> +{
> + struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
> +
> + BUG_ON(!dma_ops);
> + return dma_ops->addr_needs_map(hwdev, addr, size);
> +}
> +
> +/*
> + * Determine if an address is reachable by a pci device, or if we must bounce.
> + */
> +static int
> +swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
> +{
> + u64 mask = dma_get_mask(hwdev);
> + dma_addr_t max;
> + struct pci_controller *hose;
> + struct pci_dev *pdev = to_pci_dev(hwdev);
> +
> + hose = pci_bus_to_host(pdev->bus);
> + max = hose->dma_window_base_cur + hose->dma_window_size;
> +
> + /* check that we're within mapped pci window space */
> + if ((addr + size > max) | (addr < hose->dma_window_base_cur))
> + return 1;
> +
> + return !is_buffer_dma_capable(mask, addr, size);
> +}
> +
> +static int
> +swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
> +{
> + return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
> +}
I think that swiotlb_pci_addr_needs_map and swiotlb_addr_needs_map
don't need swiotlb_arch_range_needs_mapping() since
- swiotlb_arch_range_needs_mapping() is always used with
swiotlb_arch_address_needs_mapping().
- swiotlb_arch_address_needs_mapping() uses is_buffer_dma_capable()
and powerpc doesn't overwrite swiotlb_arch_address_needs_mapping()
Do I miss something?
Anyway, we need to fix swiotlb checking code to if an area is
DMA-capable or not.
swiotlb_arch_address_needs_mapping() calls is_buffer_dma_capable() in
dma-mapping.h but it should not. It should live in an arch-specific
place such as arch's dma-mapping.h or something since
is_buffer_dma_capable() is arch-specific. I didn't know that
is_buffer_dma_capable() is arch-specific when I added it to the
generic place.
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev, dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
But I guess the bad thing is that we can't the arch abstraction due to
dom0 support.
^ permalink raw reply
* Please pull from 'next' branch
From: Kumar Gala @ 2009-05-19 5:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
This is based on benh/next and fixes the cpm cruft patch to drop the
removal of IMAP_ADDR from cpm1 so we still build on 8xx. Will deal with
that when we get into the merge window for 2.6.31.
- k
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/ecm.txt | 64 +
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 3
Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 5
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 +
arch/powerpc/boot/dts/gef_ppc9a.dts | 14
arch/powerpc/boot/dts/gef_sbc310.dts | 14
arch/powerpc/boot/dts/gef_sbc610.dts | 14
arch/powerpc/boot/dts/ksi8560.dts | 13
arch/powerpc/boot/dts/mpc832x_mds.dts | 3
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3
arch/powerpc/boot/dts/mpc8349emitx.dts | 2
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 3
arch/powerpc/boot/dts/mpc836x_rdk.dts | 2
arch/powerpc/boot/dts/mpc8377_mds.dts | 1
arch/powerpc/boot/dts/mpc8378_mds.dts | 1
arch/powerpc/boot/dts/mpc8379_mds.dts | 1
arch/powerpc/boot/dts/mpc8536ds.dts | 18
arch/powerpc/boot/dts/mpc8540ads.dts | 15
arch/powerpc/boot/dts/mpc8541cds.dts | 16
arch/powerpc/boot/dts/mpc8544ds.dts | 18
arch/powerpc/boot/dts/mpc8548cds.dts | 17
arch/powerpc/boot/dts/mpc8555cds.dts | 16
arch/powerpc/boot/dts/mpc8560ads.dts | 15
arch/powerpc/boot/dts/mpc8568mds.dts | 51 +
arch/powerpc/boot/dts/mpc8569mds.dts | 583 +++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 17
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 39 -
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 16
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 609 ++++++++++++++++
arch/powerpc/boot/dts/p2020ds.dts | 704 +++++++++++++++++++
arch/powerpc/boot/dts/sbc8349.dts | 1
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/dts/sbc8560.dts | 15
arch/powerpc/boot/dts/sbc8641d.dts | 16
arch/powerpc/boot/dts/socrates.dts | 15
arch/powerpc/boot/dts/stx_gp3_8560.dts | 15
arch/powerpc/boot/dts/tqm8540.dts | 15
arch/powerpc/boot/dts/tqm8541.dts | 15
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 16
arch/powerpc/boot/dts/tqm8548.dts | 16
arch/powerpc/boot/dts/tqm8555.dts | 15
arch/powerpc/boot/dts/tqm8560.dts | 15
arch/powerpc/include/asm/cpm2.h | 4
arch/powerpc/include/asm/mpc86xx.h | 33
arch/powerpc/include/asm/pci-bridge.h | 6
arch/powerpc/include/asm/qe.h | 21
arch/powerpc/oprofile/op_model_fsl_emb.c | 14
arch/powerpc/platforms/82xx/pq2ads.h | 13
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 43 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 52 +
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1
arch/powerpc/platforms/86xx/gef_sbc310.c | 1
arch/powerpc/platforms/86xx/gef_sbc610.c | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8
arch/powerpc/platforms/86xx/sbc8641d.c | 1
arch/powerpc/platforms/8xx/mpc885ads.h | 4
arch/powerpc/platforms/fsl_uli1575.c | 24
arch/powerpc/sysdev/cpm2.c | 2
arch/powerpc/sysdev/fsl_msi.c | 9
arch/powerpc/sysdev/fsl_pci.c | 132 +++
arch/powerpc/sysdev/fsl_pci.h | 6
arch/powerpc/sysdev/fsl_rio.c | 15
arch/powerpc/sysdev/fsl_soc.c | 14
arch/powerpc/sysdev/qe_lib/qe.c | 75 +-
drivers/dma/fsldma.c | 13
drivers/net/ucc_geth.c | 24
drivers/net/ucc_geth.h | 4
drivers/of/base.c | 1
drivers/rapidio/rio-scan.c | 6
include/linux/pci_ids.h | 4
78 files changed, 2810 insertions(+), 272 deletions(-)
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (2):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Kumar Gala (18):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
powerpc/fsl: Update FSL esdhc binding
powerpc/85xx: Add P2020DS board support
powerpc/fsl: Setup PCI inbound window based on actual amount of memory
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (1):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
^ permalink raw reply
* Re: fs_enet build breakage
From: Kumar Gala @ 2009-05-19 6:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, Kumar Gala, linuxppc-dev list
In-Reply-To: <1242683444.16901.1.camel@pasglop>
On May 18, 2009, at 4:50 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote:
>>> I'm pretty sure the driver changes to address this are in dave's
>> net-
>>> next tree.
>>
>> Won't this break git bisect?
>>
>> Not to mention anyone trying to use your tree now...
>
> Right, though if you have the commit ID in DaveM tree, I can work with
> him to sort out that driver, for example by having the same commit in
> my tree.
As discussed on IRC, its easier to modify the commit that cause the
issue to drop removing IMAP_ADDR for cpm1 devices for now. I'll
generate a separate patch for us to deal w/during the merge window
for .31
- k
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Piotr Zięcik @ 2009-05-19 7:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <4A1170B0.5080203@grandegger.com>
Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisa=B3(a):
> > I have simple question about bus speed setting support. Existing
> > implementation uses default safe speed if there is no 'clock-frequency'
> > property in i2c node. Comments in code suggest that this behaviour is
> > left for backward compatibility only. Should I make the 'clock-frequenc=
y'
> > property mandatory for a new type of I2C controller (MPC5121) ?
>
> I don't think so, for the same backward compatibility reason as for the
> other boards. But the DTS file might be changed to use clock-frequency.
In my opinion implementing "backward compatilility" for MPC5121 is not good
idea. MPC5121 I2C support is completly new thing in mainline. Simply, there=
is=20
no DTS with which I have to be compatible. Adding backward compatibility
with nothing may be confusing.
=2D-=20
Best Regards,
Piotr Zi=EAcik
^ permalink raw reply
* Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Piotr Zięcik @ 2009-05-19 8:03 UTC (permalink / raw)
To: Hongjun Chen; +Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk
In-Reply-To: <200905190937411866001@freescale.com>
Tuesday 19 May 2009 03:37:47 Hongjun Chen wrote:
> Since you have reuse most part of our BSP, why should you reinvent wheel
> for MPC512x DMA? We have one ready DMA driver, which has been used by AC9=
7,
> ATA, VIU etc.
>
Answer is simple. The old one does not fit Linux DMA API. New one uses=20
existing infrastructure which makes DMA engine aviable for existing consume=
rs
in Linux kernel. For example network stack. Support for I/O <-> memory=20
transfers will be added when more consumers arrive.
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Wolfgang Grandegger @ 2009-05-19 8:10 UTC (permalink / raw)
To: Piotr Zięcik; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <200905190947.22972.kosmo@semihalf.com>
Piotr Zięcik wrote:
> Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisał(a):
>>> I have simple question about bus speed setting support. Existing
>>> implementation uses default safe speed if there is no 'clock-frequency'
>>> property in i2c node. Comments in code suggest that this behaviour is
>>> left for backward compatibility only. Should I make the 'clock-frequency'
>>> property mandatory for a new type of I2C controller (MPC5121) ?
>> I don't think so, for the same backward compatibility reason as for the
>> other boards. But the DTS file might be changed to use clock-frequency.
>
> In my opinion implementing "backward compatilility" for MPC5121 is not good
> idea. MPC5121 I2C support is completly new thing in mainline. Simply, there is
> no DTS with which I have to be compatible. Adding backward compatibility
> with nothing may be confusing.
There is a port for the MPC5121 in mainline since 2.6.25 including DTS
file:
http://lxr.linux.no/linux+v2.6.25/arch/powerpc/boot/dts/mpc5121ads.dts
If it was really usable or even used is another question. But it's fine
for me be more restrictive, e.g. print a warning when save values are
selected.
Wolfgang.
^ permalink raw reply
* [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Martyn Welch @ 2009-05-19 9:40 UTC (permalink / raw)
To: galak, linuxppc-dev
Mappings for temperature sensors (adt7461 and lm92) are missing from the
SBC610's DTS file.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6898d7e..85d1416 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -153,6 +153,16 @@
interrupt-parent = <&mpic>;
dfsrr;
+ hwmon@48 {
+ compatible = "national,lm92";
+ reg = <0x48>;
+ };
+
+ hwmon@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+
rtc@51 {
compatible = "epson,rx8581";
reg = <0x00000051>;
^ permalink raw reply related
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Piotr Zięcik @ 2009-05-19 11:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <1242685051.16901.6.camel@pasglop>
Tuesday 19 May 2009 00:17:31 Benjamin Herrenschmidt wrote:
>
> We are close to the point where we can make this a runtime option
> though, by just having a different set of dma_ops hooked in.
>
Is somebody currently working on it? If yes, where we can see
code ?
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* Q: MTD RAM in OF Device Tree
From: Albrecht Dreß @ 2009-05-19 11:59 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
is there a standard way to define a ram chip (in my case a battery-buffered=
nv ram, attached to the 5200's Local Bus) in the OF tree, and are there an=
y drivers (on 2.6.29.1) which pick up the chip/partition specification for =
mtd? Does such a driver exist, or do I have to write one (probably based o=
n plat-ram.c?)? I think of something like
localbus {
=09[...]
=09ranges =3D < 0 0 0xfe000000 0x02000000
=09=09 1 0 0xfc000000 0x00080000>;
flash@0,0 {
=09=09[flash definition & partitions]
=09};
=09nvram@1,0 {
=09=09compatible =3D "mtd-ram";
=09=09reg =3D <1 0x0 0x00080000>;
=09=09bank-width =3D <2>;
=09=09device-width =3D <2>;
=09=09#size-cells =3D <1>;
=09=09#address-cells =3D <1>;
=09=09part@0 {
=09=09=09label =3D "pdata";
=09=09=09reg =3D <0x00000000 0x00080000>;
=09=09};
=09};
};
Thanks,
Albrecht.
Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus =FCber 80 Spielen w=E4hlen!
http://www.arcor.de/footer-gaming/
^ permalink raw reply
* Re: Q: MTD RAM in OF Device Tree
From: Wolfram Sang @ 2009-05-19 12:27 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <5023288.1242734340173.JavaMail.ngmail@webmail15.arcor-online.net>
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
Hello Albrecht,
(adding linux-mtd)
On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dreß wrote:
>
> is there a standard way to define a ram chip (in my case a battery-buffered
> nv ram, attached to the 5200's Local Bus) in the OF tree, and are there any
> drivers (on 2.6.29.1) which pick up the chip/partition specification for mtd?
> Does such a driver exist, or do I have to write one (probably based on
> plat-ram.c?)? I think of something like
I wrote such a driver (yet without partitioning support) and I am trying to get
it mainline, just didn't get any comments so far:
http://patchwork.ozlabs.org/patch/23557/
http://patchwork.ozlabs.org/patch/23556/
I'd be happy if you could give it a try and donate some
{Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try to get
it mainline.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Grant Likely @ 2009-05-19 12:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: scottwood, linuxppc-dev, Timur Tabi
In-Reply-To: <20090518235756.7a0b1061@lappy.seanm.ca>
On Mon, May 18, 2009 at 9:57 PM, Sean MacLennan <smaclennan@pikatech.com> w=
rote:
> On Mon, 18 May 2009 20:58:03 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Then let it lie fallow on the list and in patchwork. =A0It is published,
>> and people know that it is available (I'll certainly consider it as I
>> do driver work), but there must be real (not just theoretical) in
>> kernel users of the interface. =A0I someone wants to use it, then they
>> can add it to their series or ping the list about getting it merged.
>
> That's too bad. If it is ever merged, could you also ping the list?
If you intend to use it, then post a patch to do so and state that it
depends on Timur's patch.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-19 13:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <1242683395.16901.0.camel@pasglop>
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>>
>> Part of this is how the generic swiotlb code works and part of it
>> was
>> our desire not to bloat dev archdata by adding such info that as you
>> say is either bus specific or conveyed in the dma addr mask.
>
> Right but perf sucks :-)
>
> Maybe an option is to clamp the DMA mask when it's set by the driver
> to
> limit it to the available inbound window ?
Clamping the DMA mask is even worse than the additional indirection
for us. We have valid scenarios in which we'd have 512M of outbound
PCI address space and 4G of mem and thus 3.5G of inbound PCI address
space. With the DMA mask we'd be limited to 2G and bouncing from
2..3.5G when we don't need to.
I think our options are to change archdata as follows:
Option 1 - just add a new data member to dev_archdata
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
void *dma_data;
dma_addr_t direct_dma_addr;
};
Option 2 - introduce a proper container for how we use dma_data. This
may just be moving the indirection from an indirection function call
to an indirection data reference:
struct dma_data {
dma_addr_t offset;
dma_addr_t direct_dma_addr;
struct iommu_table *iommu_table;
};
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
struct dma_data *dma_data;
};
Option 3 - use dma_data to keep the addr at which we need to bounce vs
not for SWIOTLB - this has potential issues w/conflicting with
dma_data being used as the dma_offset. (need to think on that a bit
more). Additionally this has the benefit in that we need dma_data to
be a 64-bit quantity on ppc32 w/>32-bit phys addr.
struct dev_archdata {
/* Optional pointer to an OF device node */
struct device_node *of_node;
/* DMA operations on that device */
struct dma_mapping_ops *dma_ops;
dma_addr_t dma_data;
};
others??
- k
^ permalink raw reply
* Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-19 13:08 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Linuxppc-embedded
Hi,
kernel- 2.6.29
Debug technique: KGDB
The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
prevents the use of software breakpoints in case of internal debug
mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
used by boot-loaders.
It seems head_44x.S lacks this step of DBCR0 register initialization.
So fixing this with initializing the DBCR0 register as shown below :
Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having
bootloader
The kernel does not initialize the PPC440 DBCR0 register.
This prevents (among other things) the use of software
breakpoints with GDB. The boot loaders probably do initialize
this but few targets run without a boot loader
---
arch/powerpc/kernel/head_44x.S | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index a4a890a..b413bc4 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -240,6 +240,18 @@ skpinv: addi r4,r4,1 /* Increment */
lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
mtspr SPRN_IVPR,r4
+#if !defined(CONFIG_BDI_SWITCH)
+ /*
+ * The Abatron BDI JTAG debugger does not tolerate others
+ * mucking with the debug registers.
+ */
+ lis r2,DBCR0_IDM@h
+ mtspr SPRN_DBCR0,r2
+ isync
+ /* clear any residual debug events */
+ li r2,-1
+ mtspr SPRN_DBSR,r2
+#endif
/*
* This is where the main kernel code starts.
*/
Any suggestions or comments on this ?
Thanks,
-Srikant
^ permalink raw reply related
* Re: Q: MTD RAM in OF Device Tree
From: Grant Likely @ 2009-05-19 14:39 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Albrecht Dreß, linux-mtd, linuxppc-dev
In-Reply-To: <20090519122714.GH30753@pengutronix.de>
On Tue, May 19, 2009 at 6:27 AM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
> Hello Albrecht,
>
> (adding linux-mtd)
>
> On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dre=DF wrote:
>>
>> is there a standard way to define a ram chip (in my case a battery-buffe=
red
>> nv ram, attached to the 5200's Local Bus) in the OF tree, and are there =
any
>> drivers (on 2.6.29.1) which pick up the chip/partition specification for=
mtd?
>> Does such a driver exist, or do I have to write one (probably based on
>> plat-ram.c?)? =A0I think of something like
>
> I wrote such a driver (yet without partitioning support) and I am trying =
to get
> it mainline, just didn't get any comments so far:
>
> http://patchwork.ozlabs.org/patch/23557/
> http://patchwork.ozlabs.org/patch/23556/
>
> I'd be happy if you could give it a try and donate some
> {Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try to =
get
> it mainline.
I missed them when you posted them. I'll go look now.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] maps/mtd-ram: refactor probe and remove
From: Grant Likely @ 2009-05-19 14:41 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <1232559685-2268-2-git-send-email-w.sang@pengutronix.de>
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> Refactor the probe and remove routines of the mtd-ram driver to export
> a generic part which can later be accessed by an of-counterpart of this
> driver. Tested with a phyCORE-MPC5200B-IO.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
On brief review, looks okay by me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0drivers/mtd/maps/plat-ram.c =A0| =A0123 +++++++++++++++++++++---------=
------------
> =A0include/linux/mtd/plat-ram.h | =A0 =A04 ++
> =A02 files changed, 66 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/mtd/maps/plat-ram.c b/drivers/mtd/maps/plat-ram.c
> index e7dd9c8..1582cd6 100644
> --- a/drivers/mtd/maps/plat-ram.c
> +++ b/drivers/mtd/maps/plat-ram.c
> @@ -50,16 +50,6 @@ struct platram_info {
> =A0 =A0 =A0 =A0struct platdata_mtd_ram *pdata;
> =A0};
>
> -/* to_platram_info()
> - *
> - * device private data to struct platram_info conversion
> -*/
> -
> -static inline struct platram_info *to_platram_info(struct platform_devic=
e *dev)
> -{
> - =A0 =A0 =A0 return (struct platram_info *)platform_get_drvdata(dev);
> -}
> -
> =A0/* platram_setrw
> =A0*
> =A0* call the platform device's set rw/ro control
> @@ -77,18 +67,14 @@ static inline void platram_setrw(struct platram_info =
*info, int to)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(info->pdata->set_rw)(info->dev, to);
> =A0}
>
> -/* platram_remove
> - *
> - * called to remove the device from the driver's control
> -*/
> -
> -static int platram_remove(struct platform_device *pdev)
> +int __platram_remove(struct device *dev)
> =A0{
> - =A0 =A0 =A0 struct platram_info *info =3D to_platram_info(pdev);
> + =A0 =A0 =A0 struct platram_info *info;
>
> - =A0 =A0 =A0 platform_set_drvdata(pdev, NULL);
> + =A0 =A0 =A0 dev_dbg(dev, "removing device\n");
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "removing device\n");
> + =A0 =A0 =A0 info =3D dev_get_drvdata(dev);
> + =A0 =A0 =A0 dev_set_drvdata(dev, NULL);
>
> =A0 =A0 =A0 =A0if (info =3D=3D NULL)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;
> @@ -123,68 +109,49 @@ static int platram_remove(struct platform_device *p=
dev)
>
> =A0 =A0 =A0 =A0return 0;
> =A0}
> +EXPORT_SYMBOL_GPL(__platram_remove);
>
> -/* platram_probe
> +/* platram_remove
> =A0*
> - * called from device drive system when a device matching our
> - * driver is found.
> + * called to remove the device from the driver's control
> =A0*/
>
> -static int platram_probe(struct platform_device *pdev)
> +static int platram_remove(struct platform_device *pdev)
> +{
> + =A0 =A0 =A0 return __platram_remove(&pdev->dev);
> +}
> +
> +int __platram_probe(struct device *dev, const char *name,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct resource *res, struc=
t platdata_mtd_ram *pdata)
> =A0{
> - =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> =A0 =A0 =A0 =A0struct platram_info *info;
> - =A0 =A0 =A0 struct resource *res;
> =A0 =A0 =A0 =A0int err =3D 0;
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "probe entered\n");
> -
> - =A0 =A0 =A0 if (pdev->dev.platform_data =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no platform data suppl=
ied\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOENT;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto exit_error;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 pdata =3D pdev->dev.platform_data;
> -
> =A0 =A0 =A0 =A0info =3D kzalloc(sizeof(*info), GFP_KERNEL);
> =A0 =A0 =A0 =A0if (info =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory for flash in=
fo\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "no memory for flash info\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_error;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 platform_set_drvdata(pdev, info);
> + =A0 =A0 =A0 dev_set_drvdata(dev, info);
>
> - =A0 =A0 =A0 info->dev =3D &pdev->dev;
> + =A0 =A0 =A0 info->dev =3D dev;
> =A0 =A0 =A0 =A0info->pdata =3D pdata;
>
> - =A0 =A0 =A0 /* get the resource for the memory mapping */
> -
> - =A0 =A0 =A0 res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> - =A0 =A0 =A0 if (res =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory resource spe=
cified\n");
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOENT;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto exit_free;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "got platform resource %p (0x%llx)\n", =
res,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res->start);
> -
> =A0 =A0 =A0 =A0/* setup map parameters */
>
> =A0 =A0 =A0 =A0info->map.phys =3D res->start;
> =A0 =A0 =A0 =A0info->map.size =3D (res->end - res->start) + 1;
> =A0 =A0 =A0 =A0info->map.name =3D pdata->mapname !=3D NULL ?
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (char *)pdata->mapname : (c=
har *)pdev->name;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (char *)pdata->mapname : (c=
har *)name;
> =A0 =A0 =A0 =A0info->map.bankwidth =3D pdata->bankwidth;
>
> =A0 =A0 =A0 =A0/* register our usage of the memory area */
>
> - =A0 =A0 =A0 info->area =3D request_mem_region(res->start, info->map.siz=
e, pdev->name);
> + =A0 =A0 =A0 info->area =3D request_mem_region(res->start, info->map.siz=
e, name);
> =A0 =A0 =A0 =A0if (info->area =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to request memo=
ry region\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to request memory regi=
on\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -EIO;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
> @@ -192,17 +159,17 @@ static int platram_probe(struct platform_device *pd=
ev)
> =A0 =A0 =A0 =A0/* remap the memory area */
>
> =A0 =A0 =A0 =A0info->map.virt =3D ioremap(res->start, info->map.size);
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "virt %p, %lu bytes\n", info->map.virt,=
info->map.size);
> + =A0 =A0 =A0 dev_dbg(dev, "virt %p, %lu bytes\n", info->map.virt, info->=
map.size);
>
> =A0 =A0 =A0 =A0if (info->map.virt =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to ioremap() re=
gion\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to ioremap() region\n"=
);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -EIO;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0simple_map_init(&info->map);
>
> - =A0 =A0 =A0 dev_dbg(&pdev->dev, "initialised map, probing for mtd\n");
> + =A0 =A0 =A0 dev_dbg(dev, "initialised map, probing for mtd\n");
>
> =A0 =A0 =A0 =A0/* probe for the right mtd map driver
> =A0 =A0 =A0 =A0 * supplied by the platform_data struct */
> @@ -218,7 +185,7 @@ static int platram_probe(struct platform_device *pdev=
)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0info->mtd =3D do_map_probe("map_ram", &inf=
o->map);
>
> =A0 =A0 =A0 =A0if (info->mtd =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "failed to probe for ma=
p_ram\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "failed to probe for map_ram\n=
");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto exit_free;
> =A0 =A0 =A0 =A0}
> @@ -249,20 +216,54 @@ static int platram_probe(struct platform_device *pd=
ev)
> =A0#endif /* CONFIG_MTD_PARTITIONS */
>
> =A0 =A0 =A0 =A0if (add_mtd_device(info->mtd)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "add_mtd_device() faile=
d\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "add_mtd_device() failed\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D -ENOMEM;
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0if (!err)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_info(&pdev->dev, "registered mtd device=
\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_info(dev, "registered mtd device\n");
>
> =A0 =A0 =A0 =A0return err;
>
> =A0exit_free:
> - =A0 =A0 =A0 platram_remove(pdev);
> + =A0 =A0 =A0 __platram_remove(dev);
> =A0exit_error:
> =A0 =A0 =A0 =A0return err;
> =A0}
> +EXPORT_SYMBOL_GPL(__platram_probe);
> +
> +/* platram_probe
> + *
> + * called from device drive system when a device matching our
> + * driver is found.
> +*/
> +
> +static int platram_probe(struct platform_device *pdev)
> +{
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> + =A0 =A0 =A0 struct resource *res;
> +
> + =A0 =A0 =A0 dev_dbg(&pdev->dev, "probe entered\n");
> +
> + =A0 =A0 =A0 pdata =3D pdev->dev.platform_data;
> + =A0 =A0 =A0 if (pdata =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no platform data suppl=
ied\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOENT;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* get the resource for the memory mapping */
> +
> + =A0 =A0 =A0 res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + =A0 =A0 =A0 if (res =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&pdev->dev, "no memory resource spe=
cified\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOENT;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 dev_dbg(&pdev->dev, "got platform resource %p (0x%llx)\n", =
res,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (unsigned long long)res->start);
> +
> + =A0 =A0 =A0 return __platram_probe(&pdev->dev, pdev->name, res, pdata);
> +}
>
> =A0/* device driver info */
>
> diff --git a/include/linux/mtd/plat-ram.h b/include/linux/mtd/plat-ram.h
> index e07890a..c522562 100644
> --- a/include/linux/mtd/plat-ram.h
> +++ b/include/linux/mtd/plat-ram.h
> @@ -31,4 +31,8 @@ struct platdata_mtd_ram {
> =A0 =A0 =A0 =A0void =A0 =A0(*set_rw)(struct device *dev, int to);
> =A0};
>
> +extern int __platram_probe(struct device *dev, const char *name,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct resource *res, struc=
t platdata_mtd_ram *pdata);
> +extern int __platram_remove(struct device *dev);
> +
> =A0#endif /* __LINUX_MTD_PLATRAM_H */
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-19 14:57 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <1232559685-2268-3-git-send-email-w.sang@pengutronix.de>
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> Create an of-aware driver using the now exported generic functions from
> plat-ram.c. A typical oftree snipplet for it looks like this:
>
> sram@04e00000 {
> =A0 =A0 =A0 =A0compatible =3D "mtd-ram";
> =A0 =A0 =A0 =A0reg =3D <0x04e00000 0x00200000>;
> =A0 =A0 =A0 =A0bank-width =3D <2>;
> };
>
> Partitions on this device are not yet supported.
This is a new device tree binding. It must be documented in
Documentation/powerpc/dts-bindings and posted to
devicetree-discuss@ozlabs.org for review.
> diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> index 6d9ba35..f8e3908 100644
> --- a/drivers/mtd/maps/Makefile
> +++ b/drivers/mtd/maps/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_WRSBC8260) =A0 +=3D wr_sbc82xx_flash.o
> =A0obj-$(CONFIG_MTD_DMV182) =A0 =A0 =A0 +=3D dmv182.o
> =A0obj-$(CONFIG_MTD_SHARP_SL) =A0 =A0 +=3D sharpsl-flash.o
> =A0obj-$(CONFIG_MTD_PLATRAM) =A0 =A0 =A0+=3D plat-ram.o
> +obj-$(CONFIG_MTD_OFRAM) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D of-ram.o
> =A0obj-$(CONFIG_MTD_OMAP_NOR) =A0 =A0 +=3D omap_nor.o
> =A0obj-$(CONFIG_MTD_INTEL_VR_NOR) +=3D intel_vr_nor.o
> =A0obj-$(CONFIG_MTD_BFIN_ASYNC) =A0 +=3D bfin-async-flash.o
> diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> new file mode 100644
> index 0000000..4d334a9
> --- /dev/null
> +++ b/drivers/mtd/maps/of-ram.c
> @@ -0,0 +1,120 @@
> +/*
> + * drivers/mtd/maps/of-ram.c
> + *
> + * Generic of device based RAM map
> + *
> + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> + *
> + * Using plat-ram.c by Ben Dooks
> + *
> + * 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 publis=
hed by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/mtd/plat-ram.h>
> +
> +static int of_ram_probe(struct of_device *op, const struct of_device_id =
*match)
__devinit
> +{
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> + =A0 =A0 =A0 struct resource *resource;
> + =A0 =A0 =A0 const char *name;
> + =A0 =A0 =A0 const u32 *bankwidth;
> + =A0 =A0 =A0 int ret =3D -ENOMEM;
> +
> + =A0 =A0 =A0 pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> + =A0 =A0 =A0 if (!pdata)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad0;
> + =A0 =A0 =A0 op->dev.platform_data =3D pdata;
> +
> + =A0 =A0 =A0 name =3D of_get_property(op->node, "name", NULL);
> + =A0 =A0 =A0 if (!name) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not get node name\=
n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 resource =3D kzalloc(sizeof(struct resource), GFP_KERNEL);
> + =A0 =A0 =A0 if (!resource)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
Why isn't resource on the stack?
> +
> + =A0 =A0 =A0 if (of_address_to_resource(op->node, 0, resource)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENXIO;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not create resourc=
e\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 bankwidth =3D of_get_property(op->node, "bank-width", NULL)=
;
> + =A0 =A0 =A0 if (*bankwidth =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "bank width not set\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad2;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 pdata->bankwidth =3D *bankwidth;
> +
> + =A0 =A0 =A0 ret =3D __platram_probe(&op->dev, name, resource, pdata);
> + =A0 =A0 =A0 kfree(resource);
> +
> + =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
> +
> + =A0 =A0 =A0 return 0;
> +
> + bad2:
> + =A0 =A0 =A0 kfree(resource);
> + bad1:
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + bad0:
> + =A0 =A0 =A0 return ret;
I'd rather see more meaningful labels. ie "err_kalloc:" and
"err_platram_probe:".
> +}
> +
> +static int of_ram_remove(struct of_device *op)
__devexit
> +{
> + =A0 =A0 =A0 int ret;
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata =3D op->dev.platform_data;
> +
> + =A0 =A0 =A0 ret =3D __platram_remove(&op->dev);
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + =A0 =A0 =A0 return ret;
> +}
> +
> +static struct of_device_id of_ram_match[] =3D {
> + =A0 =A0 =A0 { .compatible =3D "mtd-ram", },
> + =A0 =A0 =A0 {},
> +};
> +MODULE_DEVICE_TABLE(of, of_ram_match);
> +
> +static struct of_platform_driver of_ram_driver =3D {
__devinitdata
> + =A0 =A0 =A0 .owner =3D THIS_MODULE,
> + =A0 =A0 =A0 .name =3D "of-ram",
This name is too generic for an of_platform device. 'mtd' needs to be
in there somewhere.
> + =A0 =A0 =A0 .match_table =3D of_ram_match,
> + =A0 =A0 =A0 .probe =3D of_ram_probe,
> + =A0 =A0 =A0 .remove =3D of_ram_remove,
__devexit_p()
> +};
> +
> +static int __init of_ram_init(void)
> +{
> + =A0 =A0 =A0 return of_register_platform_driver(&of_ram_driver);
> +}
> +
> +static void __exit of_ram_exit(void)
> +{
> + =A0 =A0 =A0 of_unregister_platform_driver(&of_ram_driver);
> +}
> +
> +module_init(of_ram_init);
Put the module_init() statement directly after the of_ram_init() definition=
.
> +module_exit(of_ram_exit);
> +
> +MODULE_AUTHOR("Wolfram Sang");
> +MODULE_DESCRIPTION("MTD OF RAM map driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Musings on PCI busses
From: Grant Likely @ 2009-05-19 15:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala, Josh Boyer,
Roderick Colenbrander, John Linn, linuxppc-dev
Hey all,
I've been having some thoughts on PCI host controller probing and how
best to handle it. Currently AFAICT, the SoC platform code explicitly
calls the PCI setup code. In all of the existing SoCs this works fine
because there is SoC specific platform code which knows what PCI
busses to expect on the SoC.
I'm now looking at the case of Xilinx Virtex FPGA support. Because it
is an FPGA and the SW view of the design is so flexible and fluid, I'm
trying to keep platform code unified for all Virtex platforms. (ie.
two radically different board layouts can look identical from the
CPU's perspective, or the behaviour of one board can be completely
changed with a new bitstream).
Roderick has written a patch to support one of the Xilinx reference
designs that includes a PCI host controller. Right now the patch adds
a separate platform file, but I'm not comfortable with the approach
(despite suggesting it to Roderick in the first place) because it
relegates PCI support to only work with the ml510 reference design.
ie. PCI will not be automatically supported for anyone who modifies
the reference design or adds the PCI host controller to their own
design. So I've been thinking of alternatives. Here's what I've come
up with.
1) Probe the host controller in an of_platform driver. This has the
advantage of simplicity. The probe routine will get automatically
called when the PCI host controller device tree node is registered
with the of_platform bus. The bus parenthood also gets reflected in
the device model and sysfs. The disadvantage is that it defers PCI
bus probing until after the of_platform bus is probed (maybe this is
okay; maybe this already happens anyway).
2) Probe the host controller in an subsys_initcall(). Advantage is
PCI can be probed earlier in the init path. Disadvantages (minor) are
that it will always get called if the driver is enabled, and it needs
to manually search the device tree for PCI nodes.
I'm leaning towards making it an of_platform driver. Doing so also
makes it available to other powerpc processors (not just virtex) in
the case where a Xilinx FPGA is welded up to a discrete SoC and a host
controller instance is put into the FPGA. (one of those weird things
people do when they have an FPGA in their system).
Comments? Opinions?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Musings on PCI busses
From: Arnd Bergmann @ 2009-05-19 16:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Roderick Colenbrander, John Linn
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
On Tuesday 19 May 2009, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. =A0This has the
> advantage of simplicity. =A0The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. =A0The bus parenthood also gets reflected in
> the device model and sysfs. =A0The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).
This is also what we do on 64-bit systems (well, Cell at this time).
There are no fundamental problems with this, just some slightly
unexpected interactions e.g. when you have use a PCI serial port
as your console before probing PCI.
Making CONFIG_PPC_OF_PLATFORM_PCI probably requires some more
consolidation between pci_32.c and pci_64.c, but I'd consider
this a good thing.
Arnd <><
^ permalink raw reply
* RE: Musings on PCI busses
From: Stephen Neuendorffer @ 2009-05-19 16:25 UTC (permalink / raw)
To: Grant Likely, Benjamin Herrenschmidt, Kumar Gala, Josh Boyer,
Roderick Colenbrander, John Linn, linuxppc-dev
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model and sysfs. The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).
> =
> 2) Probe the host controller in an subsys_initcall(). Advantage is
> PCI can be probed earlier in the init path. Disadvantages (minor) are
> that it will always get called if the driver is enabled, and it needs
> to manually search the device tree for PCI nodes.
> =
> I'm leaning towards making it an of_platform driver. Doing so also
> makes it available to other powerpc processors (not just virtex) in
> the case where a Xilinx FPGA is welded up to a discrete SoC and a host
> controller instance is put into the FPGA. (one of those weird things
> people do when they have an FPGA in their system).
I agree that something is called for... The first might be slightly
simpler, since it would probably transparently deal with the presence
of more than one PLB->PCI bridge?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-19 16:30 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Roderick Colenbrander, John Linn
In-Reply-To: <20090519162511.7454D17E8058@mail19-dub.bigfish.com>
On Tue, May 19, 2009 at 10:25 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>> 1) Probe the host controller in an of_platform driver. =A0This has the
>> advantage of simplicity. =A0The probe routine will get automatically
>> called when the PCI host controller device tree node is registered
>> with the of_platform bus. =A0The bus parenthood also gets reflected in
>> the device model and sysfs. =A0The disadvantage is that it defers PCI
>> bus probing until after the of_platform bus is probed (maybe this is
>> okay; maybe this already happens anyway).
>>
>> 2) Probe the host controller in an subsys_initcall(). =A0Advantage is
>> PCI can be probed earlier in the init path. =A0Disadvantages (minor) are
>> that it will always get called if the driver is enabled, and it needs
>> to manually search the device tree for PCI nodes.
>>
>> I'm leaning towards making it an of_platform driver. =A0Doing so also
>> makes it available to other powerpc processors (not just virtex) in
>> the case where a Xilinx FPGA is welded up to a discrete SoC and a host
>> controller instance is put into the FPGA. =A0(one of those weird things
>> people do when they have an FPGA in their system).
>
> I agree that something is called for... =A0The first might be slightly
> simpler, since it would probably transparently deal with the presence
> of more than one PLB->PCI bridge?
Yes, I think so.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Q: MTD RAM in OF Device Tree
From: Albrecht Dreß @ 2009-05-19 18:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090519122714.GH30753@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
Hi Wolfram!
Am 19.05.09 14:27 schrieb(en) Wolfram Sang:
> I wrote such a driver (yet without partitioning support) and I am
> trying to get it mainline, just didn't get any comments so far:
>
> http://patchwork.ozlabs.org/patch/23557/
> http://patchwork.ozlabs.org/patch/23556/
Thanks a lot, this is *exactly* what I was looking for! Actually,
partition support is not important as I want to use the whole chip -
512k isn't *that* much...
> I'd be happy if you could give it a try and donate some
> {Acked|Tested|Reviewed}-by tags. Maybe this will help for my next try
> to get it mainline.
Will do that once I get it running completely. The first test
triggered some strange problems when I wrote to /dev/mtdn and read back
the data (which is supposed to give "raw" direct access, right?) - the
last dword in each 512 byte block is partly broken. Probably something
in the localbus layout or timing...
Thanks again,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-19 19:05 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <200905191812.03347.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 19 May 2009 18:12:02 +0200
> On Tuesday 19 May 2009, Grant Likely wrote:
>> 1) Probe the host controller in an of_platform driver. =A0This has t=
he
>> advantage of simplicity. =A0The probe routine will get automatically=
>> called when the PCI host controller device tree node is registered
>> with the of_platform bus. =A0The bus parenthood also gets reflected =
in
>> the device model and sysfs. =A0The disadvantage is that it defers PC=
I
>> bus probing until after the of_platform bus is probed (maybe this is=
>> okay; maybe this already happens anyway).
> =
> This is also what we do on 64-bit systems (well, Cell at this time).
> There are no fundamental problems with this, just some slightly
> unexpected interactions e.g. when you have use a PCI serial port
> as your console before probing PCI.
This is also what sparc64 does :-)
All of the individual sparc64 PCI controller types have a OF driver
and then there is a common layer of OF PCI helper code to do most
of the work.
^ permalink raw reply
* [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, benh, grant.likely, smaclennan
In-Reply-To: <1242761199-17875-1-git-send-email-timur@freescale.com>
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v8: added a copyright notice
arch/powerpc/include/asm/delay.h | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..af4a270 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,8 +2,11 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include <asm/time.h>
+
/*
* Copyright 1996, Paul Mackerras.
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,5 +33,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
^ permalink raw reply related
* [PATCH 2/2] qe: add polling timeout to qe_issue_cmd()
From: Timur Tabi @ 2009-05-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, benh, grant.likely, smaclennan
In-Reply-To: <1242761199-17875-2-git-send-email-timur@freescale.com>
The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) polls on
a register until a status bit changes, but does not include a timeout to
handle the situation if the bit never changes. Change the code to use the new
spin_event_timeout() macro, which simplifies polling on a register without
a timeout.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch depends on my previous patch, "powerpc: introduce macro
spin_event_timeout()".
arch/powerpc/sysdev/qe_lib/qe.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 01bce37..810e1df 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -111,6 +111,7 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
{
unsigned long flags;
u8 mcn_shift = 0, dev_shift = 0;
+ int ret;
spin_lock_irqsave(&qe_lock, flags);
if (cmd == QE_RESET) {
@@ -138,11 +139,13 @@ int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input)
}
/* wait for the QE_CR_FLG to clear */
- while(in_be32(&qe_immr->cp.cecr) & QE_CR_FLG)
- cpu_relax();
+ spin_event_timeout((in_be32(&qe_immr->cp.cecr) & QE_CR_FLG) == 0,
+ 100, 0, ret);
+ /* On timeout (e.g. failure), the expression will be false (ret == 0),
+ otherwise it will be true (ret == 1). */
spin_unlock_irqrestore(&qe_lock, flags);
- return 0;
+ return ret == 1;
}
EXPORT_SYMBOL(qe_issue_cmd);
--
1.6.0.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox