* Re: /proc/bus/pci and domains
From: Martin Mares @ 2008-02-14 21:45 UTC (permalink / raw)
To: David Miller; +Cc: greg, linux-pci, paulus, anton, linuxppc-dev
In-Reply-To: <20080214.134305.237408044.davem@davemloft.net>
Hi!
> > Would it be acceptable for the PPC folks to modify the code to add
> > domain numbers to the device numbers in /proc/bus/pci/devices in the
> > same format as the bus directories already have?
>
> Be careful, things like the X server parse that file, and X's
> parser does not expect domain numbers there so you will break
> things :-(
Yes, but neither does it expect domain numbers in the directory names,
I guess :-)
But thanks for the tip, I will check X before I post the patch.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A student who changes the course of history is probably taking an exam.
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: David Miller @ 2008-02-14 21:43 UTC (permalink / raw)
To: mj; +Cc: greg, linux-pci, paulus, anton, linuxppc-dev
In-Reply-To: <mj+md-20080214.093558.3352.nikam@ucw.cz>
From: Martin Mares <mj@ucw.cz>
Date: Thu, 14 Feb 2008 10:40:22 +0100
> Would it be acceptable for the PPC folks to modify the code to add
> domain numbers to the device numbers in /proc/bus/pci/devices in the
> same format as the bus directories already have?
Be careful, things like the X server parse that file, and X's
parser does not expect domain numbers there so you will break
things :-(
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: Josh Boyer @ 2008-02-14 21:24 UTC (permalink / raw)
To: Becky Bruce; +Cc: sparclinux, linuxppc-dev, David Miller, linux-kernel
In-Reply-To: <38133B3C-75A2-4465-9484-7BF8E7E85D1D@freescale.com>
On Thu, 14 Feb 2008 14:58:22 -0600
Becky Bruce <becky.bruce@freescale.com> wrote:
>
> On Feb 13, 2008, at 7:09 PM, David Miller wrote:
>
> >
> > I've taken into consideration the various feedback, and
> > ported the bug fix and other LMB patches posted recently
> > in an effort to keep the patch churn by others down wrt.
> > my moving of these files.
> >
> > 1) Use HAVE_LMB as suggested by Sam.
> >
> > 2) Fix potential build errors wrt. asm/prom.h dependencies.
> >
> > My algorithm was:
> >
> > a) If the file only included asm/lmb.h I added an include
> > of both linux/lmb.c and asm/prom.h
> >
> > b) If the file already includes asm/prom.h, I merely
> > changed the asm/lmb.h to linux/lmb.h
> >
> > Header include mimimizations can be done as followon patches.
> >
> > 3) Integrate Kumar Gala's initial region fix.
> >
> > 4) Integrate Becky Bruce's large physical addressing change,
> > but using u64 instead of phys_addr_t.
> >
> > It's all at:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git
> >
> > like before.
>
>
> Thanks for picking up the patches from Kumar and myself and fitting
> them into your series - this is much appreciated. FYI, I applied the
> entire patch series to my local tree and test-booted both mpc8641 and
> mpc8568mds and both build and boot cleanly. I also built pasemi and
> ebony, those build cleanly as well.
I plan on actually testing this on Ebony, Walnut, and Bamboo either
later tonight or tomorrow. I don't expect many issues.
Dave, those above boards would cover the build of PowerPC 4xx CPU cores.
Just an FYI.
josh
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: Becky Bruce @ 2008-02-14 20:58 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.170938.34536425.davem@davemloft.net>
On Feb 13, 2008, at 7:09 PM, David Miller wrote:
>
> I've taken into consideration the various feedback, and
> ported the bug fix and other LMB patches posted recently
> in an effort to keep the patch churn by others down wrt.
> my moving of these files.
>
> 1) Use HAVE_LMB as suggested by Sam.
>
> 2) Fix potential build errors wrt. asm/prom.h dependencies.
>
> My algorithm was:
>
> a) If the file only included asm/lmb.h I added an include
> of both linux/lmb.c and asm/prom.h
>
> b) If the file already includes asm/prom.h, I merely
> changed the asm/lmb.h to linux/lmb.h
>
> Header include mimimizations can be done as followon patches.
>
> 3) Integrate Kumar Gala's initial region fix.
>
> 4) Integrate Becky Bruce's large physical addressing change,
> but using u64 instead of phys_addr_t.
>
> It's all at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git
>
> like before.
Thanks for picking up the patches from Kumar and myself and fitting
them into your series - this is much appreciated. FYI, I applied the
entire patch series to my local tree and test-booted both mpc8641 and
mpc8568mds and both build and boot cleanly. I also built pasemi and
ebony, those build cleanly as well.
Cheers,
Becky
^ permalink raw reply
* Re: High resolution timer support in 2.6.24+ for MPC831x?
From: Scott Wood @ 2008-02-14 20:51 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: linuxppc-embedded
In-Reply-To: <c384c5ea0802141226m630fcc11h60627cde75cb8b0e@mail.gmail.com>
Leon Woestenberg wrote:
> Hello all,
>
> although I can enable high res timers in 2.6.24, the item note says it
> does nothing if the platform does not have support for it.
>
> My platform is a MPC8313E-RDB, and I suspect no high res clock source
> implementation exists for it in 2.6.24, because
> clock_getres(CLOCK_REALTIME,) gives me 1/HZ.
>
> Is this correct and/or is anything in the works?
The timebase/decrementer can be used as a high clock source on virtually
all powerpc chips; I tried clock_getres(CLOCK_REALTIME) on an 8313erdb,
and I got 1 ns. Did you turn on CONFIG_HIGH_RES_TIMERS?
-Scott
^ permalink raw reply
* Re: [PATCH 05/11] ppc/mpc8xx: remove ppc_ide_md hooks
From: Vitaly Bordug @ 2008-02-14 20:46 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080214003656.12879.21968.sendpatchset@localhost.localdomain>
On Thu, 14 Feb 2008 01:36:56 +0100
Bartlomiej Zolnierkiewicz wrote:
> * Initialize IDE ports in mpc8xx_ide_probe().
>
> * Remove m8xx_ide_init() and ppc_ide_md hooks - no need for them
> (IDE mpc8xx host driver takes care of all this setup).
>
> * Remove needless 'if (irq)' and 'if (data_port >= MAX_HWIFS)' checks
> from m8xx_ide_init_hwif_ports().
>
> * Remove 'ctrl_port' and 'irq' arguments from
> m8xx_ide_init_hwif_ports().
>
> * Rename m8xx_ide_init_hwif_ports() to m8xx_ide_init_ports().
>
> * Add __init tag to m8xx_ide_init_ports().
>
> This patch fixes hwif->irq always being overriden to 0 (==
> auto-probe, is this even working on PPC?) because of
> ide_init_default_irq() call in ide.c.
>
> There should be no other functional changes.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
> arch/ppc/syslib/m8xx_setup.c | 6 ---
> drivers/ide/ppc/mpc8xx.c | 86
> +++++++++++-------------------------------- 2 files changed, 22
> insertions(+), 70 deletions(-)
>
> Index: b/arch/ppc/syslib/m8xx_setup.c
> ===================================================================
> --- a/arch/ppc/syslib/m8xx_setup.c
> +++ b/arch/ppc/syslib/m8xx_setup.c
> @@ -87,8 +87,6 @@ void m8xx_calibrate_decr(void);
>
> unsigned char __res[sizeof(bd_t)];
>
> -extern void m8xx_ide_init(void);
> -
> extern unsigned long find_available_memory(void);
> extern void m8xx_cpm_reset(void);
> extern void m8xx_wdt_handler_install(bd_t *bp);
> @@ -474,8 +472,4 @@ platform_init(unsigned long r3, unsigned
>
> ppc_md.find_end_of_memory = m8xx_find_end_of_memory;
> ppc_md.setup_io_mappings = m8xx_map_io;
> -
> -#if defined(CONFIG_BLK_DEV_MPC8xx_IDE)
> - m8xx_ide_init();
> -#endif
> }
> Index: b/drivers/ide/ppc/mpc8xx.c
> ===================================================================
> --- a/drivers/ide/ppc/mpc8xx.c
> +++ b/drivers/ide/ppc/mpc8xx.c
> @@ -99,32 +99,6 @@ static int _slot_ = -1; /*
> will be rea /* Make clock cycles and always round up */
> #define PCMCIA_MK_CLKS( t, T ) (( (t) * ((T)/1000000) + 999U ) /
> 1000U )
> -
> -
> -/*
> - * IDE stuff.
> - */
> -static int
> -m8xx_ide_default_irq(unsigned long base)
> -{
> -#ifdef CONFIG_BLK_DEV_MPC8xx_IDE
> - if (base >= MAX_HWIFS)
> - return 0;
> -
> - printk("[%d] m8xx_ide_default_irq
> %d\n",__LINE__,ioport_dsc[base].irq);
> -
> - return (ioport_dsc[base].irq);
> -#else
> - return 9;
> -#endif
> -}
> -
> -static unsigned long
> -m8xx_ide_default_io_base(int index)
> -{
> - return index;
> -}
> -
> #define M8XX_PCMCIA_CD2(slot) (0x10000000 >> (slot << 4))
> #define M8XX_PCMCIA_CD1(slot) (0x08000000 >> (slot << 4))
>
> @@ -149,12 +123,11 @@ static int pcmcia_schlvl = PCMCIA_SCHLVL
> */
>
> /*
> - * m8xx_ide_init_hwif_ports for a direct IDE interface _using_
> + * m8xx_ide_init_ports() for a direct IDE interface _using_
> + * MPC8xx's internal PCMCIA interface
> */
> #if defined(CONFIG_IDE_8xx_PCCARD) || defined(CONFIG_IDE_8xx_DIRECT)
> -static void
> -m8xx_ide_init_hwif_ports(hw_regs_t *hw, unsigned long data_port,
> - unsigned long ctrl_port, int *irq)
> +static void __init m8xx_ide_init_ports(hw_regs_t *hw, unsigned long
> data_port) {
> unsigned long *p = hw->io_ports;
> int i;
> @@ -173,8 +146,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> unsigned long base;
>
> *p = 0;
> - if (irq)
> - *irq = 0;
>
> pcmp = (pcmconf8xx_t *)(&(((immap_t
> *)IMAP_ADDR)->im_pcmcia));
> @@ -248,9 +219,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> }
> }
>
> - if (data_port >= MAX_HWIFS)
> - return;
> -
> if (_slot_ == -1) {
> printk ("PCMCIA slot has not been defined! Using A
> as default\n"); _slot_ = 0;
> @@ -292,11 +260,13 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> *p++ = base + ioport_dsc[data_port].reg_off[i];
> }
>
> - if (irq) {
> + hw->irq = ioport_dsc[data_port].irq;
> + hw->ack_intr = (ide_ack_intr_t *)ide_interrupt_ack;
> +
> #ifdef CONFIG_IDE_8xx_PCCARD
> + {
> unsigned int reg;
>
> - *irq = ioport_dsc[data_port].irq;
> if (_slot_)
> pgcrx = &((immap_t *)
> IMAP_ADDR)->im_pcmcia.pcmc_pgcrb; else
> @@ -306,14 +276,11 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> reg |= mk_int_int_mask (pcmcia_schlvl) << 24;
> reg |= mk_int_int_mask (pcmcia_schlvl) << 16;
> *pgcrx = reg;
> -#else /* direct connected IDE drive, i.e. external IRQ, not
> the PCMCIA irq */
> - *irq = ioport_dsc[data_port].irq;
> -#endif /* CONFIG_IDE_8xx_PCCARD */
> }
> +#endif /* CONFIG_IDE_8xx_PCCARD */
>
> ide_hwifs[data_port].pio_mask = ATA_PIO4;
> ide_hwifs[data_port].set_pio_mode = m8xx_ide_set_pio_mode;
> - ide_hwifs[data_port].ack_intr = (ide_ack_intr_t
> *)ide_interrupt_ack;
> /* Enable Harddisk Interrupt,
> * and make it edge sensitive
> @@ -329,16 +296,15 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
> /* Enable falling edge irq */
> pcmp->pcmc_per = 0x100000 >> (16 * _slot_);
> #endif /* CONFIG_IDE_8xx_PCCARD */
> -} /* m8xx_ide_init_hwif_ports() using 8xx internal PCMCIA
> interface */ +}
> #endif /* CONFIG_IDE_8xx_PCCARD || CONFIG_IDE_8xx_DIRECT */
>
> /*
> - * m8xx_ide_init_hwif_ports for a direct IDE interface _not_ using
> + * m8xx_ide_init_ports() for a direct IDE interface _not_ using
> * MPC8xx's internal PCMCIA interface
> */
> #if defined(CONFIG_IDE_EXT_DIRECT)
> -void m8xx_ide_init_hwif_ports (hw_regs_t *hw,
> - unsigned long data_port, unsigned long ctrl_port, int *irq)
> +static void __init m8xx_ide_init_ports(hw_regs_t *hw, unsigned long
> data_port) {
> unsigned long *p = hw->io_ports;
> int i;
> @@ -349,8 +315,6 @@ void m8xx_ide_init_hwif_ports (hw_regs_t
> unsigned long base;
>
> *p = 0;
> - if (irq)
> - *irq = 0;
>
> if (!ide_base) {
>
> @@ -372,9 +336,6 @@ void m8xx_ide_init_hwif_ports (hw_regs_t
> #endif
> }
>
> - if (data_port >= MAX_HWIFS)
> - return;
> -
> base = ide_base + ioport_dsc[data_port].base_off;
> #ifdef DEBUG
> printk ("base: %08x + %08x = %08x\n",
> @@ -392,14 +353,12 @@ void m8xx_ide_init_hwif_ports (hw_regs_t
> *p++ = base + ioport_dsc[data_port].reg_off[i];
> }
>
> - if (irq) {
> - /* direct connected IDE drive, i.e. external IRQ */
> - *irq = ioport_dsc[data_port].irq;
> - }
> + /* direct connected IDE drive, i.e. external IRQ */
> + hw->irq = ioport_dsc[data_port].irq;
> + hw->ack_intr = (ide_ack_intr_t *)ide_interrupt_ack;
>
> ide_hwifs[data_port].pio_mask = ATA_PIO4;
> ide_hwifs[data_port].set_pio_mode = m8xx_ide_set_pio_mode;
> - ide_hwifs[data_port].ack_intr = (ide_ack_intr_t
> *)ide_interrupt_ack;
> /* Enable Harddisk Interrupt,
> * and make it edge sensitive
> @@ -407,8 +366,7 @@ void m8xx_ide_init_hwif_ports (hw_regs_t
> /* (11-18) Set edge detect for irq, no wakeup from low power
> mode */ ((immap_t *) IMAP_ADDR)->im_siu_conf.sc_siel |=
> (0x80000000 >> ioport_dsc[data_port].irq);
> -} /* m8xx_ide_init_hwif_ports() for CONFIG_IDE_8xx_DIRECT */
> -
> +}
> #endif /* CONFIG_IDE_8xx_DIRECT */
>
>
> @@ -829,20 +787,20 @@ static int identify (volatile u8 *p)
> return (0); /* don't know */
> }
>
> -void m8xx_ide_init(void)
> -{
> - ppc_ide_md.default_irq = m8xx_ide_default_irq;
> - ppc_ide_md.default_io_base = m8xx_ide_default_io_base;
> - ppc_ide_md.ide_init_hwif = m8xx_ide_init_hwif_ports;
> -}
> -
> static int __init mpc8xx_ide_probe(void)
> {
> + hw_regs_t hw;
> u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
>
> #ifdef IDE0_BASE_OFFSET
> + memset(&hw, 0, sizeof(hw));
> + m8xx_ide_init_ports(&hw, 0);
> + ide_init_port_hw(&ide_hwifs[0], &hw);
> idx[0] = 0;
> #ifdef IDE1_BASE_OFFSET
> + memset(&hw, 0, sizeof(hw));
> + m8xx_ide_init_ports(&hw, 1);
> + ide_init_port_hw(&ide_hwifs[1], &hw);
> idx[1] = 1;
> #endif
> #endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* High resolution timer support in 2.6.24+ for MPC831x?
From: Leon Woestenberg @ 2008-02-14 20:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
although I can enable high res timers in 2.6.24, the item note says it
does nothing if the platform does not have support for it.
My platform is a MPC8313E-RDB, and I suspect no high res clock source
implementation exists for it in 2.6.24, because
clock_getres(CLOCK_REALTIME,) gives me 1/HZ.
Is this correct and/or is anything in the works?
Regards,
--
Leon
^ permalink raw reply
* RE: [PATCH] [POWERPC] Enable correct operation of serial ports withnonzero regshift.
From: Stephen Neuendorffer @ 2008-02-14 18:55 UTC (permalink / raw)
To: Pavel Kiryukhin, linuxppc-dev
In-Reply-To: <47B35ED8.7020404@ru.mvista.com>
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> + /* get regshift if present*/
> + regshift =3D get_property(np, "reg-shift", NULL);
of_get_property, presumably?
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
> + regshift =3D get_property(np, "reg-shift", NULL);
ditto...
Otherwise,=20
Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Also, can you post a patch to the Xilinx portion of
booting-without-of.txt that has the device tree entries necessary to get
the uart to work? (Since I happened to be tracking down what I assume
is the same issue when you posted the patch!)
Steve
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Jesse Barnes @ 2008-02-14 18:39 UTC (permalink / raw)
To: linux-pci; +Cc: Greg KH, paulus, anton, Martin Mares, linuxppc-dev
In-Reply-To: <mj+md-20080214.093558.3352.nikam@ucw.cz>
On Thursday, February 14, 2008 1:40 am Martin Mares wrote:
> Hi Greg!
>
> > I have no idea, it sounds like a PPC specific thing, not anything the
> > PCI core does, right? So I'll add the ppc list to the cc: and ask if
> > anyone there has any ideas?
>
> Unfortunately, this is not PPC specific at all -- proc_attach_device()
> calls pci_proc_domain(bus), which is an arch-specific hook turning on
> the weird behavior I described. This hook can return non-zero even on
> x86 if there are buses outside domain 0.
>
> I think that the hook itself is correct, it only should trigger more
> consistent behavior of the generic code :)
>
> Would it be acceptable for the PPC folks to modify the code to add
> domain numbers to the device numbers in /proc/bus/pci/devices in the
> same format as the bus directories already have?
>
> If so, I will cook up a patch.
I've run into this too, on machines with many domains. It's unfortunate that
there's no way to preserve compatibility, but I agree that the brokenness may
as well be consistent.
Jesse
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:38 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH,
linux-kernel, apw, linuxppc-dev, Christoph Raisch, netdev, tklein
In-Reply-To: <1203010575.12312.6.camel@dyn9047017100.beaverton.ibm.com>
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
>
> I am not sure what you are trying to do with walk_memory_resource().
> The
> behavior is different on ppc64. Hotplug memory usage assumes that all
> the memory resources (all system memory, not just IOMEM) are
> represented
> in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
> contains ONLY iomem related. Paulus didn't want to export all the
> system
> memory into /proc/iomem on ppc64. So I had to workaround by providing
> arch-specific walk_memory_resource() function for ppc64.
OK, let's use that one.
-- Dave
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Badari Pulavarty @ 2008-02-14 17:36 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH,
linux-kernel, apw, linuxppc-dev, Christoph Raisch, netdev, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote:
..
> > > > - Use currently other not exported functions in kernel/resource.c, like
> > > > walk_memory_resource (where we would still need the maximum
> > > possible number
> > > > of pages NR_MEM_SECTIONS)
> > >
> > > It isn't the act of exporting that's the problem. It's making sure that
> > > the exports won't be prone to abuse and that people are using them
> > > properly. You should assume that you can export and use
> > > walk_memory_resource().
> >
> > So this seems to come down to a basic question:
> > New hardware seems to have a tendency to get "private MMUs",
> > which need private mappings from the kernel address space into a
> > "HW defined address space with potentially unique characteristics"
> > RDMA in Openfabrics with global MR is the most prominent example heading
> > there
>
> That's not a question. ;)
>
> Please explain to me why walk_memory_resource() is insufficient for your
> needs. I've now pointed it out to you at least 3 times.
I am not sure what you are trying to do with walk_memory_resource(). The
behavior is different on ppc64. Hotplug memory usage assumes that all
the memory resources (all system memory, not just IOMEM) are represented
in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
contains ONLY iomem related. Paulus didn't want to export all the system
memory into /proc/iomem on ppc64. So I had to workaround by providing
arch-specific walk_memory_resource() function for ppc64.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:12 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH, apw,
linux-kernel, linuxppc-dev, Badari Pulavarty, netdev, tklein
In-Reply-To: <OF64B9886B.CE795DED-ONC12573EF.002FFA8B-C12573EF.00301683@de.ibm.com>
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > Constraints imposed by HW / FW:
> > > - eHEA has own MMU
> > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> virtual
> > > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > > - The number of MRs is limited (not enough to have one MR per packet)
> >
> > Are there enough to have one per 16MB section?
>
> Unfortunately this won't work. This was one of our first ideas we tossed
> out,
> but the number of MRs will not be sufficient.
Can you give a ballpark of how many there are to work with? 10? 100?
1000?
> We understand that the add/remove area is not as
> settled in the kernel like for example f_ops ;-)
> Are there already base working assumptions which are very unlikely to
> change?
If you use good interfaces, and someone changes them, they'll likely
also fix your driver.
If you use bad interfaces, people may not even notice when they break.
As I showed you with those compile failures, you're using bad interfaces
that don't even compile on some .configs.
> I'm a little confused here....
> ...the existing add/remove code depends on sparse mem.
> Other pieces on the POWER6 version of the architecture do as well.
> So we could either chose to disable add/remove if sparsemem is not there,
> or disable the driver by Kconfig in this case.
Technically, you can do this. But, it's not a sign of a professionally
written driver that is going to get its patches accepted into mainline.
Technically, you can also use lots of magic numbers and not obey
CodingStyle. But, you'll probably get review comments asking you to
change it.
> > > - a way to iterate over all kernel pages and a way to detect holes in
> the
> > > kernel memory layout in order to build up our own ehea_bmap.
> >
> > Look at kernel/resource.c
> >
> > But, I'm really not convinced that you can actually keep this map
> > yourselves. It's not as simple as you think. What happens if you get
> > on an LPAR with two sections, one 256MB@0x0 and another
> > 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> > array will eat all of memory.
> I'm glad you mention this part. There are many algorithms out there to
> handle this problem,
> hashes/trees/... all of these trade speed for smaller memory footprint.
> We based the table decission on the existing implementations of the
> architecture.
> Do you see such a case coming along for the next generation POWER systems?
Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
memory to it. Then, remove all of the sections of memory in the middle.
You'll be left with a very sparse memory configuration that we *DO*
handle today in the core VM. We handle it quite well, actually.
The hypervisor does not shrink memory from the top down. It pulls
things out of the middle and shuffles things around. In fact, a NUMA
node's memory isn't even contiguous.
Your code will OOM the machine in this case. I consider the ehea driver
buggy in this regard.
> I would guess these drastic changes would also require changes in base
> kernel.
No, we actually solved those a couple years ago.
> Will you provide a generic mapping system with a contiguous virtual address
> space
> like the ehea_bmap we can query? This would need to be a "stable" part of
> the implementation,
> including translation functions from kernel to nextgen_ehea_generic_bmap
> like virt_to_abs.
Yes, that's a real possibility, especially if some other users for it
come forward. We could definitely add something like that to the
generic code. But, you'll have to be convincing that what we have now
is insufficient.
Does this requirement:
"- MRs cover a contiguous virtual memory block (no holes)"
come from the hardware?
Is that *EACH* MR? OR all MRs?
Where does EHEA_BUSMAP_START come from? Is that defined in the
hardware? Have you checked to ensure that no other users might want a
chunk of memory in that area?
Can you query the existing MRs? Not change them in place, but can you
query their contents?
> > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> > in the core, so that we can deal with these kinds of problems, once and
> > *NOT* in every single little driver out there.
> >
> > > Functions to use while building ehea_bmap + MRs:
> > > - Use either the functions that are used by the memory hotplug system
> as
> > > well, that means using the section defines + functions
> (section_nr_to_pfn,
> > > pfn_valid)
> >
> > Basically, you can't use anything related to sections outside of the
> > core code. You can use things like pfn_valid(), or you can create new
> > interfaces that are properly abstracted.
>
> We picked sections instead of PFNs because this keeps the ehea_bmap in a
> reasonable range
> on the existing systems.
> But if you provide a abstract method handling exactly the problem we
> mention
> we'll be happy to use that and dump our private implementation.
One thing you can guarantee today is that things are contiguous up to
MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
much more appropriate than using sparsemem. We could also give you a
nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
that's what you really want.
> > > - Use currently other not exported functions in kernel/resource.c, like
> > > walk_memory_resource (where we would still need the maximum
> > possible number
> > > of pages NR_MEM_SECTIONS)
> >
> > It isn't the act of exporting that's the problem. It's making sure that
> > the exports won't be prone to abuse and that people are using them
> > properly. You should assume that you can export and use
> > walk_memory_resource().
>
> So this seems to come down to a basic question:
> New hardware seems to have a tendency to get "private MMUs",
> which need private mappings from the kernel address space into a
> "HW defined address space with potentially unique characteristics"
> RDMA in Openfabrics with global MR is the most prominent example heading
> there
That's not a question. ;)
Please explain to me why walk_memory_resource() is insufficient for your
needs. I've now pointed it out to you at least 3 times.
> > Do you know what other operating systems do with this hardware?
>
> We're not aware of another open source Operating system trying to address
> this topic.
What about AIX? Do you know who wrote its driver? Perhaps you should
go ask them.
-- Dave
^ permalink raw reply
* [PATCH] Fix ucc_geth MII master selection
From: Joakim Tjernlund @ 2008-02-14 17:11 UTC (permalink / raw)
To: 'linuxppc-dev Development'; +Cc: Joakim Tjernlund
Remove bogus UCC regs range test and correct
off by one error in call to ucc_set_qe_mux_mii_mng()
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
I am not 100% sure this is the correct fix, please ACK or NACK
drivers/net/ucc_geth_mii.c | 26 +++++++++++---------------
1 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 6c257b8..472d5a1 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -200,21 +200,17 @@ static int uec_mdio_probe(struct of_device *ofdev, const struct of_device_id *ma
if (err)
goto bus_register_fail;
- /* if our mdio regs fall within this UCC regs range */
- if ((res.start >= tempres.start) &&
- (res.end <= tempres.end)) {
- /* set this UCC to be the MII master */
- const u32 *id = of_get_property(tempnp, "device-id", NULL);
- if (id == NULL)
- goto bus_register_fail;
-
- ucc_set_qe_mux_mii_mng(*id - 1);
-
- /* assign the TBI an address which won't
- * conflict with the PHYs */
- out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
- break;
- }
+ /* set this UCC to be the MII master */
+ const u32 *id = of_get_property(tempnp, "device-id", NULL);
+ if (id == NULL)
+ goto bus_register_fail;
+
+ ucc_set_qe_mux_mii_mng(*id);
+
+ /* assign the TBI an address which won't
+ * conflict with the PHYs */
+ out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
+ break;
}
err = mdiobus_register(new_bus);
--
1.5.3.8
^ permalink raw reply related
* Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: Clemens Koller @ 2008-02-14 16:52 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0802140528i69fece47xa6d751200c5616f9@mail.gmail.com>
mahendra varman schrieb:
> Hello all
>
> If iam not using the open firmware architecture
> Then can u please help me what i need to enable in menuconfig for ISP
> 1562 pci based usb controller ...
According to it's datasheet, The ISP1562 integrates normal OHCI / EHCI
compliant USB cores. My ISP1563 works fine with these CONFIGs enabled.
> Please do reply
Please don't push anybody.
Regards,
Clemens Koller
^ permalink raw reply
* BUG: ucc_geth, MDIO only works for UCC3(ucc@2200) on MPC8321
From: Joakim Tjernlund @ 2008-02-14 16:36 UTC (permalink / raw)
To: 'linuxppc-dev Development', Kim Phillips, Li Yang
Trying to use other UCC2 or UCC4 for ethernet instead of UCC3 makes MDIO
unusable. UCC2 can not find its PHY if not UCC3 is present too. Seems
like only UCC3 is able to drive the MDIO bus.
Jocke
^ permalink raw reply
* [PATCH 04/14] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
arch/powerpc/platforms/iseries/pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
#undef DEBUG
+#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/string.h>
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] emac/zmii link warnings
From: Josh Boyer @ 2008-02-14 15:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <47AA9251.5020007@pikatech.com>
On Thu, 07 Feb 2008 00:08:33 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Ok, here is my best shot at removing the warnings. It seems to me that
> functions called from a dev_init section should not be dev_exit.
This seems to fix those specific warnings, but there are others lurking
in some of the other files (rgmii, tah, etc). We should probably get
those fixed up too.
josh
^ permalink raw reply
* Re: [PATCH] remove unused CONFIG_WANT_DEVICE_TREE
From: Josh Boyer @ 2008-02-14 15:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080214041301.30383.5581.stgit@trillian.secretlab.ca>
On Wed, 13 Feb 2008 21:14:09 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> CONFIG_DEVICE_TREE was the only user of CONFIG_WANT_DEVICE_TREE but
> it was removed in commit id 25431333813686654907ab987fb5de10c10a16db
> (bootwrapper: Build multiple cuImages).
>
> This patch removes CONFIG_WANT_DEVICE_TREE from Kconfig and the defconfigs
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested on Ebony for 4xx. Seems Paul already has it queued up.
I have some other changes coming and I'll update the defconfigs for 4xx
to remove reference to it.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Kumar Gala @ 2008-02-14 14:28 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linuxppc-dev
In-Reply-To: <47B40573.1080203@ru.mvista.com>
On Feb 14, 2008, at 3:10 AM, Pavel Kiryukhin wrote:
> Kumar Gala wrote:
>>
>> On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote:
>>
>>> Add regshift reading to serial drivers.
>>> This enables correct operation of serial ports with nonzero
>>> regshift.
>>
>> what device needs this?
>>
>> - k
>
> Xilinx opb 16550 uart
please add that info to the commit message so we know why this change
was made. Other it looks ok to me.
- k
^ permalink raw reply
* Re: libfdt: Fix NOP handling bug in fdt_add_subnode_namelen()
From: Jon Loeliger @ 2008-02-14 14:05 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080214055034.GA13137@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> fdt_add_subnode_namelen() has a bug if asked to add a subnode to a
> node which has NOP tags interspersed with its properties. In this
> case fdt_add_subnode_namelen() will put the new subnode before the
> first NOP tag, even if there are properties after it, which will
> result in an invalid blob.
>
> This patch fixes the bug, and adds a testcase for it.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: mahendra varman @ 2008-02-14 13:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
Hello all
If iam not using the open firmware architecture
Then can u please help me what i need to enable in menuconfig for ISP 1562
pci based usb controller ...
Please do reply
[-- Attachment #2: Type: text/html, Size: 204 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] [POWERPC] Add i2c pins to dts and board setup on 01-31-08
From: Jochen Friedrich @ 2008-02-14 11:39 UTC (permalink / raw)
To: Nima Montaser; +Cc: linuxppc-dev list
In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE1418A0B3@zcarhxm2.corp.nortel.com>
Hi Nima,
> I've got a couple of comments about the above patch - I'm not quite sure
> how to add my comments to the ozlab.org site.
simply replying to the original mail will add your comments.
> 1 -
> -- a/arch/powerpc/boot/dts/mpc8272ads.dts
> [snip]
> + i2c@11860 {
> + compatible = "fsl,mpc8248-i2c",
> [NIMA] Are you sure it should be mpc8248, or do you want 8272. I know
> they are essentially the same chip, but just to avoid confusion, it
> maybe better as 8272.
Good catch, thanks! As i don't have a CPM2 chip myself, i had a tester with
a MPC8248. I just took his dts parts.
> 2-
> +++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
> @@ -96,6 +96,11 @@ static struct cpm_pin mpc8272_ads_pins[] = {
> {1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
> {2, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> {2, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> +
> + /* I2C */
> + {3, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
> + {3, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
>
> [NIMA] The MPC8272 manual states that it should be pins 14/15 and not
> 26/27.
Ah thanks.
> However, in all my accesses,
> - 1st write is successful
> - 1st read fails (times out)
> - 2nd read succeeds
>
> Here is the debug log:
> i2c-adapter i2c-0: ioctl, cmd=0x703, arg=0x40
> i2c-dev: i2c-0 writing 2 bytes.
> i2c-adapter i2c-0: master_xfer[0] W, addr=0x40, len=2
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_iic_write(abyte=0x80)
> i2c-adapter i2c-0: tx sc 0 bc00
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 2
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: tx sc 0 3c00
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: I2C read: timeout!
> i2c-adapter i2c-0: cpm_i2c_force_close()
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: rx sc 2c00, rx sc 1800
>
> Any ideas?
What does you chip expect? Start-Write-Start-Read-Stop or Start-Write-Stop, Start-Read-Stop?
Did you try chaining the write and read request (put them into the same msg)?
Thanks,
Jochen
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Martin Mares @ 2008-02-14 9:40 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Linux-PCI Mailing List, paulus, anton
In-Reply-To: <20080214044323.GB1176@kroah.com>
Hi Greg!
> I have no idea, it sounds like a PPC specific thing, not anything the
> PCI core does, right? So I'll add the ppc list to the cc: and ask if
> anyone there has any ideas?
Unfortunately, this is not PPC specific at all -- proc_attach_device()
calls pci_proc_domain(bus), which is an arch-specific hook turning on
the weird behavior I described. This hook can return non-zero even on
x86 if there are buses outside domain 0.
I think that the hook itself is correct, it only should trigger more
consistent behavior of the generic code :)
Would it be acceptable for the PPC folks to modify the code to add
domain numbers to the device numbers in /proc/bus/pci/devices in the
same format as the bus directories already have?
If so, I will cook up a patch.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c
^ permalink raw reply
* Re: [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc
From: Kamalesh Babulal @ 2008-02-14 9:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dhaval Giani, Jens Axboe, Srivatsa Vaddagiri, LKML, linuxppc-dev,
Balbir Singh
In-Reply-To: <20080212075812.GC11775@elte.hu>
Ingo Molnar wrote:
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> While booting with the 2.6.25-rc1-git1 kernel on the powerbox the
>> softlockup is seen, with following trace.
>
>> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:377]
>> TASK = c00000077cb2f0e0[377] 'insmod' THREAD: c00000077cb28000 CPU: 1
>> NIP [c0000000001b172c] .radix_tree_gang_lookup+0xdc/0x1e4
>> LR [c0000000001a6f00] .call_for_each_cic+0x50/0x10c
>> Call Trace:
>> [c00000077cb2bb20] [c0000000001a6f60] .call_for_each_cic+0xb0/0x10c (unreliable)
>> [c00000077cb2bc60] [c00000000019ecd8] .exit_io_context+0xf0/0x110
>> [c00000077cb2bcf0] [c00000000006254c] .do_exit+0x820/0x850
>> [c00000077cb2bda0] [c000000000062648] .do_group_exit+0xcc/0xe8
>> [c00000077cb2be30] [c00000000000872c] syscall_exit+0x0/0x40
>
> this call_for_each_cic/radix_tree_gang_lookup locked up, and all other
> CPUs deadlocked in stopmachine, due to this one.
>
> call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got
> classic-RCU:
>
> CONFIG_CLASSIC_RCU=y
> # CONFIG_PREEMPT_RCU is not set
>
> so it's not related to the preempt-RCU changes either.
>
> It is this part that locks up:
>
> do {
> ...
> nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
> index, CIC_GANG_NR);
> ...
> } while (nr == CIC_GANG_NR);
> ...
>
> it seems the radix tree will yield new entries again and again. Either
> it got corrupted, or some other CPU is filling it faster than we can
> deplete it [unlikely i think].
>
> Ingo
This softlockup is seen with the 2.6.25-rc1-git3 also. Let me know if you
need more details.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Pavel Kiryukhin @ 2008-02-14 9:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B8D9D613-441B-4A20-AE2D-D808D4B82F16@kernel.crashing.org>
Kumar Gala wrote:
>
> On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote:
>
>> Add regshift reading to serial drivers.
>> This enables correct operation of serial ports with nonzero regshift.
>
> what device needs this?
>
> - k
Xilinx opb 16550 uart
--
Pavel
^ 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