From: Kumar Gala:
...
> Fixed RTC support that requires a dummy memory read on the P2P
> bridge to unlock the RTC and setup the default of the RTC alarm
> registers to match with a basic x86 style CMOS RTC.
...
> diff --git a/arch/powerpc/platforms/fsl_uli1575.c
...
> +/* We have to do a dummy read
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> I have developed a device driver and use the sysFS to export some
> registers to userspace.
Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
not to play around with registers from userspace.
> I opened the s
On Tue, Sep 11, 2007 at 09:34:13AM -0500, Milton Miller wrote:
> Previously we called ppc_md.get_boot_time at most once. How about
> moving the check for it into the if (first) block?
Yup on investigatiion it looks like moving it inside the "if (fist)" is
safe.
> Have you tested with a platf
This is from an earlier message from Christoph Lameter:
processor_core.c currently tries to determine the apicid by special casing
for IA64 and x86. The desired information is readily available via
cpu_physical_id()
on IA64, i386 and x86_64.
Signed-off-by: Christoph
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/powerpc/k
Convert cpu_sibling_map from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c |2 -
ar
This patch converts the x86_cpu_to_apicid array to be a per
cpu variable. This saves sizeof(apicid) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
MP_processor_info() is one of the functions that require access
to the x86_cpu_to_apicid array before the per_cpu data are
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ia64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
There was one access to cpu_sibling_map before the per_cpu data
area was created, so that step was moved to after the p
This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
fo
Convert cpu_sibling_map to a per_cpu cpumask_t array for the sparc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/sparc64
Convert cpu_llc_id from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpu_llc_id) * NR unused
cpus. Access is mostly from startup and CPU HOTPLUG functions.
Note there's an addtional change of the type of cpu_llc_id
from int to u8 for ARCH i386 to correspond with the s
Note:
This patch consolidates all the previous patches regarding
the conversion of static arrays sized by NR_CPUS into per_cpu
data arrays and is referenced against 2.6.23-rc6 .
v1 Intro:
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0.
Fix four instances where cpu_to_node is referenced
by array instead of via the cpu_to_node macro. This
is preparation to moving it to the per_cpu data area.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/vsyscall.c |2 +-
arch/x86_64/mm/numa.c |4 ++--
arch
This is a copy of an older patch that is in rc3-mm1. It's needed
to allow the remaining patches to integrate correctly.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic.c |2 --
arch/x86_64/kernel/genapic_flat.c |1 -
arch/x86_64/kernel/smpboot.c |
Make the define_machine() block for mpc885_ads more greppable and consistent
with other examples in tree.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Index: working/ar
On Tue, Sep 11, 2007 at 10:33:20PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
>
> > On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> >> Added basic board port for MPC8572 DS reference platform that is
> >> similiar to the MPC8544/33 DS reference pl
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
>
> > On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
> >>
> >> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
> >>
> >>> Olof Johansson wrote:
> On Tue, Sep 11, 200
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
> > In the meantime, couldn't the code still be merged, using an explicit
> > test of the root node's 'compatible' or 'model' properties to decide
> > on the right primary bus.
>
> I will be, I'm not going to wait on having some device tr
On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
> On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
>>
>> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
>>
>>> Olof Johansson wrote:
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> Olof Johansson wrote:
>> On
On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
> On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
>> Added basic board port for MPC8572 DS reference platform that is
>> similiar to the MPC8544/33 DS reference platform in uniprocessor
>> mode.
>>
>> ---
>>
>> Rev 3 -- updates to th
On Wed, 2007-09-12 at 12:05 +1000, David Gibson wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > Hello,
> >
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace. I opened the sysFS File for one register and did
> > some reads
On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> Added basic board port for MPC8572 DS reference platform that is
> similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
>
> ---
>
> Rev 3 -- updates to the device tree based on discussion on how we want
> to handle me
On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
>
> > Olof Johansson wrote:
> >> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> >>> Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrot
> On Wed, 12 Sep 2007, Michael Neuling wrote:
> >
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
>
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on
On Tue, Sep 11, 2007 at 07:17:42PM -0700, Linus Torvalds wrote:
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on the architecture having a define for TCGETS2, and I think they match
> up. I see:
>
> [EMAIL PROTECTED] linux]$ git grep -l kerne
Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> This adds the required API to asm-powerpc.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> --
> This needs to go up fo
On Wed, 12 Sep 2007, Michael Neuling wrote:
>
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the architecture
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> Hello,
>
> I have developed a device driver and use the sysFS to export some
> registers to userspace. I opened the sysFS File for one register and did
> some reads from this File, but I alwas becoming the same value from the
> regi
The "tty: termios locking functions break with new termios type" patch
(f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
This adds the required API to asm-powerpc.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
--
This needs to go up for 2.6.23.
Should we really put these
On Tue, Sep 11, 2007 at 11:09:07AM -0600, Grant Likely wrote:
> On 9/11/07, Michal Simek <[EMAIL PROTECTED]> wrote:
> > For example emaclite driver needs information about turning on/off ping
> > pong buffer...
> >
> > I would like to make this properly.
>
> FDT design is just as much art as it i
On Wed, 12 Sep 2007 00:57:17 +0200
Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Vitaly Bordug wrote:
> >
> > We are having 2 different instances of
> > pci_process_bridge_OF_ranges(), which makes describing 64-bit
> > physical addresses in non PPC64 case impossible.
> >
> > This approa
On Wednesday 12 September 2007, Vitaly Bordug wrote:
>
> We are having 2 different instances of pci_process_bridge_OF_ranges(),
> which makes describing 64-bit physical addresses in non PPC64 case
> impossible.
>
> This approach inherits pci space parsing, but has a new way to behave
> equally go
We are having 2 different instances of pci_process_bridge_OF_ranges(),
which makes describing 64-bit physical addresses in non PPC64 case
impossible.
This approach inherits pci space parsing, but has a new way to behave
equally good in both 32bit and 64bit environments. This approach uses
of_tran
Paul Mackerras wrote:
> Scott Wood writes:
>
>> The e300 core (and probably most other 6xx chips) can only come out of
>> sleep mode with an interrupt. However, interrupts are logically disabled
>> by the power management layer.
>>
>> This hack extends the existing doze/nap hack to also suppress
Paul Mackerras wrote:
> Scott Wood writes:
>
>> +_GLOBAL(mpc6xx_enter_sleep)
>
> The name is slightly unfortunate as powerbooks also use 6xx-family
> processors but enter sleep in a quite different manner, because they
> exit sleep with a reset. Can you think of a better name, that gives a
> hin
Scott Wood writes:
> The e300 core (and probably most other 6xx chips) can only come out of
> sleep mode with an interrupt. However, interrupts are logically disabled
> by the power management layer.
>
> This hack extends the existing doze/nap hack to also suppress the running
> of the interrupt
Scott Wood writes:
> +_GLOBAL(mpc6xx_enter_sleep)
The name is slightly unfortunate as powerbooks also use 6xx-family
processors but enter sleep in a quite different manner, because they
exit sleep with a reset. Can you think of a better name, that gives a
hint that this is the one to use if we a
Paul Mackerras wrote:
> It might be better to use hard_irq_disable rather than
> local_irq_disable here, since I think we will need that on 64-bit (and
> on 32-bit if we ever do lazy irq disabling there).
OK.
>> +/* Overrides the weak version in kernel/power/main.c */
>> +void arch_suspend_disabl
Scott Wood writes:
> These hooks ensure that a decrementer interrupt is not pending when
> suspending; otherwise, problems may occur. For example, with deep sleep
> on the 831x, a pending decrementer will cause a system freeze because the
> SoC thinks the decrementer interrupt would have woken th
On Tue, Sep 11, 2007 at 02:22:21PM -0500, Becky Bruce wrote:
> >>
> >> I'm also guilty of not noticing the original patch - my apologies.
> >
> > maybe we should just have a platforms/fsl for all boards from
> > freescale. Not having things broken up by which processor family
> > they are for
Would you feel better if it was in platforms/common/ or
platforms/fsl
> Maybe it would make more sense for you guys to slice the platforms
> differently, and have a common platform for the eval boards you
> have
> with ULi on them instead of grouping it by core us
On Tue, 11 Sep 2007 14:22:21 -0500
Becky Bruce <[EMAIL PROTECTED]> wrote:
> > maybe we should just have a platforms/fsl for all boards from
> > freescale. Not having things broken up by which processor family
> > they are for.
>
> What do you envision as being under there? Subdirs? How's i
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Rev 3 -- updates to the device tree based on discussion on how we want
to handle memory busses going forward.
arch/powerpc/boot/dts/mpc8572ds.dts |
On Tue, Sep 11, 2007 at 01:43:59PM -0500, Becky Bruce wrote:
> >> Maybe it would make more sense for you guys to slice the platforms
> >> differently, and have a common platform for the eval boards you have
> >> with ULi on them instead of grouping it by core used by the processor
> >> on the boar
On Sep 11, 2007, at 2:08 PM, Kumar Gala wrote:
>
> On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:
>
>>
>> On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>>
>>>
>>> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>>>
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>
>
On 9/11/07, S. Fricke <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > >[...]
> > > intr = mpc52xx_find_and_map("mpc52xx-pic");
> > > if(!intr) {
> > > panic(__FILE__ ": mpc52xx-pic - MAP failed");
> > > }
> > >
> > > set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
> >
> > You probably d
On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:
>
> On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>
>>
>> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>>
>>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>
On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>
> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>
>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>>
>>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>>
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>
On Sep 11, 2007, at 12:09 PM, Timur Tabi wrote:
> Paul and Kumar,
>
> It turns out that I have a bunch more QE library code clean-up, so
> please ignore this patch. I'll submit a more comprehensive one
> later this week.
>
> Timur Tabi wrote:
>> The initialization of the QE's GUEMR register
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>
>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>
>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>>>
Hello,
> >[...]
> > intr = mpc52xx_find_and_map("mpc52xx-pic");
> > if(!intr) {
> > panic(__FILE__ ": mpc52xx-pic - MAP failed");
> > }
> >
> > set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
>
> You probably don't want to do this (unless you are cascading IRQs to
> custom exter
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>
>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>
>>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>>> ---
>>> arch/powerpc/boot/dts/mpc8544ds.dts| 88 +
Hi,
I am using the kernel 2.6.23-rc3, when i try to boot the kernel i got
following messages.
Booting image at 0020 ...
Image Name: Linux-2.6.23-rc3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1487259 Bytes = 1.4 MB
Load Address:
Entry
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/boot/dts/mpc8544ds.dts| 88 --
>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++--
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
> Olof Johansson wrote:
>> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
>>> Olof Johansson wrote:
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
> well the ifdefs are orthogonal. We don't have a way of knowing
>
On Sep 11, 2007, at 12:03 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>>> I propose we do it by defining the first (and ideally only, but
>>> that's another argument) entry in ranges as the immr, and getting
>>> rid of /soc/reg.
>> I disagree.
Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
>> Olof Johansson wrote:
>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
well the ifdefs are orthogonal. We don't have a way of knowing
primary from the device tree today.
>>> How about
On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> Olof Johansson wrote:
> > On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
> >> well the ifdefs are orthogonal. We don't have a way of knowing
> >> primary from the device tree today.
> >
> > How about something like "fsl,
Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>> well the ifdefs are orthogonal. We don't have a way of knowing
>> primary from the device tree today.
>
> How about something like "fsl,primary-phb" in the bus device node? I don't
> know, maybe it's already
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8544ds.dts| 88 --
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++--
> arch/powerpc/platforms/85xx/Kconfig|
On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
>
> > On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
> >>> How different are these boards really? Could you just detect
> >>> MPC85xxDS
> >>> and have a generic plat
Paul and Kumar,
It turns out that I have a bunch more QE library code clean-up, so please
ignore this patch. I'll submit a more comprehensive one later this week.
Timur Tabi wrote:
> The initialization of the QE's GUEMR register is overly complicated, involving
> multiple functions and a redund
On 9/11/07, Michal Simek <[EMAIL PROTECTED]> wrote:
> Hi Grant,
(Adding linuxppc-dev mailing list to CC list because we're discussing
FDT issues)
> I made EDK repository file for generation dts file from Xilinx design. I sent
> it to Wolfgang and Steve this week.
> It is in the same config file
On Tue, 11 Sep 2007 12:03:31 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
>
> It'd probably be more efficient to discuss this in person; can you stop
> by my cube sometime when you're around and not in a meeting?
Please be sure to post a summary of the discussion if you do that so the
other people
Kumar Gala wrote:
> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>> I propose we do it by defining the first (and ideally only, but
>> that's another argument) entry in ranges as the immr, and getting
>> rid of /soc/reg.
>
> I disagree.
I'm shocked. :-)
> I don't think we want to start over
On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>>> Any particular reason to special-case it, when we already need
>>> code to do it the other way for every other fsl soc?
>> If you suggest a sane way of getting the value le
Kumar Gala wrote:
> On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
>> Any particular reason to special-case it, when we already need code to
>> do it the other way for every other fsl soc?
>
> If you suggest a sane way of getting the value let me know. The mpc8xx
> doesn't appear to have what
On Sep 11, 2007, at 10:51 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> Yep. However, after some discussion with Segher on this for 83xx/
>> 85xx/86xx I think we want to keep the reg prop and have it cover
>> the initial soc registers [size on 83xx is 0x100, size on 85xx/
>> 86xx would be 0x1
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Take two, with my clean ups to the device tree as commented by Scott and
fixing my copy/paste foobar with pci_ids.h.
arch/powerpc/boot/dts/mpc8572ds.dts
On Sep 11, 2007, at 10:55 AM, Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..1e2eba8 100644
--- a/arch/powerpc/platforms/85xx/mp
On Sep 11, 2007, at 9:17 AM, Scott Wood wrote:
> On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
>> diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/
>> boot/dts/mpc8572ds.dts
>> new file mode 100644
>> index 000..9d23561
>> --- /dev/null
>> +++ b/arch/powerpc/boot
On Tue, Sep 11, 2007 at 10:50:18AM -0500, Kumar Gala wrote:
>>> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> index 3a5c3c4..1e2eba8 100644
>>> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
>>> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds
Kumar Gala wrote:
> Yep. However, after some discussion with Segher on this for
> 83xx/85xx/86xx I think we want to keep the reg prop and have it cover
> the initial soc registers [size on 83xx is 0x100, size on 85xx/86xx
> would be 0x1000].
>
> What we need is a saner way to determine immr on
The initialization of the QE's GUEMR register is overly complicated, involving
multiple functions and a redundant ucc_common structure. This patch removes
struct ucc_common, merges ucc_init_guemr() into ucc_set_type() (every caller
of ucc_init_guemr() also calls ucc_set_type() immediately afterwar
On Sep 11, 2007, at 9:18 AM, Olof Johansson wrote:
> Hi,
>
> On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
>> Added basic board port for MPC8572 DS reference platform that is
>> similiar to the MPC8544/33 DS reference platform in uniprocessor
>> mode.
>>
>> ---
>> diff --git a/arc
On Sep 11, 2007, at 8:57 AM, Scott Wood wrote:
> On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
>>
>> On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
>>
>>> 1. Fix get_immrbase() to use ranges, rather than reg.
>>>
>>> It is not always the case that the SoC's first reg property points
>From: Scott Wood [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, September 11, 2007 7:20 AM
>To: Zhang Wei-r63237
>Cc: Nelson, Shannon; [EMAIL PROTECTED];
>linuxppc-dev@ozlabs.org; Williams, Dan J; [EMAIL PROTECTED]
>Subject: Re: [PATCH 5/5] Add DMA engine driver for Freescale
>MPC85xx processors.
>
Hi,
Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
> ---
> drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
> b/drivers/infiniband/hw/ehca/ehca_to
Hi
I am trying to get ethernet working with the current fs_enet patchset
from Scott Wood. I have added this along with the PPC_CPM_NEW_BINDING
patches to Kumars current tree.
I ma having trouble with phy_connect/phy_attach similar to what was
broken without the fs_enet patchset. It turns out tha
On Tue Sep 11 18:17:46 EST 2007, Tony Breeds wrote:
> +unsigned long read_persistent_clock(void)
> {
> struct rtc_time tm;
> + static int first = 1;
> +
> + if (first) {
> + first = 0;
> + if (ppc_md.time_init)
> + timezone_offs
Zhang Wei-r63237 wrote:
>>> +/**
>>> + * fsl_chan_xfer_ld_queue -- Transfer the link descriptors
>> in channel
>>> + * ld_queue.
>> The function's "short description" (unfortunately) must be on only one
>> line. E.g.:
>>
>> * fsl_chan_xfer_ld_queue - Transfer link desc
On Tue, Sep 11, 2007 at 06:10:53PM +0800, Zhang Wei-r63237 wrote:
> > >+
> > >+ fsl_dma_memcpy_issue_pending(chan);
> > >+ while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
> > >+ != DMA_SUCCESS);
> >
> > Again, is it possible to hang your thread here?
> >
> > [...]
>
> I'l
On 9/11/07, S. Fricke <[EMAIL PROTECTED]> wrote:
>
> Dear Linux-enthusiasts,
>
> I'm still at the same problem.
>
> I have now implemented a irq_chip for the hardwired IRQ2. Now I have:
>
>
> --==>
> volatile static struct mpc52xx_intr __iomem *intr;
> unsigned long flags;
> static DEFINE_SPINLOCK(
On Tue, Sep 11, 2007 at 06:01:39PM +0800, Zhang Wei-r63237 wrote:
>
>
> >
> > On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher Boessenkool wrote:
> > > > + l) Freescale DMA
> > >
> > > > +- compatible : Should be "fsl,dma".
> > >
> > > Please choose some more specific name. "fsl,mpc854
Hi,
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
> Added basic board port for MPC8572 DS reference platform that is
> similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
>
> ---
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> b/arch/powerpc/platforms/8
On Tue, Sep 11, 2007 at 01:29:18AM -0500, Kumar Gala wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts
> b/arch/powerpc/boot/dts/mpc8572ds.dts
> new file mode 100644
> index 000..9d23561
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8572ds.dts
> @@ -0,0 +1,378 @@
> +/*
> + * MPC8572
On Tue, Sep 11, 2007 at 12:35:56AM -0500, Kumar Gala wrote:
>
> On Aug 28, 2007, at 3:16 PM, Scott Wood wrote:
>
> >1. Fix get_immrbase() to use ranges, rather than reg.
> >
> >It is not always the case that the SoC's first reg property points
> >to the beginning of the entire SoC block.
>
> whe
Nobody needed the SVNEHCA_ prefix anyway.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_main.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
ind
Some firmware levels exhibit a race condition between H_ALLOC_RESOURCE(MR)
and H_FREE_RESOURCE(MR). Work around this problem by locking these hvCalls
against each other.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/hcp_if.c | 28 +---
Rectify some modify_qp() issues related to path migration.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_irq.c |4 +-
drivers/infiniband/hw/ehca/ehca_qp.c | 90 -
2 files changed, 68 insertions(+), 26 deletions(-)
dif
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
index f9b264b..863f972 100644
--- a
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index d2ab84a..7154f62 100644
--- a/drivers
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_tools.h |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h
b/drivers/infiniband/hw/ehca/ehca_tools.h
index 57c77a7..f9b264b 100644
--- a/driv
...because -12 is easier to read than FFF4.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_cq.c | 14 +++---
drivers/infiniband/hw/ehca/ehca_hca.c|2 +-
drivers/infiniband/hw/ehca/ehca_main.c | 24 +-
drivers/infiniband/hw/ehca/
Change hvcall trace output towards better readability: reg numbers instead
of argument numbers, return code as signed decimal instead of unsigned hex.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/hcp_if.c | 57 ++
1 files chang
From: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
Use Paul's new remap_4k_pfn() function to map our 4K firmware contexts into
user space on 64K-page machines without exposing neighboring firmware
contexts. Return the context's offset within a 64K page to user space so it
can determine the proper virtual
From: Stefan Roscher <[EMAIL PROTECTED]>
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_cq.c |7 ++-
drivers/infiniband/hw/ehca/ehca_main.c |2 +-
drivers/infiniband/hw/ehca/ehca_qp.c |9 +++--
drivers/infiniband/hw/ehca/ehca_uv
From: Stefan Roscher <[EMAIL PROTECTED]>
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/hcp_if.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c
b/drivers/infiniband/hw/ehca/hcp_if.c
index 24f4541..
From: Stefan Roscher <[EMAIL PROTECTED]>
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_qp.c |7 +++
drivers/infiniband/hw/ehca/ipz_pt_fn.c |1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.
Here are some fresh eHCA driver features and fixes for your reviewing
pleasure. They have passed internal testing and checkpatch.pl, so we think
they are ready for inclusion.
[01/12] adds userspace support for small QPs
[02/12] changes a nit in firmware communication
[03/12] adds support for more
1 - 100 of 112 matches
Mail list logo
