* 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: 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
* 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: [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] 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
* [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
* 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
* 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
* [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: [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
* 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: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: /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] [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
* 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 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
* 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 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: [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: /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: /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: Martin Mares @ 2008-02-14 21:46 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: greg, linuxppc-dev, paulus, anton, linux-pci, David Miller
In-Reply-To: <20080214214506.GB7657@parisc-linux.org>
Hi!
> > 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 :-(
>
> It might be best if we only place domain 0 in that file.
Yes, that's another possilibity. However, in such cases we should probably
create the subdirectories only for domain 0 as well.
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
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- D.E.K.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-02-14 22:00 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug-fixes and very minor cleanups for powerpc
(plus one commit wiring up the timerfd syscalls).
Thanks,
Paul.
arch/powerpc/Kconfig | 4 ---
arch/powerpc/boot/Makefile | 2 +
arch/powerpc/boot/ps3-hvcall.S | 2 +
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/process.c | 2 +
arch/powerpc/kernel/vdso.c | 12 ++++----
arch/powerpc/platforms/512x/Kconfig | 1 -
arch/powerpc/platforms/52xx/Kconfig | 2 -
arch/powerpc/platforms/Kconfig | 2 -
arch/powerpc/platforms/Kconfig.cputype | 4 ---
arch/powerpc/platforms/cell/ras.c | 11 ++++++-
arch/powerpc/platforms/embedded6xx/Kconfig | 4 ---
arch/powerpc/platforms/iseries/vio.c | 2 +
drivers/char/hvc_rtas.c | 2 +
drivers/ps3/ps3-lpm.c | 22 ++++++++------
drivers/ps3/ps3-sys-manager.c | 44 ++++++++++++++++++++--------
include/asm-powerpc/systbl.h | 4 ++-
include/asm-powerpc/unistd.h | 6 +++-
include/asm-ppc/page.h | 2 +
19 files changed, 76 insertions(+), 54 deletions(-)
Adrian Bunk (3):
[POWERPC] vdso_do_func_patch{32,64}() must be __init
[POWERPC] free_property() must not be __init
[POWERPC] hvc_rtas_init() must be __init
Geoff Levand (4):
[POWERPC] PS3: Fix bootwrapper hang bug
[POWERPC] PS3: Use system reboot on restart
[POWERPC] PS3: Sys-manager code cleanup
[POWERPC] PS3: Update sys-manager button events
Grant Likely (1):
[POWERPC] Remove unused CONFIG_WANT_DEVICE_TREE
Hugh Dickins (1):
[POWERPC] Fix DEBUG_PREEMPT warning when warning
Kumar Gala (1):
[POWERPC] Remove generated files on make clean
Michael Ellerman (1):
[POWERPC] Cell RAS: Remove DEBUG, and add license and copyright
Stefan Roese (1):
[POWERPC] Fix arch/ppc compilation - add typedef for pgtable_t
Stephen Rothwell (1):
[POWERPC] Wire up new timerfd syscalls
Takashi Yamamoto (2):
[POWERPC] PS3: Fix setting bookmark in logical performance monitor
[POWERPC] PS3: Fix reading pm interval in logical performance monitor
^ permalink raw reply
* Re: [PATCH 0/4]: Respun LMB patches.
From: David Miller @ 2008-02-14 22:13 UTC (permalink / raw)
To: becky.bruce; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <38133B3C-75A2-4465-9484-7BF8E7E85D1D@freescale.com>
From: Becky Bruce <becky.bruce@freescale.com>
Date: Thu, 14 Feb 2008 14:58:22 -0600
> 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.
Thanks for all of the testing.
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Matthew Wilcox @ 2008-02-14 21:45 UTC (permalink / raw)
To: David Miller; +Cc: greg, mj, linuxppc-dev, paulus, anton, linux-pci
In-Reply-To: <20080214.134305.237408044.davem@davemloft.net>
On Thu, Feb 14, 2008 at 01:43:05PM -0800, David Miller wrote:
> 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 :-(
It might be best if we only place domain 0 in that file.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ 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