* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Christoph Hellwig @ 2007-11-30 7:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130054126.39BDCDDE0A@ozlabs.org>
On Fri, Nov 30, 2007 at 04:40:23PM +1100, Benjamin Herrenschmidt wrote:
> From: Stefan Roese <sr@denx.de>
>
> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC 440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
Is there a reason the emac driver isn't using the generic phy code?
^ permalink raw reply
* Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
From: Benjamin Herrenschmidt @ 2007-11-30 7:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071130061209.497F3DE03A@ozlabs.org>
On Fri, 2007-11-30 at 17:11 +1100, Benjamin Herrenschmidt wrote:
> This adds base support for the Katmai board, including PCI-X and
> PCI-Express (but no RTC, nvram, etc... yet).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> As for Taishan, the bootwrapper code can be simplified. In fact,
> we probably don't need to probe clocks & memsize off the chip and
> just trust what uboot tells us.
This misses a select CONFIG_PPC4xx_PCI_EXPRESS in Kconfig, I added
that thing at the last minute and forgot to refresh the Katmai patch.
Without it, PCIe will not be probed.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Benjamin Herrenschmidt @ 2007-11-30 8:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130075641.GA16650@infradead.org>
On Fri, 2007-11-30 at 07:56 +0000, Christoph Hellwig wrote:
> >
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC
> driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese
> <sr@denx.de>
>
> Is there a reason the emac driver isn't using the generic phy code?
Yes. First, the emac PHY code predates the generic one, and mostly,
in its current shape, the generic PHY code does too violent locking
for me.
I need to be able to use mutexes in the low level PHY read/write, and
the current phylib doesn't allow that as it uses spinlocks all over.
However, I do plan to fix that. I haven't had time yet, but I plan to
convert PHY lib to more task-level operations, which would be a good
thing anyway since PHY communication is fairly slow and some chips can
do it interrupt driven rather than polling loops (and even polling loops
could be preemptible).
So the answer is "not yet" basically.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Li Li @ 2007-11-30 8:48 UTC (permalink / raw)
To: Gala Kumar; +Cc: linuxppc-dev, Li Tony
In-Reply-To: <4544168D-5E95-44E8-9128-6F343283EC82@freescale.com>
On Fri, 2007-11-30 at 15:37 +0800, Gala Kumar wrote:
>
> On Nov 29, 2007, at 9:45 PM, Li Li wrote:
>
> > The PCIE controller is initiated in u-boot.
> >
> > This patch is based on Leo`s mpc837xe patches.
> >
> >
> > Signed-off-by: Tony Li <tony.li@freescale.com>
> > ---
> > arch/powerpc/boot/dts/mpc8377_mds.dts | 56 ++++++++--
> > arch/powerpc/boot/dts/mpc8378_mds.dts | 56 ++++++++--
> > arch/powerpc/platforms/83xx/Kconfig | 7 ++
> > arch/powerpc/platforms/83xx/mpc8313_rdb.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc837x_mds.c | 7 +-
> > arch/powerpc/platforms/83xx/mpc83xx.h | 10 ++-
> > arch/powerpc/platforms/83xx/pci.c | 166
> ++++++++++++++++++++
> > +++++++-
> > 12 files changed, 283 insertions(+), 31 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
> > boot/dts/mpc8377_mds.dts
> > index 4402e39..1f7819e 100644
>
> >
> > +
> > + pci2@e0009000 {
>
> I agree w/Olof. This should be pcie@e0009000
> >
> > + interrupt-map-mask = <f800 0 0 7>;
> > + msi-available-ranges = <43 4 51 52 56 57 58 59>;
> > + interrupt-map = <
> > + 0000 0 0 1 &ipic 1 8
> > + 0000 0 0 2 &ipic 1 8
> > + 0000 0 0 3 &ipic 1 8
> > + 0000 0 0 4 &ipic 1 8
> > + >;
> > + interrupt-parent = < &ipic >;
> > + interrupts = <1 8>;
> > + bus-range = <0 0>;
> > + ranges = <02000000 0 A8000000 A8000000 0 10000000
> > + 01000000 0 00000000 B8000000 0 00800000>;
> > + clock-frequency = <0>;
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + reg = <e0009000 00001000
> > + a0000000 08000000>;
>
> Shouldn't the reg size for the cfg space be 256M?
256M is a little too big for kernel.
>
>
> > diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> > platforms/83xx/Kconfig
> > index 0c61e7a..00154c5 100644
> > --- a/arch/powerpc/platforms/83xx/Kconfig
> > +++ b/arch/powerpc/platforms/83xx/Kconfig
> > @@ -87,3 +87,10 @@ config PPC_MPC837x
> > select PPC_INDIRECT_PCI
> > select FSL_SERDES
> > default y if MPC837x_MDS
> > +
> > +config PPC_MPC83XX_PCIE
> > + bool "MPC837X PCI Express support"
> > + depends on PCIEPORTBUS && PPC_MPC837x
> > + default n
> > + help
> > + Enables MPC837x PCI express RC mode
>
> This should be a hidden config that is just selected by PPC_MPC837x
> instead of a choice. Also drop the depends on.
>
In the dts file, the PCIE is default enabled. So, we should provide
another way to disable the PCIE.
Modify and recompile the dts is a little unkind to user.
> > diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/
> > platforms/83xx/mpc83xx.h
> > index b778cb4..2078da7 100644
> > --- a/arch/powerpc/platforms/83xx/mpc83xx.h
> > +++ b/arch/powerpc/platforms/83xx/mpc83xx.h
> > @@ -43,12 +43,18 @@
> > #define PORTSCX_PTS_UTMI 0x00000000
> > #define PORTSCX_PTS_ULPI 0x80000000
> >
> > +/* PCIE Registers */
> > +#define PEX_LTSSM_STAT 0x404
> > +#define PEX_LTSSM_STAT_L0 0x16
> > +#define PEX_GCLK_RATIO 0x440
> > +
>
> just move these into the .c file.
>
> >
> > /*
> > * Declaration for the various functions exported by the
> > * mpc83xx_* files. Mostly for use by mpc83xx_setup
> > */
> > -
> > -extern int mpc83xx_add_bridge(struct device_node *dev);
> > +#define PPC_83XX_PCI 0x1
> > +#define PPC_83XX_PCIE 0x2
> > +extern int mpc83xx_add_bridge(struct device_node *dev, int flags);
> > extern void mpc83xx_restart(char *cmd);
> > extern long mpc83xx_time_init(void);
> > extern int mpc834x_usb_cfg(void);
> > diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/
> > platforms/83xx/pci.c
> > index 80425d7..0b52b2e 100644
> > --- a/arch/powerpc/platforms/83xx/pci.c
> > +++ b/arch/powerpc/platforms/83xx/pci.c
> > @@ -25,6 +25,8 @@
> > #include <asm/prom.h>
> > #include <sysdev/fsl_soc.h>
> >
> > +#include "mpc83xx.h"
> > +
> > #undef DEBUG
> >
> > #ifdef DEBUG
> > @@ -33,13 +35,157 @@
> > #define DBG(x...)
> > #endif
> >
> > -int __init mpc83xx_add_bridge(struct device_node *dev)
> > +#if defined(CONFIG_PPC_MPC83XX_PCIE)
> > +
> > +/* PCIE config space Read/Write routines */
>
> should really be called something like mpc83xx_pciex_read_config
> >
> > +static int direct_read_config_pcie(struct pci_bus *bus,
> > + uint devfn, int offset, int len, u32 *val)
> > +{
> > + struct pci_controller *hose = bus->sysdata;
> > + void __iomem *cfg_addr;
> > + u32 bus_no;
> > +
> > + if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + if (ppc_md.pci_exclude_device)
> > + if (ppc_md.pci_exclude_device(hose, bus->number,
> devfn))
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + switch (len) {
> > + case 2:
> > + if (offset & 1)
> > + return -EINVAL;
> > + break;
> > + case 4:
> > + if (offset & 3)
> > + return -EINVAL;
> > + break;
> > + }
>
> fix formatting.
>
> >
> > +
> > + pr_debug("_read_cfg_pcie: bus=%d devfn=%x off=%x len=%x\n",
> > + bus->number, devfn, offset, len);
> > +
> > + if (bus->number == hose->first_busno) {
> > + if (devfn & 0xf8)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
>
> what is the 0xf8 all about?
>
The pcie only have one link, so the dev number only can be 0, as well
the function number can be 0 ~ 7.
> >
> > + bus_no = hose->self_busno;
> > + } else
> > + bus_no = bus->number;
> > +
> > + cfg_addr = (void __iomem *)((ulong) hose->cfg_addr +
> > + ((bus_no << 20) | (devfn << 12) | (offset & 0xfff)));
> > +
> > + switch (len) {
> > + case 1:
> > + *val = in_8(cfg_addr);
> > + break;
> > + case 2:
> > + *val = in_le16(cfg_addr);
> > + break;
> > + default:
> > + *val = in_le32(cfg_addr);
> > + break;
> > + }
> > + pr_debug("_read_cfg_pcie: val=%x cfg_addr=%p\n", *val,
> cfg_addr);
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
> > +
> > +static int direct_write_config_pcie(struct pci_bus *bus,
> > + uint devfn, int offset, int len, u32 val)
> > +{
> > + struct pci_controller *hose = bus->sysdata;
> > + void __iomem *cfg_addr;
> > + u32 bus_no;
> > +
> > + if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + if (ppc_md.pci_exclude_device)
> > + if (ppc_md.pci_exclude_device(hose, bus->number,
> devfn))
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + switch (len) {
> > + case 2:
> > + if (offset & 1)
> > + return -EINVAL;
> > + break;
> > + case 4:
> > + if (offset & 3)
> > + return -EINVAL;
> > + break;
> > + }
> > +
> > + if (bus->number == hose->first_busno) {
> > + if (devfn & 0xf8)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > + bus_no = hose->self_busno;
> > + } else
> > + bus_no = bus->number;
> > +
> > + cfg_addr = (void __iomem *)((ulong) hose->cfg_addr +
> > + ((bus_no << 20) | (devfn << 12) | (offset & 0xfff)));
> > +
> > + switch (len) {
> > + case 1:
> > + out_8(cfg_addr, val);
> > + break;
> > + case 2:
> > + out_le16(cfg_addr, val);
> > + break;
> > + default:
> > + out_le32(cfg_addr, val);
> > + break;
> > + }
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
> > +
> > +static struct pci_ops direct_pcie_ops = {
> > + direct_read_config_pcie,
> > + direct_write_config_pcie
> > +};
> > +
> > +void __init setup_direct_pcie(struct pci_controller *hose, u32
> > cfg_addr, u32 cfg_size)
> > +{
> > + ulong base = cfg_addr & PAGE_MASK;
> > + void __iomem *mbase, *addr;
> > +
> > + mbase = ioremap(base, cfg_size);
>
> this ioremap is going to be problematic in that cfg_size is going to
> be 256M. and we will not have enough kernel virtual address space to
> deal with it.
>
I agree.
> > + addr = mbase + (cfg_addr & ~PAGE_MASK);
> > + hose->cfg_addr = addr;
> > + hose->ops = &direct_pcie_ops;
>
> what's the point of this function, why not just fold it into
> mpc83xx_setup_pcie
>
> >
> > +}
> > +
> > +static void __init mpc83xx_setup_pcie(struct pci_controller *hose,
> > + struct resource *reg, struct resource
> *cfg_space)
> > +{
> > + void __iomem *hose_cfg_base;
> > + u32 val;
> > +
> > + hose_cfg_base = ioremap(reg->start, reg->end - reg->start +
> 1);
> > +
> > + val = in_le32(hose_cfg_base + PEX_LTSSM_STAT);
> > + if (val < PEX_LTSSM_STAT_L0)
> > + hose->indirect_type |=
> PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> > +
> > + setup_direct_pcie(hose, cfg_space->start,
> > + cfg_space->end - cfg_space->start + 1);
> > +}
> > +#endif /* CONFIG_PPC_MPC83XX_PCIE */
> > +
>
> We should do the same think fsl_pci does for primary, its passed
> into
> _add_bridge. Also, can we not do what fsl_pci does and use PCI
> capabilities to determine we are a PCIe controller (and drop passing
> it in via flags).
>
The mpc837x PCIE controller is a little different from mpc85xx.
It can not be access via PCI configure read/write. It only can be
accessed via memory-mapped read/write from core.
> > +int __init mpc83xx_add_bridge(struct device_node *dev, int flags)
> > {
> > int len;
> > struct pci_controller *hose;
> > struct resource rsrc;
> > +#if defined(CONFIG_PPC_MPC83XX_PCIE)
> > + struct resource cfg_space;
> > +#endif
> > const int *bus_range;
> > - int primary = 1, has_address = 0;
> > + static int primary = 1;
> > + int has_address = 0;
> > phys_addr_t immr = get_immrbase();
> >
> > DBG("Adding PCI host bridge %s\n", dev->full_name);
> > @@ -66,14 +212,21 @@ int __init mpc83xx_add_bridge(struct
> > device_node *dev)
> > * the other at 0x8600, we consider the 0x8500 the primary
> controller
> > */
> > /* PCI 1 */
> > - if ((rsrc.start & 0xfffff) == 0x8500) {
> > + if ((rsrc.start & 0xfffff) == 0x8500)
> > setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304,
> 0);
> > - }
> > /* PCI 2 */
> > - if ((rsrc.start & 0xfffff) == 0x8600) {
> > + if ((rsrc.start & 0xfffff) == 0x8600)
> > setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384,
> 0);
> > - primary = 0;
> > +
> > +#if defined(CONFIG_PPC_MPC83XX_PCIE)
> > + if (flags & PPC_83XX_PCIE) {
> > + if (of_address_to_resource(dev, 1, &cfg_space)) {
> > + printk("PCIE RC losts configure space. Skip it
> \n");
> > + return 1;
> > + }
> > + mpc83xx_setup_pcie(hose, &rsrc, &cfg_space);
> > }
> > +#endif
> >
> > printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx.
> "
> > "Firmware bus number: %d->%d\n",
> > @@ -86,6 +239,7 @@ int __init mpc83xx_add_bridge(struct
> device_node
> > *dev)
> > /* Interpret the "ranges" property */
> > /* This also maps the I/O region and sets isa_io/mem_base */
> > pci_process_bridge_OF_ranges(hose, dev, primary);
> > + primary = 0;
> >
> > return 0;
> > }
> > --
> > 1.5.2
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Kumar Gala @ 2007-11-30 9:05 UTC (permalink / raw)
To: Li Li; +Cc: linuxppc-dev, Li Tony
In-Reply-To: <1196412491.31962.9.camel@Guyver>
>>> +
>>> + pci2@e0009000 {
>>
>> I agree w/Olof. This should be pcie@e0009000
>>>
>>> + interrupt-map-mask = <f800 0 0 7>;
>>> + msi-available-ranges = <43 4 51 52 56 57 58 59>;
>>> + interrupt-map = <
>>> + 0000 0 0 1 &ipic 1 8
>>> + 0000 0 0 2 &ipic 1 8
>>> + 0000 0 0 3 &ipic 1 8
>>> + 0000 0 0 4 &ipic 1 8
>>> + >;
>>> + interrupt-parent = < &ipic >;
>>> + interrupts = <1 8>;
>>> + bus-range = <0 0>;
>>> + ranges = <02000000 0 A8000000 A8000000 0 10000000
>>> + 01000000 0 00000000 B8000000 0 00800000>;
>>> + clock-frequency = <0>;
>>> + #interrupt-cells = <1>;
>>> + #size-cells = <2>;
>>> + #address-cells = <3>;
>>> + reg = <e0009000 00001000
>>> + a0000000 08000000>;
>>
>> Shouldn't the reg size for the cfg space be 256M?
>
> 256M is a little too big for kernel.
what do you mean too big? Aren't you losing access to some bus/dev/fn
than?
>>> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
>>> platforms/83xx/Kconfig
>>> index 0c61e7a..00154c5 100644
>>> --- a/arch/powerpc/platforms/83xx/Kconfig
>>> +++ b/arch/powerpc/platforms/83xx/Kconfig
>>> @@ -87,3 +87,10 @@ config PPC_MPC837x
>>> select PPC_INDIRECT_PCI
>>> select FSL_SERDES
>>> default y if MPC837x_MDS
>>> +
>>> +config PPC_MPC83XX_PCIE
>>> + bool "MPC837X PCI Express support"
>>> + depends on PCIEPORTBUS && PPC_MPC837x
>>> + default n
>>> + help
>>> + Enables MPC837x PCI express RC mode
>>
>> This should be a hidden config that is just selected by PPC_MPC837x
>> instead of a choice. Also drop the depends on.
>>
>
> In the dts file, the PCIE is default enabled. So, we should provide
> another way to disable the PCIE.
> Modify and recompile the dts is a little unkind to user.
Why do you something beyond CONFIG_PCI. if you don't want PCIe but do
want PCI the extra code for PCIe isn't going to kill you.
>>> diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/
>>> platforms/83xx/mpc83xx.h
>>> index b778cb4..2078da7 100644
>>> --- a/arch/powerpc/platforms/83xx/mpc83xx.h
>>> +++ b/arch/powerpc/platforms/83xx/mpc83xx.h
>>> @@ -43,12 +43,18 @@
>>> #define PORTSCX_PTS_UTMI 0x00000000
>>> #define PORTSCX_PTS_ULPI 0x80000000
>>>
>>> +/* PCIE Registers */
>>> +#define PEX_LTSSM_STAT 0x404
>>> +#define PEX_LTSSM_STAT_L0 0x16
>>> +#define PEX_GCLK_RATIO 0x440
>>> +
>>
>> just move these into the .c file.
>>
>>>
>>> /*
>>> * Declaration for the various functions exported by the
>>> * mpc83xx_* files. Mostly for use by mpc83xx_setup
>>> */
>>> -
>>> -extern int mpc83xx_add_bridge(struct device_node *dev);
>>> +#define PPC_83XX_PCI 0x1
>>> +#define PPC_83XX_PCIE 0x2
>>> +extern int mpc83xx_add_bridge(struct device_node *dev, int flags);
>>> extern void mpc83xx_restart(char *cmd);
>>> extern long mpc83xx_time_init(void);
>>> extern int mpc834x_usb_cfg(void);
>>> diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/
>>> platforms/83xx/pci.c
>>> index 80425d7..0b52b2e 100644
>>> --- a/arch/powerpc/platforms/83xx/pci.c
>>> +++ b/arch/powerpc/platforms/83xx/pci.c
>>> @@ -25,6 +25,8 @@
>>> #include <asm/prom.h>
>>> #include <sysdev/fsl_soc.h>
>>>
>>> +#include "mpc83xx.h"
>>> +
>>> #undef DEBUG
>>>
>>> #ifdef DEBUG
>>> @@ -33,13 +35,157 @@
>>> #define DBG(x...)
>>> #endif
>>>
>>> -int __init mpc83xx_add_bridge(struct device_node *dev)
>>> +#if defined(CONFIG_PPC_MPC83XX_PCIE)
>>> +
>>> +/* PCIE config space Read/Write routines */
>>
>> should really be called something like mpc83xx_pciex_read_config
>>>
>>> +static int direct_read_config_pcie(struct pci_bus *bus,
>>> + uint devfn, int offset, int len, u32 *val)
>>> +{
>>> + struct pci_controller *hose = bus->sysdata;
>>> + void __iomem *cfg_addr;
>>> + u32 bus_no;
>>> +
>>> + if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>> +
>>> + if (ppc_md.pci_exclude_device)
>>> + if (ppc_md.pci_exclude_device(hose, bus->number,
>> devfn))
>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>> +
>>> + switch (len) {
>>> + case 2:
>>> + if (offset & 1)
>>> + return -EINVAL;
>>> + break;
>>> + case 4:
>>> + if (offset & 3)
>>> + return -EINVAL;
>>> + break;
>>> + }
>>
>> fix formatting.
>>
>>>
>>> +
>>> + pr_debug("_read_cfg_pcie: bus=%d devfn=%x off=%x len=%x\n",
>>> + bus->number, devfn, offset, len);
>>> +
>>> + if (bus->number == hose->first_busno) {
>>> + if (devfn & 0xf8)
>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>
>> what is the 0xf8 all about?
>>
>
> The pcie only have one link, so the dev number only can be 0, as well
> the function number can be 0 ~ 7.
I don't follow what the number of links has to do with dev number.
>>> + addr = mbase + (cfg_addr & ~PAGE_MASK);
>>> + hose->cfg_addr = addr;
>>> + hose->ops = &direct_pcie_ops;
>>
>> what's the point of this function, why not just fold it into
>> mpc83xx_setup_pcie
>>
>>>
>>> +}
>>> +
>>> +static void __init mpc83xx_setup_pcie(struct pci_controller *hose,
>>> + struct resource *reg, struct resource
>> *cfg_space)
>>> +{
>>> + void __iomem *hose_cfg_base;
>>> + u32 val;
>>> +
>>> + hose_cfg_base = ioremap(reg->start, reg->end - reg->start +
>> 1);
>>> +
>>> + val = in_le32(hose_cfg_base + PEX_LTSSM_STAT);
>>> + if (val < PEX_LTSSM_STAT_L0)
>>> + hose->indirect_type |=
>> PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>>> +
>>> + setup_direct_pcie(hose, cfg_space->start,
>>> + cfg_space->end - cfg_space->start + 1);
>>> +}
>>> +#endif /* CONFIG_PPC_MPC83XX_PCIE */
>>> +
>>
>> We should do the same think fsl_pci does for primary, its passed
>> into
>> _add_bridge. Also, can we not do what fsl_pci does and use PCI
>> capabilities to determine we are a PCIe controller (and drop passing
>> it in via flags).
>>
>
> The mpc837x PCIE controller is a little different from mpc85xx.
> It can not be access via PCI configure read/write. It only can be
> accessed via memory-mapped read/write from core.
You don't have access to your own config space?
- k
^ permalink raw reply
* [RFC][PATCH] [POWERPC] Allow caching of kmap_atomic page
From: Kumar Gala @ 2007-11-30 9:14 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: linuxppc-dev
Skip updating the kmap_pte and flushing the TLB if the pte we
are about to write is the same as the one we wrote last time we
called kmap_atomic for this km_type.
Also expose the flags to allow a caller to specify their own
flags for things like non-cacheable IO memory.
---
This is the starts of some work Ben and I were discussion to allow us to
use kmap_atomic to access a page size region of PCI CFG space when its
provided as direct MMIO.
We also intend to provide a means to preload the TLB for SW managed TLB
machines.
- k
include/asm-powerpc/highmem.h | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
index f7b21ee..a50bb00 100644
--- a/include/asm-powerpc/highmem.h
+++ b/include/asm-powerpc/highmem.h
@@ -73,10 +73,12 @@ static inline void kunmap(struct page *page)
* be used in IRQ contexts, so in some (very limited) cases we need
* it.
*/
-static inline void *kmap_atomic(struct page *page, enum km_type type)
+static inline void *__kmap_atomic(struct page *page,
+ enum km_type type, unsigned long flags)
{
unsigned int idx;
unsigned long vaddr;
+ pte_t pte;
/* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
pagefault_disable();
@@ -88,12 +90,20 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
#ifdef HIGHMEM_DEBUG
BUG_ON(!pte_none(*(kmap_pte+idx)));
#endif
- set_pte_at(&init_mm, vaddr, kmap_pte+idx, mk_pte(page, kmap_prot));
- flush_tlb_page(NULL, vaddr);
+ pte = mk_pte(page, flags);
+ if (!pte_same(kmap_pte[idx], pte)) {
+ set_pte_at(&init_mm, vaddr, kmap_pte+idx, pte);
+ flush_tlb_page(NULL, vaddr);
+ }
return (void*) vaddr;
}
+static inline void *kmap_atomic(struct page *page, enum km_type type)
+{
+ return __kmap_atomic(page, type, kmap_prot);
+}
+
static inline void kunmap_atomic(void *kvaddr, enum km_type type)
{
#ifdef HIGHMEM_DEBUG
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Kumar Gala @ 2007-11-30 9:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071130061155.41D71DDF5F@ozlabs.org>
On Nov 30, 2007, at 12:10 AM, Benjamin Herrenschmidt wrote:
> This adds to the previous 2 patches the support for the 4xx PCI
> Express
> cells as found in the 440SPe revA, revB and 405EX.
>
> Unfortunately, due to significant differences between these, and other
> interesting "features" of those pieces of HW, the code isn't as simple
> as it is for PCI and PCI-X and some of the functions differ
> significantly
> between the 3 implementations. Thus, not only this code can only
> support
> those 3 implementations for now and will refuse to operate on any
> other,
> but there are added ifdef's to avoid the bloat of building a fairly
> large
> amount of code on platforms that don't need it.
>
> Also, this code currently only supports fully initializing root
> complex
> nodes, not endpoint. Some more code will have to be lifted from the
> arch/ppc implementation to add the endpoint support, though it's
> mostly
> differences in memory mapping, and the question on how to represent
> endpoint mode PCI in the device-tree is thus open.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> 440SPeA is untested, 440SPeB is slightly tested (with a sky2 network
> card on
> port 0 only for now) and 405EX is untested.
>
> arch/powerpc/Kconfig | 1
> arch/powerpc/sysdev/Kconfig | 8
> arch/powerpc/sysdev/ppc4xx_pci.c | 927 +++++++++++++++++++++++++++++
> +++++++++-
> arch/powerpc/sysdev/ppc4xx_pci.h | 237 +++++++++
> 4 files changed, 1172 insertions(+), 1 deletion(-)
Is it intentional that you dont support ppc_md.pci_exclude_device()?
- k
^ permalink raw reply
* Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
From: Benjamin Herrenschmidt @ 2007-11-30 9:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <0472C239-D0C8-43FE-9996-1C28584EFBAD@kernel.crashing.org>
> Is it intentional that you dont support ppc_md.pci_exclude_device()?
More like I didn't have a need for it... that can easily be fixed when
it arises.
Cheers,
Ben.
^ permalink raw reply
* Re: Init hangs on Xilinx4
From: David H. Lynch Jr. @ 2007-11-30 9:27 UTC (permalink / raw)
To: schardt, linuxppc-embedded
In-Reply-To: <474ED262.5010408@fz-juelich.de>
schardt wrote:
> Hi David,
>
> thanks for your help.
>
>>>
>>>
>>>
>> I am presuming you are using PK's UartLite driver.
>>
>>
> I use the Kernel from Grant's git server, and let me look... yes its
> from Peter Korsgaard :)
>
>
>> Try printing out membase some time possibly in ulite_console_setup.
>> If the value of membase is 0x406000000 that is your problem.
>> It should be something like 0xfdxxxxxxxx I think.
>>
>>
> Mmmh, my EDK Project maps the uartlite to 0x40600000, so i think its
> okay. but i can try it at a higher adress
>
> it is very strange. i use the same hardware setup and boot from
> system-ace without any problems.
Another posibility that I thought of since you are using Peter K's
driver.
If you have any interrupt problems I think you could get your
current behavior.
During boot console I/O is not interrupt driven. When the OS sends a
string the whole string gets sent and then the console write exits,
but very close to running init, the console switches to using the
full driver. PK's driver is interrupt driven. If the UartLite TX FIFO
empty interrupt
is broke in anyway, it will send until the first time the FIFO fills
and then stop. The interrupt could be broken in firmware - not properly
connected to the PIC, or it could be broken in software - however your
driver is receiving its interrupt configuration, the driver may be
receiving the incorrect intterrupt #.
At one point I tried to add timer driven polling to PK's driver
similar to that in the 8250 and others - we have clients that run
without any PIC,
but trying to figure out what was going on proved sufficiently
difficult I just went back to my own driver.
>
>
>
> Regards
> Georg
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Li Li @ 2007-11-30 9:37 UTC (permalink / raw)
To: Gala Kumar; +Cc: linuxppc-dev, Li Tony
In-Reply-To: <7DF684FC-A53A-4F4D-903F-D50F1E0A486A@freescale.com>
On Fri, 2007-11-30 at 17:05 +0800, Gala Kumar wrote:
> >>> +
> >>> + pci2@e0009000 {
> >>
> >> I agree w/Olof. This should be pcie@e0009000
> >>>
> >>> + interrupt-map-mask = <f800 0 0 7>;
> >>> + msi-available-ranges = <43 4 51 52 56 57 58 59>;
> >>> + interrupt-map = <
> >>> + 0000 0 0 1 &ipic 1 8
> >>> + 0000 0 0 2 &ipic 1 8
> >>> + 0000 0 0 3 &ipic 1 8
> >>> + 0000 0 0 4 &ipic 1 8
> >>> + >;
> >>> + interrupt-parent = < &ipic >;
> >>> + interrupts = <1 8>;
> >>> + bus-range = <0 0>;
> >>> + ranges = <02000000 0 A8000000 A8000000 0 10000000
> >>> + 01000000 0 00000000 B8000000 0 00800000>;
> >>> + clock-frequency = <0>;
> >>> + #interrupt-cells = <1>;
> >>> + #size-cells = <2>;
> >>> + #address-cells = <3>;
> >>> + reg = <e0009000 00001000
> >>> + a0000000 08000000>;
> >>
> >> Shouldn't the reg size for the cfg space be 256M?
> >
> > 256M is a little too big for kernel.
>
> what do you mean too big? Aren't you losing access to some
> bus/dev/fn
> than?
If do it standard, a 256M config space, at least 256M mem space and 16M
io space are needed for each PCIE controller.
To allocate PCIE window, the window size only can be 512M or 1G.
If we choose 1G space, two PCIE controller needs 2G space.
We do not have 2G free physical space now. Usually, we use upper 128M
configure space. So, we have to cut down the config space.
>
> >>> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> >>> platforms/83xx/Kconfig
> >>> index 0c61e7a..00154c5 100644
> >>> --- a/arch/powerpc/platforms/83xx/Kconfig
> >>> +++ b/arch/powerpc/platforms/83xx/Kconfig
> >>> @@ -87,3 +87,10 @@ config PPC_MPC837x
> >>> select PPC_INDIRECT_PCI
> >>> select FSL_SERDES
> >>> default y if MPC837x_MDS
> >>> +
> >>> +config PPC_MPC83XX_PCIE
> >>> + bool "MPC837X PCI Express support"
> >>> + depends on PCIEPORTBUS && PPC_MPC837x
> >>> + default n
> >>> + help
> >>> + Enables MPC837x PCI express RC mode
> >>
> >> This should be a hidden config that is just selected by
> PPC_MPC837x
> >> instead of a choice. Also drop the depends on.
> >>
> >
> > In the dts file, the PCIE is default enabled. So, we should provide
> > another way to disable the PCIE.
> > Modify and recompile the dts is a little unkind to user.
>
> Why do you something beyond CONFIG_PCI. if you don't want PCIe but
> do
> want PCI the extra code for PCIe isn't going to kill you.
>
Here is a little complex. The MPC837xE board needs a carrier board to
extend PCIE slot. If user does not populate carrier board onto MPC837xE
board and do PCIE scan, the system will halt.
I just want to provide a easy way to disable the PCIe other than modify
and recompile the dts.
> >>> diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h
> b/arch/powerpc/
> >>> platforms/83xx/mpc83xx.h
> >>> index b778cb4..2078da7 100644
> >>> --- a/arch/powerpc/platforms/83xx/mpc83xx.h
> >>> +++ b/arch/powerpc/platforms/83xx/mpc83xx.h
> >>> @@ -43,12 +43,18 @@
> >>> #define PORTSCX_PTS_UTMI 0x00000000
> >>> #define PORTSCX_PTS_ULPI 0x80000000
> >>>
> >>> +/* PCIE Registers */
> >>> +#define PEX_LTSSM_STAT 0x404
> >>> +#define PEX_LTSSM_STAT_L0 0x16
> >>> +#define PEX_GCLK_RATIO 0x440
> >>> +
> >>
> >> just move these into the .c file.
ok.
> >>
> >>>
> >>> /*
> >>> * Declaration for the various functions exported by the
> >>> * mpc83xx_* files. Mostly for use by mpc83xx_setup
> >>> */
> >>> -
> >>> -extern int mpc83xx_add_bridge(struct device_node *dev);
> >>> +#define PPC_83XX_PCI 0x1
> >>> +#define PPC_83XX_PCIE 0x2
> >>> +extern int mpc83xx_add_bridge(struct device_node *dev, int
> flags);
> >>> extern void mpc83xx_restart(char *cmd);
> >>> extern long mpc83xx_time_init(void);
> >>> extern int mpc834x_usb_cfg(void);
> >>> diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/
> >>> platforms/83xx/pci.c
> >>> index 80425d7..0b52b2e 100644
> >>> --- a/arch/powerpc/platforms/83xx/pci.c
> >>> +++ b/arch/powerpc/platforms/83xx/pci.c
> >>> @@ -25,6 +25,8 @@
> >>> #include <asm/prom.h>
> >>> #include <sysdev/fsl_soc.h>
> >>>
> >>> +#include "mpc83xx.h"
> >>> +
> >>> #undef DEBUG
> >>>
> >>> #ifdef DEBUG
> >>> @@ -33,13 +35,157 @@
> >>> #define DBG(x...)
> >>> #endif
> >>>
> >>> -int __init mpc83xx_add_bridge(struct device_node *dev)
> >>> +#if defined(CONFIG_PPC_MPC83XX_PCIE)
> >>> +
> >>> +/* PCIE config space Read/Write routines */
> >>
> >> should really be called something like mpc83xx_pciex_read_config
> >>>
> >>> +static int direct_read_config_pcie(struct pci_bus *bus,
> >>> + uint devfn, int offset, int len, u32 *val)
> >>> +{
> >>> + struct pci_controller *hose = bus->sysdata;
> >>> + void __iomem *cfg_addr;
> >>> + u32 bus_no;
> >>> +
> >>> + if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> >>> + return PCIBIOS_DEVICE_NOT_FOUND;
> >>> +
> >>> + if (ppc_md.pci_exclude_device)
> >>> + if (ppc_md.pci_exclude_device(hose, bus->number,
> >> devfn))
> >>> + return PCIBIOS_DEVICE_NOT_FOUND;
> >>> +
> >>> + switch (len) {
> >>> + case 2:
> >>> + if (offset & 1)
> >>> + return -EINVAL;
> >>> + break;
> >>> + case 4:
> >>> + if (offset & 3)
> >>> + return -EINVAL;
> >>> + break;
> >>> + }
> >>
> >> fix formatting.
> >>
> >>>
> >>> +
> >>> + pr_debug("_read_cfg_pcie: bus=%d devfn=%x off=%x len=%x\n",
> >>> + bus->number, devfn, offset, len);
> >>> +
> >>> + if (bus->number == hose->first_busno) {
> >>> + if (devfn & 0xf8)
> >>> + return PCIBIOS_DEVICE_NOT_FOUND;
> >>
> >> what is the 0xf8 all about?
> >>
> >
> > The pcie only have one link, so the dev number only can be 0, as
> well
> > the function number can be 0 ~ 7.
>
> I don't follow what the number of links has to do with dev number.
The PCIE only have one link that mean one PCIE bus only can have one
device populate on it. The dev number of this device must be 0. If the
device number is not 0, we consider it is a error.
>
> >>> + addr = mbase + (cfg_addr & ~PAGE_MASK);
> >>> + hose->cfg_addr = addr;
> >>> + hose->ops = &direct_pcie_ops;
> >>
> >> what's the point of this function, why not just fold it into
> >> mpc83xx_setup_pcie
> >>
> >>>
> >>> +}
> >>> +
> >>> +static void __init mpc83xx_setup_pcie(struct pci_controller
> *hose,
> >>> + struct resource *reg, struct resource
> >> *cfg_space)
> >>> +{
> >>> + void __iomem *hose_cfg_base;
> >>> + u32 val;
> >>> +
> >>> + hose_cfg_base = ioremap(reg->start, reg->end - reg->start +
> >> 1);
> >>> +
> >>> + val = in_le32(hose_cfg_base + PEX_LTSSM_STAT);
> >>> + if (val < PEX_LTSSM_STAT_L0)
> >>> + hose->indirect_type |=
> >> PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> >>> +
> >>> + setup_direct_pcie(hose, cfg_space->start,
> >>> + cfg_space->end - cfg_space->start + 1);
> >>> +}
> >>> +#endif /* CONFIG_PPC_MPC83XX_PCIE */
> >>> +
> >>
> >> We should do the same think fsl_pci does for primary, its passed
> >> into
> >> _add_bridge. Also, can we not do what fsl_pci does and use PCI
> >> capabilities to determine we are a PCIe controller (and drop
> passing
> >> it in via flags).
> >>
> >
> > The mpc837x PCIE controller is a little different from mpc85xx.
> > It can not be access via PCI configure read/write. It only can be
> > accessed via memory-mapped read/write from core.
>
> You don't have access to your own config space?
>
I can access it but can not via standard pci configure routine.
So, we use different way to access PCI and PCIE. If we want access PCI
capabilities, we must know it is PCI controller or PCIE controller
first.
- Tony
> - k
>
^ permalink raw reply
* RE: [PATCH v7 9/9] add MPC837x MDS board default device tree
From: Li Yang @ 2007-11-30 9:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3E2C1CAC-3BBE-404F-B678-FE4504C7B45D@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, November 30, 2007 8:44 AM
> To: Li Yang
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v7 9/9] add MPC837x MDS board default device tree
>=20
>=20
> On Oct 19, 2007, at 6:38 AM, Li Yang wrote:
>=20
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > Updated pci node.
> > arch/powerpc/boot/dts/mpc8377_mds.dts | 282=20
> ++++++++++++++++++++++++
> > +++++++
> > arch/powerpc/boot/dts/mpc8378_mds.dts | 264=20
> ++++++++++++++++++++++++
> > +++++
> > arch/powerpc/boot/dts/mpc8379_mds.dts | 300=20
> ++++++++++++++++++++++++
> > +++++++++
> > 3 files changed, 846 insertions(+), 0 deletions(-) create=20
> mode 100644=20
> > arch/powerpc/boot/dts/mpc8377_mds.dts
> > create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
> > create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
>=20
> Can you make the following updates:
>=20
> * Drop serdes and phy-handles
> * Update sata nodes:
>=20
> + sata@19000 {
> + compatible =3D "fsl,mpc8315-sata", "fsl,sata-pq2pro;
> + reg =3D <19000 1000>;
> + interrupts =3D <2d 8>;
> + interrupt-parent =3D < &ipic >;
> + };
>=20
> * Added labels for ethernet (enet), serial, pci
>=20
> (some examples below):
I will make the changes and update you later.
- Leo
^ permalink raw reply
* RE: [PATCH v7 7/9] ipic: clean up unsupported ack operations
From: Li Yang @ 2007-11-30 10:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <0BCAE755-0506-405D-BFCA-94C2261CBE30@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, November 30, 2007 8:36 AM
> To: Li Yang
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v7 7/9] ipic: clean up unsupported ack operations
>=20
>=20
> On Oct 19, 2007, at 6:38 AM, Li Yang wrote:
>=20
> > IPIC controller doesn't support ack operations. The=20
> pending registers=20
> > are read-only. The patch removes ack operations which are=20
> not needed.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > arch/powerpc/sysdev/ipic.c | 40 +=20
> > +--------------------------------------
> > 1 files changed, 2 insertions(+), 38 deletions(-)
>=20
> applied.
Hi Kumar,
Please hold on this one. Actually external interrupts in edge mode need
this ack operation. But in most cases (level triggered) ack is not
needed. I will provide an updated patch later on to take care both
trigger modes. Thanks.
- Leo
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-30 10:17 UTC (permalink / raw)
To: cbou; +Cc: Olof Johansson, linuxppc-dev, Arnd Bergmann, linux-ide
In-Reply-To: <20071129005440.GA2235@zarina>
Anton Vorontsov wrote:
> Remaining question: any preferred name for that property? pio-mode okay?
> It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
I've already suggested "generic". A name "simple" also comes to my mind.
WBR, Sergei
^ permalink raw reply
* CPM2 USB host driver
From: Laurent Pinchart @ 2007-11-30 10:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mike
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
Hi everybody,
Linux USB host support for the CPM, CPM2 and CPM2 pro is far from complete.
Many people showed interest on this list (and on linuxppc-embedded) in the
past, but nobody managed to complete a driver and get it merged.
As I need USB host support on my MPC8248 (CPM2), I decided to scratch the itch
and try to get a working driver that could be merged upstream. This mail
describes my plans to make sure the code I write will be useful for other
people.
The driver will be based on the cpm2usb project (http://cpm2usb.sf.net/). As I
don't own any CPM1-based platform, I will convert the driver to use the CPM2
transaction-level interface, thus making it incompatible with the CPM1. CPM1
support could be added back later. There is no planned release date, and more
urgent projects could put this development on hold.
Comments are welcome (and contributions too, especially in the form of a
working driver :-)).
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-30 10:58 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Olof Johansson, cbou, linux-ide, Arnd Bergmann, linuxppc-dev
In-Reply-To: <474FE332.8080103@ru.mvista.com>
On Fri, Nov 30, 2007 at 01:17:22PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >Remaining question: any preferred name for that property? pio-mode okay?
> >It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
>
> I've already suggested "generic". A name "simple" also comes to my mind.
You've misread my question. I didn't ask about driver name, but pio-mode
property.
As for the driver name, it doesn't matter at all, as I've said already:
it's Linux specific anyway, and another compatible properties could be
added at any time, to a device tree and/or to the OF driver itself (if
some real OpenFirmware will pass some meaningful compatible property
that we'll have to match in that driver).
"generic" name is also bad one, it's confusing wrt ata_generic.c
driver (PCI). "simple" name doesn't tell anything at all. So, I'd
rather stick with -platform name.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-30 11:04 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071129211912.46da8f5b@i1501.lan.towertech.it>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
Hi, Alessandro!
Alessandro Zummo schrieb:
> On Thu, 29 Nov 2007 21:03:49 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>>>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>>>> and it also breaks the deprecated SENSORS_DS1337. :-(
>> One more update:
>> I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to
>> verify that the problem with the RTC still persists.
>>
>> I startet to bisect, but ran quickly into other crashes.
>> (no console on 2.6.23-rc2 and 2.6.23)
>> So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and
>> and 2.6.24-rc2-ge6a5c27f.
>
> did you tried compiling it modular? you might even check with
> i2cdetect if the chip is there
A kernel upgrade doesn't make the chip to disappear ;-)
The I2C bus is/was basically working fine all the time... see below.
Modular doesn't make sense to me, because the filesystem check starts
to complain when last mount time was way to far in the past or in
the future. But I will try...
I can:
$ uname -a
Linux fox_1 2.6.24-rc3-g09f345da #1 Thu Nov 29 21:21:39 CET 2007 ppc e500 GNU/Linux
$ i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
At 0x68 is the DS1337,
at 0x48 I have an LM75
at 0x50 and 0x57 there is some EEPROM attached
$ i2cdump 0 0x68 b
Error: Could not set address to 0x68: Device or resource busy
That would tell me AFAICT that the ds1307 driver claimed that
address already... But...
Well, I've attached the config again.
(Note, I enabled the SENSORS_x during my manual bisecting again to
find where it doesn't work anymore. Disabling them didn't work for
sure, but will retry now...)
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 6922 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-30 11:05 UTC (permalink / raw)
To: avorontsov; +Cc: Olof Johansson, cbou, linux-ide, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071130105849.GA10840@localhost.localdomain>
Anton Vorontsov wrote:
>>>Remaining question: any preferred name for that property? pio-mode okay?
>>>It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
>> I've already suggested "generic". A name "simple" also comes to my mind.
> You've misread my question. I didn't ask about driver name, but pio-mode
> property.
I'm OK with "pio-mode" then. Just don't think it makes much sense in the
context of this driver which has no provision for the programming the mode
timings (and if there were some provision, the *generic* platform driver
couldn't handle it anyway).
> As for the driver name, it doesn't matter at all, as I've said already:
> it's Linux specific anyway, and another compatible properties could be
> added at any time, to a device tree and/or to the OF driver itself (if
> some real OpenFirmware will pass some meaningful compatible property
> that we'll have to match in that driver).
> "generic" name is also bad one, it's confusing wrt ata_generic.c
> driver (PCI).
The "compatible" property doesn't have to contain the driver name, so
there should be no confusion with the driver names. It's just different name
spaces. :-)
> "simple" name doesn't tell anything at all. So, I'd rather stick with -platform name.
Well, those two should be "generic-ata" and "simple-ata" of course. And it
*does* tell that the driver just provides taskfile control, without the
transfer timing control and other fancy stuff...
> Thanks,
MBR, Sergei
^ permalink raw reply
* Re: CPM2 USB host driver
From: Vitaly Bordug @ 2007-11-30 11:16 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, mike
In-Reply-To: <200711301145.52926.laurentp@cse-semaphore.com>
On Fri, 30 Nov 2007 11:45:49 +0100
Laurent Pinchart wrote:
> Hi everybody,
>
> Linux USB host support for the CPM, CPM2 and CPM2 pro is far from
> complete. Many people showed interest on this list (and on
> linuxppc-embedded) in the past, but nobody managed to complete a
> driver and get it merged.
>
that is mainly because of its semi-software nature. However, any approach
would be helpful I beleive.
> As I need USB host support on my MPC8248 (CPM2), I decided to scratch
> the itch and try to get a working driver that could be merged
> upstream. This mail describes my plans to make sure the code I write
> will be useful for other people.
>
> The driver will be based on the cpm2usb project
> (http://cpm2usb.sf.net/). As I don't own any CPM1-based platform, I
> will convert the driver to use the CPM2 transaction-level interface,
> thus making it incompatible with the CPM1. CPM1 support could be
> added back later. There is no planned release date, and more urgent
> projects could put this development on hold.
>
> Comments are welcome (and contributions too, especially in the form
> of a working driver :-)).
>
I may have some WIP material left, will try to dig it out...
> Best regards,
>
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Alessandro Zummo @ 2007-11-30 11:20 UTC (permalink / raw)
To: rtc-linux; +Cc: linuxppc-embedded
In-Reply-To: <474FEE20.6070606@anagramm.de>
On Fri, 30 Nov 2007 12:04:00 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:
> A kernel upgrade doesn't make the chip to disappear ;-)
> The I2C bus is/was basically working fine all the time... see below.
you never know those pesky chips ;)
> Modular doesn't make sense to me, because the filesystem check starts
> to complain when last mount time was way to far in the past or in
> the future. But I will try...
It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
it should work anyway, but who knows...
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-30 11:45 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Olof Johansson, cbou, linux-ide, Arnd Bergmann, linuxppc-dev
In-Reply-To: <474FEE5D.2030905@ru.mvista.com>
On Fri, Nov 30, 2007 at 02:05:01PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>Remaining question: any preferred name for that property? pio-mode okay?
> >>>It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
>
> >> I've already suggested "generic". A name "simple" also comes to my mind.
>
> >You've misread my question. I didn't ask about driver name, but pio-mode
> >property.
>
> I'm OK with "pio-mode" then. Just don't think it makes much sense in the
> context of this driver which has no provision for the programming the mode
> timings (and if there were some provision, the *generic* platform driver
> couldn't handle it anyway).
What sense it makes then?.. We're specifying bus limitations wrt
PIO modes.
Oh, I think you meant that bus can't be reconfigured by generic
driver, that's true. But I didn't mean this as a purpose for
pio-mode property (though it still could be used for that
purpose by other drivers).
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-30 11:43 UTC (permalink / raw)
To: avorontsov; +Cc: Olof Johansson, cbou, linux-ide, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071130105849.GA10840@localhost.localdomain>
Anton Vorontsov wrote:
>>>Remaining question: any preferred name for that property? pio-mode okay?
>>>It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
>> I've already suggested "generic". A name "simple" also comes to my mind.
> You've misread my question. I didn't ask about driver name, but pio-mode
> property.
Probably "max-pio-mode" is a better variant.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-30 12:09 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Olof Johansson, cbou, linux-ide, Arnd Bergmann, linuxppc-dev
In-Reply-To: <474FF776.1060803@ru.mvista.com>
On Fri, Nov 30, 2007 at 02:43:50PM +0300, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
> >>>Remaining question: any preferred name for that property? pio-mode okay?
> >>>It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
>
> >> I've already suggested "generic". A name "simple" also comes to my mind.
>
> >You've misread my question. I didn't ask about driver name, but pio-mode
> >property.
>
> Probably "max-pio-mode" is a better variant.
Why? pio-mode in pata-platform context is just something highly
dependent on hardware, can not be touched. And we're passing
pio-mode information from the hardware dependent source --
device tree.
The only difference between pata-platform's max-pio-mode and
dedicated ata driver's pio-mode is that that for the first case
bus already configured for specified mode, and for the second
case dedicated driver should actually use this information
to configure hardware.
No need for max- prefix, I think.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: CPM2 USB host driver
From: Laurent Pinchart @ 2007-11-30 12:30 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, mike
In-Reply-To: <20071130141638.4e00258d@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> On Fri, 30 Nov 2007 11:45:49 +0100
>
> Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Linux USB host support for the CPM, CPM2 and CPM2 pro is far from
> > complete. Many people showed interest on this list (and on
> > linuxppc-embedded) in the past, but nobody managed to complete a
> > driver and get it merged.
>
> that is mainly because of its semi-software nature. However, any approach
> would be helpful I beleive.
The CPM/CPM2 USB host controller does indeed put some pressure on the CPU. The
PowerQuick III family is much better in that respect as its USB host
controller is EHCI compliant.
We plan to use an external USB host controller when we will redesign the
hardware. My goal in writting a CPM2 USB host driver is mainly to enable the
hardware team to perform EMC testing on the USB interface. I don't expect it
to be shipped to any client, but I'd still like to get it merged (if I
complete the project) as I don't like throwing away useful code.
> > As I need USB host support on my MPC8248 (CPM2), I decided to scratch
> > the itch and try to get a working driver that could be merged
> > upstream. This mail describes my plans to make sure the code I write
> > will be useful for other people.
> >
> > The driver will be based on the cpm2usb project
> > (http://cpm2usb.sf.net/). As I don't own any CPM1-based platform, I
> > will convert the driver to use the CPM2 transaction-level interface,
> > thus making it incompatible with the CPM1. CPM1 support could be
> > added back later. There is no planned release date, and more urgent
> > projects could put this development on hold.
> >
> > Comments are welcome (and contributions too, especially in the form
> > of a working driver :-)).
>
> I may have some WIP material left, will try to dig it out...
Should I wait ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: CPM2 USB host driver
From: Anton Vorontsov @ 2007-11-30 12:48 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: mike, linuxppc-dev
In-Reply-To: <200711301330.25100.laurentp@cse-semaphore.com>
On Fri, Nov 30, 2007 at 01:30:18PM +0100, Laurent Pinchart wrote:
> On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> > On Fri, 30 Nov 2007 11:45:49 +0100
> >
> > Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > Linux USB host support for the CPM, CPM2 and CPM2 pro is far from
> > > complete. Many people showed interest on this list (and on
> > > linuxppc-embedded) in the past, but nobody managed to complete a
> > > driver and get it merged.
> >
> > that is mainly because of its semi-software nature. However, any approach
> > would be helpful I beleive.
>
> The CPM/CPM2 USB host controller does indeed put some pressure on the CPU. The
> PowerQuick III family is much better in that respect as its USB host
> controller is EHCI compliant.
I didn't yet compare with CPM/CPM2, but I wonder if PQIIPro (MPC8360E)
USB controller is similar to cpms?..
I tried to forward-port FHCI from Freescale 2.6.11 kernels. Twice.
But these efforts always stumbled over more important tasks.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: CPM2 USB host driver
From: Vitaly Bordug @ 2007-11-30 13:00 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, mike
In-Reply-To: <20071130124801.GA13141@localhost.localdomain>
On Fri, 30 Nov 2007 15:48:01 +0300
Anton Vorontsov wrote:
> On Fri, Nov 30, 2007 at 01:30:18PM +0100, Laurent Pinchart wrote:
> > On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> > > On Fri, 30 Nov 2007 11:45:49 +0100
> > >
> > > Laurent Pinchart wrote:
> > > > Hi everybody,
> > > >
> > > > Linux USB host support for the CPM, CPM2 and CPM2 pro is far
> > > > from complete. Many people showed interest on this list (and on
> > > > linuxppc-embedded) in the past, but nobody managed to complete a
> > > > driver and get it merged.
> > >
> > > that is mainly because of its semi-software nature. However, any
> > > approach would be helpful I beleive.
> >=20
> > The CPM/CPM2 USB host controller does indeed put some pressure on
> > the CPU. The PowerQuick III family is much better in that respect
> > as its USB host controller is EHCI compliant.
>=20
> I didn't yet compare with CPM/CPM2, but I wonder if PQIIPro (MPC8360E)
> USB controller is similar to cpms?..
>
=46rom what I recall, it is similar, but ucc usb should work fine,
at least according to RM it does all the necessary things in hw
so the cpu isn't hogged with say SOF generation.
> I tried to forward-port FHCI from Freescale 2.6.11 kernels. Twice.
> But these efforts always stumbled over more important tasks.
>=20
--=20
Sincerely, Vitaly
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox