* DWC_OTG Issues
From: Hunter Cobbs @ 2009-12-19 2:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1261176637-23912-1-git-send-email-ptyser@xes-inc.com>
Hello list. I've run into a rather odd problem. I seem to have a
problem with full-speed isochronous transfers across a USB2.0 Hub. I
believe this was observed before with the general EHCI drivers in Linux.
In the latest branch of the kernel, the EHCI driver has some "Enhanced
Transaction Translation" scheduling. This would be great for me to use
as it seems to directly address the issues I've seen. However, I'm not
really sure on how to proceed because the DWC_OTG driver is not GPL code
while the EHCI code I'd like to use is. Therefore, I don't believe that
I can port the Enhanced Transaction Translation routine into the DWC_OTG
driver without violating both the GPL and Synopsis's own driver.
Does anyone have a suggestion on how to proceed?
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Benjamin Herrenschmidt @ 2009-12-19 8:46 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <m2oclw9wt4.fsf@igel.home>
On Fri, 2009-12-18 at 15:33 +0100, Andreas Schwab wrote:
> Nathan Fontenot <nfont@austin.ibm.com> writes:
>
> > Index: powerpc/arch/powerpc/Kconfig
> > ===================================================================
> > --- powerpc.orig/arch/powerpc/Kconfig 2009-10-28 15:21:47.000000000 -0500
> > +++ powerpc/arch/powerpc/Kconfig 2009-10-28 15:21:53.000000000 -0500
> > @@ -320,6 +320,10 @@
> >
> > Say N if you are unsure.
> >
> > +config ARCH_CPU_PROBE_RELEASE
> > + def_bool y
> > + depends on HOTPLUG_CPU
> > +
>
> That does not work.
>
> drivers/built-in.o: In function `.store_online':
> cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
> cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
> make: *** [.tmp_vmlinux1] Error 1
>
> cpu_hotplug_driver_lock is only defined on pseries, but HOTPLUG_CPU is
> also defined on pmac.
Well, the stuff was merged ... so we need to fix it.
Nathan, the problem is that the above wlil define ARCH_CPU_PROBE_RELEASE
for any powerpc platform that has HOTPLUG_CPU. So a kernel that doesn't
have pSeries support but has hotplug CPU will have a problem, though for
some reason none of my test configs triggered it (I'll have to check why
next week).
The right approach here is to have cpu_hotplug_driver_lock go through
ppc_md. I suppose, along with some of the other CPU hotplug platform
specific bits.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/6 v5] CPU probe/release files
From: Andreas Schwab @ 2009-12-19 10:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1261212415.2173.94.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Nathan, the problem is that the above wlil define ARCH_CPU_PROBE_RELEASE
> for any powerpc platform that has HOTPLUG_CPU. So a kernel that doesn't
> have pSeries support but has hotplug CPU will have a problem, though for
> some reason none of my test configs triggered it (I'll have to check why
> next week).
Perhaps you didn't enable CONFIG_SUSPEND.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* xilinx xps_spi & ads7846
From: Jothi Adithya @ 2009-12-19 17:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 112 bytes --]
Hi
Anybody has experience using xilinx xps_spi driver & ads7846 driver for touchscreen control?
Jothi
[-- Attachment #2: Type: text/html, Size: 485 bytes --]
^ permalink raw reply
* Re: DWC_OTG Issues
From: Wolfgang Denk @ 2009-12-19 18:56 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: linuxppc-dev
In-Reply-To: <1261190115.14590.5.camel@mobiLinux>
Dear Hunter Cobbs,
In message <1261190115.14590.5.camel@mobiLinux> you wrote:
> Hello list. I've run into a rather odd problem. I seem to have a
> problem with full-speed isochronous transfers across a USB2.0 Hub. I
> believe this was observed before with the general EHCI drivers in Linux.
Which exazct kernel / driver cversions are you talking about?
> In the latest branch of the kernel, the EHCI driver has some "Enhanced
> Transaction Translation" scheduling. This would be great for me to use
> as it seems to directly address the issues I've seen. However, I'm not
> really sure on how to proceed because the DWC_OTG driver is not GPL code
Oops? if that wa the case you could not use (and distribute) this code
in a Linux context at all.
> while the EHCI code I'd like to use is. Therefore, I don't believe that
> I can port the Enhanced Transaction Translation routine into the DWC_OTG
> driver without violating both the GPL and Synopsis's own driver.
What makes you think so?
The Synopsis dwc_otg driver license does not seem to be in conflict
to the GPL, if you ask me (but then, I am not a layer). When we
worked on this, we were assured that the use of this driver source in
the context of GPLed software like the Linux kernel (or U-Boot) was
not considered an issue by Synopsis.
> Does anyone have a suggestion on how to proceed?
We have been doing some work on the DWC drivers in the past, fixing a
number of issues. [We never attempted to psuh any of this into
mainline as the Synopsis drivers are - in our opinion - not
avcceptable for mainline but require more or less a rewrite from
scratch. But you can find all this stuff in our linux-2.6-denx repo.]
I recommend you give a try to our latest stable branch.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is research but a blind date with knowledge? -- Will Harvey
^ permalink raw reply
* Re: enabling USB Host controller on ppc405ex based board
From: Weirich, Bernhard @ 2009-12-20 15:13 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
If you enable PCI on 405EX you MUST have valid clock signals on the PCIE po=
rts. If you do not have these on your board your kernel will hang just as y=
ou said.
I do not know why PCI is required for the USB controller, if it is just for=
some software interfaces to be present then you can try to remove the PCIE=
entries from the kilauea.dts device tree.
Then you will be able to boot even without proper clock signals, yet I do n=
ot know whether the USB controller will work.
Best regards,
Bernhard
^ permalink raw reply
* Re: DWC_OTG Issues
From: Hunter Cobbs @ 2009-12-20 20:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20091219185657.5FF29E85072@gemini.denx.de>
Well, thank you for the assurance on the Synopsis drivers not being in
conflict. That makes me feel a little better.
We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit
before, although at the time you were doing some work for AMCC on just
accessing devices across a hub in general. We've been using the driver
for a few months now and it is very stable on first-use of the driver,
but once we close a full-speed port and try to reopen, that's when we
get error concerning not being able to allocate resources and getting
-28 errors. I don't have anything precise in front of me at the moment,
my test equipment is at the office. But this seems to be the issues
that lead to the Enhanced Transaction Translation Scheduling changes in
the main-line kernel.
I'm mainly being, I believe, overly cautious about not including GPL
code in the Synopsis driver simply because I'd rather be overly careful
than be exposed to some liability later down the road if Synopsis
decides they want to make their driver completely proprietary. While
the code is available, I'm not sure if we can include code from GPL
sources in the Synopsis drivers without requiring the Synopsis driver to
become completely GPL. I am also not a lawyer, but I'd rather be
cautious.
I did do a comparison on the previous branch we are (2.6.30.3-denx) and
the current stable. The only differences in the code were minor enough
that I simply merged them into our existing codebase. It didn't really
help our issue, but on block transfers and standard connect/disconnect
the driver seemed more responsive. I believe this was mainly from
Setphan's actions to put some sleeps inside of tight loops that would
chew up major CPU time on a non-preemptable kernel(which we had earlier).
On Sat, 2009-12-19 at 19:56 +0100, Wolfgang Denk wrote:
> Dear Hunter Cobbs,
>
> In message <1261190115.14590.5.camel@mobiLinux> you wrote:
> > Hello list. I've run into a rather odd problem. I seem to have a
> > problem with full-speed isochronous transfers across a USB2.0 Hub. I
> > believe this was observed before with the general EHCI drivers in Linux.
>
> Which exazct kernel / driver cversions are you talking about?
>
> > In the latest branch of the kernel, the EHCI driver has some "Enhanced
> > Transaction Translation" scheduling. This would be great for me to use
> > as it seems to directly address the issues I've seen. However, I'm not
> > really sure on how to proceed because the DWC_OTG driver is not GPL code
>
> Oops? if that wa the case you could not use (and distribute) this code
> in a Linux context at all.
>
> > while the EHCI code I'd like to use is. Therefore, I don't believe that
> > I can port the Enhanced Transaction Translation routine into the DWC_OTG
> > driver without violating both the GPL and Synopsis's own driver.
>
> What makes you think so?
>
> The Synopsis dwc_otg driver license does not seem to be in conflict
> to the GPL, if you ask me (but then, I am not a layer). When we
> worked on this, we were assured that the use of this driver source in
> the context of GPLed software like the Linux kernel (or U-Boot) was
> not considered an issue by Synopsis.
>
> > Does anyone have a suggestion on how to proceed?
>
> We have been doing some work on the DWC drivers in the past, fixing a
> number of issues. [We never attempted to psuh any of this into
> mainline as the Synopsis drivers are - in our opinion - not
> avcceptable for mainline but require more or less a rewrite from
> scratch. But you can find all this stuff in our linux-2.6-denx repo.]
>
> I recommend you give a try to our latest stable branch.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-20 20:54 UTC (permalink / raw)
To: Masami Hiramatsu; +Cc: Mahesh Jagannath Salgaonkar, linuxppc-dev
In-Reply-To: <4B2B934C.1060807@redhat.com>
In message <4B2B934C.1060807@redhat.com> you wrote:
>
>
> Mahesh Jagannath Salgaonkar wrote:
> > Michael Neuling wrote:
> >> In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
> >>> Hi Michael,
> >>>
> >>> Michael Neuling wrote:
> >>>>> + * regs_get_argument_nth() - get Nth argument at function call
> >>>>> + * @regs: pt_regs which contains registers at function entry.
> >>>>> + * @n: argument number.
> >>>>> + *
> >>>>> + * regs_get_argument_nth() returns @n th argument of a function call.
> >>>>> + * Since usually the kernel stack will be changed right after
> >>>>> function en
> >> try
> >>>> ,
> >>>>> + * you must use this at function entry. If the @n th entry is NOT
> >>>>> in the
> >>>>> + * kernel stack or pt_regs, this returns 0.
> >>>>> + */
> >>>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned
> >>>>> int n)
> >>>>> +{
> >>>>> + if (n < ARRAY_SIZE(arg_offs_table))
> >>>>> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
> >>>>> + else {
> >>>>> + /*
> >>>>> + * If more arguments are passed that can be stored in
> >>>>> + * registers, the remaining arguments are stored in the
> >>>>> + * parameter save area located at fixed offset from stack
> >>>>> + * pointer.
> >>>>> + * Following the PowerPC ABI, the first few arguments are
> >>>>> + * actually passed in registers (r3-r10), with equivalent
> >>>>> space
> >>>>> + * left unused in the parameter save area.
> >>>>> + */
> >>>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
> >>>>> + return regs_get_kernel_stack_nth(regs, n);
> >>>> How do we handle FP args?
> >>> Currently this patch does not support FP args.
> >>
> >> This might be OK. I don't think we use floating point parameters in any
> >> function definitions in the kernel.
> >> We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
> >> they are static inline, so they probably don't even end up as
> >> functions.
> >> I guess we need to make sure that we're not limiting the interface in
> >> such a way that we can't support it later if the above changes.
> >> regs_get_argument_nth returns an unsigned long which makes returning a
> >> 128 bit VMX register impossible. This might be a show stopper for me.
> >> How are the x86 guys dealing with this?
> >>
> > Nope, x86 does not deal with bigger registers (Masami, correct me if I
> > am wrong). The return data type is opaque to user. Hence this enables us
> > to handle any such situations in future without effecting user space API.
>
> Right, we don't use those bigger registers in the kernel context.
> (some special functions use it inside, but most of codes
> are just using general regs)
Sure, but kernel interfaces are for now. What happens if this changes in
the future?
> And regs_get_argument_nth is just an accessor of pt_regs field.
> This means that it just provides field in pt_regs.
Sure, that's how it's implemented, but that's not what the name of the
function suggests it does.
Mikey
>
> >>>>> + }
> >>>>> +}
> >>>>> +/*
> >>>>> * does not yet catch signals sent when the child dies.
> >>>>> * in exit.c or in signal.c.
> >>>>> */
> >>>>> Index: linux-2.6-tip/kernel/trace/Kconfig
> >>>>> ===================================================================
> >>>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> >>>>> +++ linux-2.6-tip/kernel/trace/Kconfig
> >>>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
> >>>>>
> >>>>> config KPROBE_EVENT
> >>>>> depends on KPROBES
> >>>>> - depends on X86
> >>>>> + depends on X86 || PPC
> >>>>> bool "Enable kprobes-based dynamic events"
> >>>>> select TRACING
> >>>>> default y
> >>>>>
> >>>>> _______________________________________________
> >>>>> Linuxppc-dev mailing list
> >>>>> Linuxppc-dev@lists.ozlabs.org
> >>>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>>>>
> >>> Thanks for reviewing.
> >>
> >> We are creating a new user space API here, so I'm keen for others to take
> >> a good look at the interface before we commit to something we are going
> >> to have to keep forever.
> >> Who is the main consumer of this (/me is pretty ignorant of kprobes)?
> >> What do they think of the interface?
> >>
> > The user space API are already present in the upstream kernel and
> > currently only supported architecture is x86. This patch provides ppc
> > architecture specific interfaces that enables powerpc also in par with x86.
>
> Yes, there is a kprobe tracer in ftrace (see Documentation/trace/kprobetrace.
txt).
> and this tracer is only for probing kernel (not userspace).
>
> >
> > The main consumer would be kernel developers who would like to see
> > register values, arguments and stack when the probe hits at given text
> > address.
>
> Right.
>
> BTW, there is a user-space tools we have (tools/perf/builtin-probe.c).
> Currently, it's only for x86. Mahesh, You just need to add a register
> translation table in tools/perf/util/probe-finder.c for ppc support.
>
> Thank you!
>
> --
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America), Inc.
> Software Solutions Division
>
> e-mail: mhiramat@redhat.com
>
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-20 20:59 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <4B2B0EBF.5040302@linux.vnet.ibm.com>
In message <4B2B0EBF.5040302@linux.vnet.ibm.com> you wrote:
> Michael Neuling wrote:
> > In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
> >> Hi Michael,
> >>
> >> Michael Neuling wrote:
> >>>> + * regs_get_argument_nth() - get Nth argument at function call
> >>>> + * @regs: pt_regs which contains registers at function entry.
> >>>> + * @n: argument number.
> >>>> + *
> >>>> + * regs_get_argument_nth() returns @n th argument of a function call.
> >>>> + * Since usually the kernel stack will be changed right after function
en
> > try
> >>> ,
> >>>> + * you must use this at function entry. If the @n th entry is NOT in th
e
> >>>> + * kernel stack or pt_regs, this returns 0.
> >>>> + */
> >>>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int
n)
> >>>> +{
> >>>> + if (n < ARRAY_SIZE(arg_offs_table))
> >>>> + return *(unsigned long *)((char *)regs + arg_offs_table
[n]);
> >>>> + else {
> >>>> + /*
> >>>> + * If more arguments are passed that can be stored in
> >>>> + * registers, the remaining arguments are stored in the
> >>>> + * parameter save area located at fixed offset from sta
ck
> >>>> + * pointer.
> >>>> + * Following the PowerPC ABI, the first few arguments a
re
> >>>> + * actually passed in registers (r3-r10), with equivale
nt space
> >>>> + * left unused in the parameter save area.
> >>>> + */
> >>>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long
));
> >>>> + return regs_get_kernel_stack_nth(regs, n);
> >>> How do we handle FP args?
> >> Currently this patch does not support FP args.
> >
> > This might be OK. I don't think we use floating point parameters in any
> > function definitions in the kernel.
> >
> > We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
> > they are static inline, so they probably don't even end up as
> > functions.
> >
> > I guess we need to make sure that we're not limiting the interface in
> > such a way that we can't support it later if the above changes.
> >
> > regs_get_argument_nth returns an unsigned long which makes returning a
> > 128 bit VMX register impossible. This might be a show stopper for me.
> > How are the x86 guys dealing with this?
> >
> Nope, x86 does not deal with bigger registers (Masami, correct me if I
> am wrong). The return data type is opaque to user. Hence this enables us
> to handle any such situations in future without effecting user space API.
How is it opaque? It's an unsigned long? Is this function different to
what is presented to userspace?
Mikey
> >>>> + }
> >>>> +}
> >>>> +/*
> >>>> * does not yet catch signals sent when the child dies.
> >>>> * in exit.c or in signal.c.
> >>>> */
> >>>> Index: linux-2.6-tip/kernel/trace/Kconfig
> >>>> ===================================================================
> >>>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> >>>> +++ linux-2.6-tip/kernel/trace/Kconfig
> >>>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
> >>>>
> >>>> config KPROBE_EVENT
> >>>> depends on KPROBES
> >>>> - depends on X86
> >>>> + depends on X86 || PPC
> >>>> bool "Enable kprobes-based dynamic events"
> >>>> select TRACING
> >>>> default y
> >>>>
> >>>> _______________________________________________
> >>>> Linuxppc-dev mailing list
> >>>> Linuxppc-dev@lists.ozlabs.org
> >>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>>>
> >> Thanks for reviewing.
> >
> > We are creating a new user space API here, so I'm keen for others to take
> > a good look at the interface before we commit to something we are going
> > to have to keep forever.
> >
> > Who is the main consumer of this (/me is pretty ignorant of kprobes)?
> > What do they think of the interface?
> >
> The user space API are already present in the upstream kernel and
> currently only supported architecture is x86. This patch provides ppc
> architecture specific interfaces that enables powerpc also in par with x86.
>
> The main consumer would be kernel developers who would like to see
> register values, arguments and stack when the probe hits at given text
> address.
>
> > Mikey
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: DWC_OTG Issues
From: Wolfgang Denk @ 2009-12-20 21:58 UTC (permalink / raw)
To: Hunter Cobbs; +Cc: linuxppc-dev
In-Reply-To: <1261340025.3473.15.camel@mobiLinux>
Dear Hunter Cobbs,
In message <1261340025.3473.15.camel@mobiLinux> you wrote:
>
> We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit
> before, although at the time you were doing some work for AMCC on just
> accessing devices across a hub in general. We've been using the driver
> for a few months now and it is very stable on first-use of the driver,
> but once we close a full-speed port and try to reopen, that's when we
> get error concerning not being able to allocate resources and getting
> -28 errors. I don't have anything precise in front of me at the moment,
> my test equipment is at the office. But this seems to be the issues
> that lead to the Enhanced Transaction Translation Scheduling changes in
> the main-line kernel.
If you have a detailed bug report, ideally including an easy to
reproduce test case to trigger the problem then please feel free to
send it to our support address.
> I'm mainly being, I believe, overly cautious about not including GPL
> code in the Synopsis driver simply because I'd rather be overly careful
> than be exposed to some liability later down the road if Synopsis
> decides they want to make their driver completely proprietary. While
> the code is available, I'm not sure if we can include code from GPL
> sources in the Synopsis drivers without requiring the Synopsis driver to
> become completely GPL. I am also not a lawyer, but I'd rather be
> cautious.
Well, their license is relatively simple: the driver is unsupported,
it "IS NOT an item of Licensed Software or Licensed Product under any
End User Software License Agreement or Agreement for Licensed
Product", and you "are permitted to use andredistribute this Software
in source and binary forms, with or without modification, provided
that redistributions of source code must retain this notice." And
there is no warranty, of course.
IANAL, but I see no risks here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I ever needed a brain transplant, I'd choose a teenager's because
I'd want a brain that had never been used.
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Michael Neuling @ 2009-12-20 23:59 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <1261170452.8134.13.camel@jschopp-laptop>
> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
Please give this a more appropriate name.
> In order to boot with more than 64 cores on machines that support the
> ibm,client-architecture RTAS call a new field has been added to the
> structure. This patch updates that field and adds a few others in the
> process.
Please detail what these are here.
> It would be good if this could go in as a bugfix.
>
> Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
>
> Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
> @@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v
> #define OV5_CMO 0x00
> #endif
>
> +/* Option Vector 6: IBM PAPR hints */
> +#define OV6_LINUX 0x02 /* Linux is our OS */
> +
> /*
> * The architecture vector has an array of PVR mask/value pairs,
> * followed by # option vectors - 1, followed by the option vectors.
> @@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve
> W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
> W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
> W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
> - 5 - 1, /* 5 option vectors */
> + 6 - 1, /* 6 option vectors */
>
> /* option vector 1: processor architectures supported */
> 3 - 2, /* length */
> @@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve
> 0, /* don't halt */
>
> /* option vector 5: PAPR/OF options */
> - 5 - 2, /* length */
> + 13 - 2, /* length */
> 0, /* don't ignore, don't halt */
> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
> 0,
> OV5_CMO,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + W(NR_CPUS/4), /* max cores supported */
4?
> +
> + /* option vector 6: IBM PAPR hints */
> + 4 - 2,
Please put a comment next to these to say what it is.
> + 0, /* reserved */
> + 0, /* 1 == no secondary pteg */
> + OV6_LINUX,
> +
> + /* option vector 7: IBM PAPR OS identification */
> + /* a human readable ascii string will go here */
Can we do this now or remove the comment. Maybe UTS_RELEASE or
something like that.
Mikey
> };
>
> /* Old method - ELF header with PT_NOTE sections */
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Tony Breeds @ 2009-12-21 0:44 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <1261170452.8134.13.camel@jschopp-laptop>
On Fri, Dec 18, 2009 at 03:07:32PM -0600, Joel Schopp wrote:
> In order to boot with more than 64 cores on machines that support the
> ibm,client-architecture RTAS call a new field has been added to the
> structure. This patch updates that field and adds a few others in the
> process. It would be good if this could go in as a bugfix.
But it's not really is it? What does it fix?
> Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
>
> Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
> +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
> @@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v
> #define OV5_CMO 0x00
> #endif
>
> +/* Option Vector 6: IBM PAPR hints */
> +#define OV6_LINUX 0x02 /* Linux is our OS */
> +
> /*
> * The architecture vector has an array of PVR mask/value pairs,
> * followed by # option vectors - 1, followed by the option vectors.
> @@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve
> W(0xffffffff), W(0x0f000003), /* all 2.06-compliant */
> W(0xffffffff), W(0x0f000002), /* all 2.05-compliant */
> W(0xfffffffe), W(0x0f000001), /* all 2.04-compliant and earlier */
> - 5 - 1, /* 5 option vectors */
> + 6 - 1, /* 6 option vectors */
>
> /* option vector 1: processor architectures supported */
> 3 - 2, /* length */
> @@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve
> 0, /* don't halt */
>
> /* option vector 5: PAPR/OF options */
> - 5 - 2, /* length */
> + 13 - 2, /* length */
> 0, /* don't ignore, don't halt */
> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
> 0,
> OV5_CMO,
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
> + 0, /* reserved */
Not so much reserved, as unused by us.
> + W(NR_CPUS/4), /* max cores supported */
4? I can see a case for 2 or just plain NR_CPUS, but 4 is wrong.
> + /* option vector 6: IBM PAPR hints */
> + 4 - 2,
We all know this is a length, but please follow the style in this structure.
> + 0, /* reserved */
> + 0, /* 1 == no secondary pteg */
I think the "1 == " confuses things.
> + OV6_LINUX,
Does filling in the vector actually let us boot on systems where we do not already?
> +
> + /* option vector 7: IBM PAPR OS identification */
> + /* a human readable ascii string will go here */
Either fill it in or leave the comments out.
Yours Tony
^ permalink raw reply
* [PATCH-V2] mpc8xxx_gpio: add interrupt support
From: Peter Korsgaard @ 2009-12-21 12:26 UTC (permalink / raw)
To: avorontsov, galak, linuxppc-dev
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
.../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 22 +++-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 147 ++++++++++++++++++++
2 files changed, 168 insertions(+), 1 deletions(-)
Changes since v1:
- Document OF binding for IRQ as requested by Kumar.
diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
index d015dce..b0019eb 100644
--- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
@@ -11,7 +11,7 @@ Required properties:
83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
+ - interrupts : Interrupt mapping for GPIO IRQ.
- interrupt-parent : Phandle for the interrupt controller that
services interrupts for this device.
- gpio-controller : Marks the port as GPIO controller.
@@ -38,3 +38,23 @@ Example of gpio-controller nodes for a MPC8347 SoC:
See booting-without-of.txt for details of how to specify GPIO
information for devices.
+
+To use GPIO pins as interrupt sources for peripherals, specify the
+GPIO controller as the interrupt parent and define GPIO number +
+trigger mode using the interrupts property, which is defined like
+this:
+
+interrupts = <number trigger>, where:
+ - number: GPIO pin (0..31)
+ - trigger: trigger mode:
+ 2 = trigger on falling edge
+ 3 = trigger on both edges
+
+Example of device using this is:
+
+ funkyfpga@0 {
+ compatible = "funky-fpga";
+ ...
+ interrupts = <4 3>;
+ interrupt-parent = <&gpio1>;
+ };
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index ee1c0e1..b4f861a 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -15,6 +15,7 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/gpio.h>
+#include <linux/irq.h>
#define MPC8XXX_GPIO_PINS 32
@@ -34,6 +35,7 @@ struct mpc8xxx_gpio_chip {
* open drain mode safely
*/
u32 data;
+ struct irq_host *irq;
};
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
@@ -127,12 +129,136 @@ static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val
return 0;
}
+static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ if (mpc8xxx_gc->irq && offset < MPC8XXX_GPIO_PINS)
+ return irq_create_mapping(mpc8xxx_gc->irq, offset);
+ else
+ return -ENXIO;
+}
+
+static void mpc8xxx_gpio_irq_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_desc_data(desc);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned int mask;
+
+ mask = in_be32(mm->regs + GPIO_IER) & in_be32(mm->regs + GPIO_IMR);
+ if (mask)
+ generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
+ 32 - ffs(mask)));
+}
+
+static void mpc8xxx_irq_unmask(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+
+ setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+}
+
+static void mpc8xxx_irq_mask(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+
+ clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+}
+
+static void mpc8xxx_irq_ack(unsigned int virq)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+
+ out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(virq_to_hw(virq)));
+}
+
+static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long flags;
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ setbits32(mm->regs + GPIO_ICR,
+ mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(mm->regs + GPIO_ICR,
+ mpc8xxx_gpio2mask(virq_to_hw(virq)));
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct irq_chip mpc8xxx_irq_chip = {
+ .name = "mpc8xxx-gpio",
+ .unmask = mpc8xxx_irq_unmask,
+ .mask = mpc8xxx_irq_mask,
+ .ack = mpc8xxx_irq_ack,
+ .set_type = mpc8xxx_irq_set_type,
+};
+
+static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ set_irq_chip_data(virq, h->host_data);
+ set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
+ set_irq_type(virq, IRQ_TYPE_NONE);
+
+ return 0;
+}
+
+static int mpc8xxx_gpio_irq_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_flags)
+
+{
+ /* interrupt sense values coming from the device tree equal either
+ * EDGE_FALLING or EDGE_BOTH
+ */
+ *out_hwirq = intspec[0];
+ *out_flags = intspec[1];
+
+ return 0;
+}
+
+static struct irq_host_ops mpc8xxx_gpio_irq_ops = {
+ .map = mpc8xxx_gpio_irq_map,
+ .xlate = mpc8xxx_gpio_irq_xlate,
+};
+
static void __init mpc8xxx_add_controller(struct device_node *np)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct of_mm_gpio_chip *mm_gc;
struct of_gpio_chip *of_gc;
struct gpio_chip *gc;
+ unsigned hwirq;
int ret;
mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
@@ -157,11 +283,32 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
else
gc->get = mpc8xxx_gpio_get;
gc->set = mpc8xxx_gpio_set;
+ gc->to_irq = mpc8xxx_gpio_to_irq;
ret = of_mm_gpiochip_add(np, mm_gc);
if (ret)
goto err;
+ hwirq = irq_of_parse_and_map(np, 0);
+ if (hwirq == NO_IRQ)
+ goto skip_irq;
+
+ mpc8xxx_gc->irq =
+ irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, MPC8XXX_GPIO_PINS,
+ &mpc8xxx_gpio_irq_ops, MPC8XXX_GPIO_PINS);
+ if (!mpc8xxx_gc->irq)
+ goto skip_irq;
+
+ mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
+
+ /* ack and mask all irqs */
+ out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
+ out_be32(mm_gc->regs + GPIO_IMR, 0);
+
+ set_irq_data(hwirq, mpc8xxx_gc);
+ set_irq_chained_handler(hwirq, mpc8xxx_gpio_irq_cascade);
+
+skip_irq:
return;
err:
--
1.6.5
^ permalink raw reply related
* AMCC 405EX Rev D PVR
From: Lee Nipper @ 2009-12-21 15:37 UTC (permalink / raw)
To: linuxppc-dev
I have observed an odd behavior in the latest 405EX revision parts (Rev D).
Upon first power up on our custom board,
the 405EX Rev D shows a value of 0x12911470 in the PVR register.
After a reset, the 405EX Rev D shows the correct value of 0x12911475
in the PVR register.
The 405EX Rev C part had a steady 0x1291147F on first power up on the
same board.
Has anyone seen this ?
Is a wider reset pulse is required for the Rev D 405EX ?
Thanks for any feedback,
Lee
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-21 18:15 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <29526.1261353566@neuling.org>
>> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
>>
>
> Please give this a more appropriate name.
>
Any suggestions?
>
>> In order to boot with more than 64 cores on machines that support the
>> ibm,client-architecture RTAS call a new field has been added to the
>> structure. This patch updates that field and adds a few others in the
>> process.
>>
>
> Please detail what these are here.
>
OK.
>> + W(NR_CPUS/4), /* max cores supported */
>>
>
> 4?
>
>
4 is the new 2. Since you don't know the actual threads per core at
this point in boot you have to be conservative and go with the maximum
number of any processor. See page 4 of these charts:
http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>
>
> Can we do this now or remove the comment. Maybe UTS_RELEASE or
> something like that.
>
I'll just remove the comment for now.
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-21 18:22 UTC (permalink / raw)
To: Joel Schopp, benh, linuxppc-dev
In-Reply-To: <20091221004458.GI30375@ozlabs.org>
Tony Breeds wrote:
> On Fri, Dec 18, 2009 at 03:07:32PM -0600, Joel Schopp wrote:
>
>> In order to boot with more than 64 cores on machines that support the
>> ibm,client-architecture RTAS call a new field has been added to the
>> structure. This patch updates that field and adds a few others in the
>> process. It would be good if this could go in as a bugfix.
>>
>
> But it's not really is it? What does it fix?
>
It fixes kernels compiled with NR_CPUS where NR_CPUS > 256.
>
>> /* option vector 5: PAPR/OF options */
>> - 5 - 2, /* length */
>> + 13 - 2, /* length */
>> 0, /* don't ignore, don't halt */
>> OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY |
>> OV5_DONATE_DEDICATE_CPU | OV5_MSI,
>> 0,
>> OV5_CMO,
>> + 0, /* reserved */
>> + 0, /* reserved */
>> + 0, /* reserved */
>> + 0, /* reserved */
>>
>
> Not so much reserved, as unused by us.
>
They were all reserved until recently, and the last 2 of the 4 are still
reserved, while we just don't use the first two yet. I'll remove the
comments from the first 2.
>
>> + W(NR_CPUS/4), /* max cores supported */
>>
>
> 4? I can see a case for 2 or just plain NR_CPUS, but 4 is wrong.
>
4 is the new 2. Since the actual threads per core is unknown at this
point in boot you have to be conservative and go with the maximum number
of any processor. See page 4 of these charts:
http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>
>> + /* option vector 6: IBM PAPR hints */
>> + 4 - 2,
>>
>
> We all know this is a length, but please follow the style in this structure.
>
OK.
>
>> + 0, /* reserved */
>> + 0, /* 1 == no secondary pteg */
>>
>
> I think the "1 == " confuses things.
>
I'll remove it then.
>
>> + OV6_LINUX,
>>
>
> Does filling in the vector actually let us boot on systems where we do not already?
>
Will add description to the email body on this one.
>
>> +
>> + /* option vector 7: IBM PAPR OS identification */
>> + /* a human readable ascii string will go here */
>>
>
> Either fill it in or leave the comments out.
>
I'll leave the comment out.
^ permalink raw reply
* Trouble specifying dts gpio-leds with GPIO expander chip
From: Bill Gatliff @ 2009-12-21 19:40 UTC (permalink / raw)
To: Linux/PPC Development
Guys:
I'm trying to come up with the right stuff for my dts file to assign a
Linux "heartbeat" trigger to an I2C GPIO expansion device (MAX7314).
I'm running on a platform that is very similar to the lite5200b, with
linux-2.6.32. I'm a bit new to the device tree concept, having come
most recently from an ARM world, so please be gentle... :)
I have this so far:
soc5200@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc5200b-immr","simple-bus";
ranges = <0 0xf0000000 0x0000c000>;
reg = <0xf0000000 0x00000100>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
...
i2c@3d40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
lext20: max7314@20 {
#gpio-cells = <2>;
compatible = "maxim,max7314","phillips,pca953x";
reg = <0x20>;
linux,phandle = <0x20>;
gpio-controller;
};
...
};
};
...
system {
compatible = "simple-bus";
gpio-leds {
compatible = "gpio-leds";
heartbeat {
gpios = <&lext20 3 0>;
linux,default-trigger = "heartbeat";
};
};
};
...
The MAX7314 chip is showing up under /debug/gpio:
# cat /debug/gpio
...
GPIOs 198-213, i2c/1-0020, max7314, can sleep:
And, indeed, I can twiddle the LED by hand:
# echo 201 > /sys/class/gpio/export
# while true; do for led in high low; \
do echo $led > /sys/class/gpio/gpio201/direction; \
sleep 1; done; done
(observe blinking)
But I see this at boot:
Skipping unavailable LED gpio -19 (heartbeat)
That error code is -ENODEV. I double-checked that gpio-leds is showing
up on of_platform:
# ls /sys/bus/of_platform/devices/
...
gpio-leds.2
...
I'm stumped. Could it be that the startup code is trying to register
the heartbeat device before it has registered the MAX7314, so it doesn't
know yet that the GPIO line exists?
Anyone have any suggestions?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Michael Neuling @ 2009-12-21 21:12 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev
In-Reply-To: <4B2FBB3F.8030703@austin.ibm.com>
> >> Subject: Re: [PATCH] powerpc: update ibm,client-architecture
> >>
> >
> > Please give this a more appropriate name.
> >
> Any suggestions?
Something that's more descriptive of what the patch does. Say "Add
max CPU nodes field to ibm,client-architecture call"
> >
> >> In order to boot with more than 64 cores on machines that support the
> >> ibm,client-architecture RTAS call a new field has been added to the
> >> structure. This patch updates that field and adds a few others in the
> >> process.
> >>
> >
> > Please detail what these are here.
> >
> OK.
> >> + W(NR_CPUS/4), /* max cores supported */
FYI reading the PAPR, this comment should technically be "max 'cpu'
nodes presented".
> >>
> >
> > 4?
> >
> >
> 4 is the new 2.
I'd still be asking what 2 is. It's needs a #define to make clearer
what you are doing.
> Since you don't know the actual threads per core at
> this point in boot you have to be conservative and go with the maximum
> number of any processor. See page 4 of these charts:
> http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
I don't think hard wiring 4 in here is right. If we are booting a
machine with SMT2, we will put only half the number of cores that we can
handle in this field. This is going to break a lot of machines where
people have compiled with NR_CPUS = thread number.
I think you just want to put NR_CPUS here.
Mikey
> >
> >
> > Can we do this now or remove the comment. Maybe UTS_RELEASE or
> > something like that.
> >
> I'll just remove the comment for now.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Trouble specifying dts gpio-leds with GPIO expander chip
From: Anton Vorontsov @ 2009-12-21 21:55 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Linux/PPC Development
In-Reply-To: <4B2FCF40.3050204@billgatliff.com>
On Mon, Dec 21, 2009 at 01:40:48PM -0600, Bill Gatliff wrote:
[...]
> I'm stumped. Could it be that the startup code is trying to register
> the heartbeat device before it has registered the MAX7314, so it doesn't
> know yet that the GPIO line exists?
>
> Anyone have any suggestions?
drivers/gpio/pca953x.c doesn't register itself with the
OF GPIO infrastructure (plus the driver has an absolutely
bogus linux,gpio-base stuff, heh).
As an example of how to do the OF GPIO properly, see
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c:mcu_gpiochip_add().
Though, soon there will be an easier way to register I2C/SPI chips
with the OF GPIO infrastructure.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: update ibm,client-architecture
From: Joel Schopp @ 2009-12-21 22:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <7024.1261429935@neuling.org>
>> OK.
>>
>>>> + W(NR_CPUS/4), /* max cores supported */
>>>>
>
> FYI reading the PAPR, this comment should technically be "max 'cpu'
> nodes presented".
>
I applied a disambiguation filter to the comment since cpus can mean a
lot of things these days ( ie hardware threads, cores, chips) , but a
core is a core.
>> 4 is the new 2.
>>
>
> I'd still be asking what 2 is. It's needs a #define to make clearer
> what you are doing.
>
>
I'll add a #define
>> Since you don't know the actual threads per core at
>> this point in boot you have to be conservative and go with the maximum
>> number of any processor. See page 4 of these charts:
>> http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>>
>
> I don't think hard wiring 4 in here is right. If we are booting a
> machine with SMT2, we will put only half the number of cores that we can
> handle in this field. This is going to break a lot of machines where
> people have compiled with NR_CPUS = thread number.
>
> I think you just want to put NR_CPUS here.
>
>
It's a bad interface. No matter what you choose there will be a
downside. 1) If you choose NR_CPUS, the best case of how many you could
boot without SMT, then when you boot with SMT2 or SMT4 you can get
assigned more cpus than you can boot. 2) If you choose NR_CPUS/4, the
worst case of how many you could boot, and you get a large machine with
SMT2 or SMT1 you might have said you support less cpus than you actually
do and thus not boot all the cpus. So no matter what you choose you
could be not booting cpus in some theoretical scenario.
^ permalink raw reply
* Question on MPC52xx IRQ[123] pins
From: Bill Gatliff @ 2009-12-21 22:30 UTC (permalink / raw)
To: Linux/PPC Development
Guys:
I think I already know the answer to this, having read most of the
MPC52xx manual. But I'll ask anyway, just to be sure I'm not missing
something obvious... :)
Is it possible to treat the external IRQ[123] pins on the MPC52xx as
GPIO inputs? And if so, how do I tweak my dts file and other code, if
necessary, to make that happen?
Reason I ask is, I'm trying to enhance
drivers/input/misc/rotary-encoder.c to use device trees, and one of the
encoder inputs is on IRQ2. My strategy so far is to just provide an
of_probe() function that builds a rotary_encoder_platform_data structure
and then calls platform_device_register(). And that ain't working. :)
First off, the rotary-encoder driver assumes that both of its inputs are
both known to gpiolib, so that they can do both gpio_to_irq() and
gpio_get_value() on them. There isn't any existing code that I can find
that allows you to read the states of IRQ pins, be it under gpiolib or
otherwise. And I think the reason for that is that there's no way to
actually read the states of those pins at all--- the hardware just
doesn't work that way.
Or am I missing something?
Second, if I get all this working then my rotary encoders won't be
platform devices--- they'll be openfirmware devices, which means I'll
have to do other work in the code as well. That's a subtle point I
know, but rotary-encoder's assumption that all rotary encoder devices
are also platform devices is kind of like mixing policy with
implementation, it turns out. Almost like trying to reuse a PCI driver
as a platform driver. I didn't spot how important that was until I
started hacking on the code itself...
Thanks!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Trouble specifying dts gpio-leds with GPIO expander chip
From: Grant Likely @ 2009-12-21 22:32 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Linux/PPC Development, Anton Vorontsov
In-Reply-To: <4B2FCF40.3050204@billgatliff.com>
On Mon, Dec 21, 2009 at 12:40 PM, Bill Gatliff <bgat@billgatliff.com> wrote=
:
> Guys:
>
>
> I'm trying to come up with the right stuff for my dts file to assign a
> Linux "heartbeat" trigger to an I2C GPIO expansion device (MAX7314).
> I'm running on a platform that is very similar to the lite5200b, with
> linux-2.6.32. =A0I'm a bit new to the device tree concept, having come
> most recently from an ARM world, so please be gentle... =A0:)
>
> I have this so far:
>
> =A0 =A0 =A0 =A0soc5200@f0000000 {
> =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc5200b-immr","simple-bus";
> =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0 0xf0000000 0x0000c000>;
> =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xf0000000 0x00000100>;
> =A0 =A0 =A0 =A0 =A0 =A0bus-frequency =3D <0>; =A0 =A0 =A0 =A0// from boot=
loader
> =A0 =A0 =A0 =A0 =A0 =A0system-frequency =3D <0>; =A0 =A0 =A0 =A0// from b=
ootloader
> =A0 =A0...
> =A0 =A0 =A0 =A0 =A0 =A0i2c@3d40 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc5200b-i2c","fsl,mpc=
5200-i2c","fsl-i2c";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x3d40 0x40>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <2 16 0>;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lext20: max7314@20 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #gpio-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "maxim,max7314=
","phillips,pca953x";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x20>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 linux,phandle =3D <0x20>;
Drop the linux,phandle. The phandle property is generated
automatically by the device tree compiler. This could mess things up.
As Anton says, the 7314 driver doesn't register the GPIO in a way that
the of_gpio layer understands, so cannot translate. What the of_gpio
infrastructure *should* be doing is to fetch the device tree node out
of the struct device and use that path to translate device tree GPIO
references to Linux GPIO numbers. ie.
dev_archdata_get_node(gc->dev->archdata). Then as long as the device
tree node pointer is set in the struct device (which it always should
be), then OF translations for GPIO numbers should work without driver
changes.
In other words; given a device tree node pointer; loop over all the
registered GPIO devices and look for a matching node pointer in the
struct device. When a matching one is found; do the translation.
However, on further thought, this may require an additional hook added
to the gpio_chip registration to override the translation function if
necessary.
Anton, what are you thinking about to simplify OF GPIO registrations?
Bill, in the mean time you could do as Anton suggests and modify the
GPIO driver to have an of_gpio_chip allocation.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* MPC8313e RDB rev A4 and rev C network throughput
From: RONETIX - Asen Dimov @ 2009-12-21 22:27 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I have made some test on network throughput with MPC8313e RDB revA4 and
revC.
Some have mentioned that CSB(Coherent System Bus) frequency or untuned
TCP/IP stack,
could cause decrease of network throughput.
**Test results
-on MPC8313e RDB revA4 with kernel 2.6.20 and u-boot 1.1.6 created with
ltib-mpc8313erdb-20070824
iperf -c 172.16.0.1 -l 2m -w 256k
-throughput is 510Mbps
-on MPC8313e RDB revA4 with kernel 2.6.23 and u-boot 1.3.0 generated
with ltib-mpc8313erdb-20081222
iperf -c 172.16.0.1 -l 2m -w 256k
-throughput is 510Mbps
-on MPC8313e RDB revC with kernel 2.6.23 (the same u-boot, kernel and
rootfs as in rev A4, only dtb file differs)
iperf -c 172.16.0.1 -l 2m -w 256k
-throughput is 360Mbps.
Have someone made such measurements? Any ideas why MPC8313e RDB revC
gives worser throughput than revA4?
** Notes
*The PC (CPU:Intel(R) Core(TM)2 Duo CPU, E8400 @ 3.00GHz;
RAM: 2x2G DDR2 @ 800Mhz ;
NIC: R8168B PCI Express Gigabit Ethernet controller, driver
8.014.00-NAPI;
OS: Fedora release 10 (Cambridge) with kernel:
2.6.27.38-170.2.113.fc10.i686.PAE #1 SMP )
*Commnads to set PC
ethtool -s eth0 autoneg off speed 1000 duplex full
ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 10000
echo 131071 > /proc/sys/net/core/rmem_max
echo 131071 > /proc/sys/net/core/wmem_max
echo "4096 1048576 8388608" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 1048576 8388608" > /proc/sys/net/ipv4/tcp_wmem
iperf -s -l 2m -w 70k
*The MPC8313e RDB(CPU: 333Mhz; CSB: 166Mhz) revA4 and revC(using PHY not
switch)
*Commnads to set a board before using iperf
ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 10000
#The PC lan card is set to advertise 1000Mbps only, so the
board switches to 1000Mbps too.
echo 131071 > /proc/sys/net/core/rmem_max
echo 131071 > /proc/sys/net/core/wmem_max
echo "4096 1048576 8388608" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 1048576 8388608" > /proc/sys/net/ipv4/tcp_wmem
Regards,
Asen
^ permalink raw reply
* Re: Question on MPC52xx IRQ[123] pins
From: Grant Likely @ 2009-12-21 23:16 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Linux/PPC Development
In-Reply-To: <4B2FF71E.10508@billgatliff.com>
On Mon, Dec 21, 2009 at 3:30 PM, Bill Gatliff <bgat@billgatliff.com> wrote:
> gpio_get_value() on them. =A0There isn't any existing code that I can fin=
d
> that allows you to read the states of IRQ pins, be it under gpiolib or
> otherwise. =A0And I think the reason for that is that there's no way to
> actually read the states of those pins at all--- the hardware just
> doesn't work that way.
Correct. IRQ2 can only be used as IRQ2. It cannot be used a GPIO.
(Well, I suppose you *could* try to hack into the interrupt controller
driver and fetch the pin state that way; but I don't know if you can
read the state of masked out IRQ pins, and it sure would be ugly.)
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-12-21 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
Hi Linus !
Here are some powerpc leftovers from the merge window. Mostly fixes,
plus a few embedded things that I didn't pull from Kumar in time.
Cheers,
Ben.
The following changes since commit 55639353a0035052d9ea6cfe4dde0ac7fcbb2c9f:
Linus Torvalds (1):
Linux 2.6.33-rc1
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Albert Herranz (3):
powerpc/gamecube/wii: Fix off-by-one error in ugecon/usbgecko_udbg
powerpc/gc/wii: hlwd-pic: convert irq_desc.lock to raw_spinlock
powerpc/gc/wii: Remove get_irq_desc()
Alexey Dobriyan (1):
powerpc/iseries: Convert to proc_fops
Anatolij Gustschin (1):
powerpc/44x: Extend Katmai dts for ADMA and RAID56 support
Anton Blanchard (3):
powerpc/defconfigs: Reduce 64bit vmlinux by making acenic and cramfs modules
powerpc/defconfigs: Disable token ring in powerpc defconfigs
powerpc/defconfigs: Set HZ=100 on pseries and ppc64 defconfigs
Anton Vorontsov (4):
powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
powerpc/83xx/suspend: Clear deep_sleeping after devices resume
powerpc/83xx/suspend: Save and restore SICRL, SICRH and SCCR
powerpc/83xx: Add power management support for MPC8315E-RDB boards
Benjamin Herrenschmidt (4):
powerpc/mm: Fix a WARN_ON() with CONFIG_DEBUG_PAGEALLOC and CONFIG_DEBUG_VM
powerpc: Fix MSI support on U4 bridge PCIe slot
Merge commit 'kumar/next' into merge
Merge commit 'jwb/next' into merge
David Daney (1):
powerpc: Convert BUG() to use unreachable()
David Gibson (1):
powerpc/mm: Fix stupid bug in subpge protection handling
Dmitry Eremin-Solenikov (4):
powerpc/83xx: mpc8349emitx - add gpio controller declarations
powerpc/83xx: mpc8349emitx - populate I2C busses in device tree
powerpc/83xx: mpc8349emitx - add OF descriptions of LocalBus devices
powerpc/83xx: mpc8349emitx - add leds-gpio binding
Felix Radensky (1):
powerpc/85xx: Workaround MPC8572/MPC8536 GPIO 1 errata.
Gautham R Shenoy (2):
powerpc/pseries: Don't panic when H_PROD fails during cpu-online.
powerpc/pseries: Make declarations of cpu_hotplug_driver_lock() ANSI compatible.
Mark Ware (1):
powerpc/cpm2_pic: Allow correct flow_types for port C interrupts
Mel Gorman (1):
powerpc/pseries: Select XICS and PCI_MSI PSERIES
Neil Campbell (1):
powerpc: Handle VSX alignment faults correctly in little-endian mode
Peter Korsgaard (1):
powerpc/gpio: support gpio_to_irq()
Robert Jennings (2):
mm: Add notifier in pageblock isolation for balloon drivers
powerpc: Make the CMM memory hotplug aware
Roel Kluin (1):
powerpc/85xx: Wrong variable returned on error
Sachin P. Sant (1):
powerpc/mm: Fix hash_utils_64.c compile errors with DEBUG enabled.
Sean MacLennan (1):
powerpc/44x: Increase warp SD buffer
Sebastian Andrzej Siewior (1):
powerpc/fsl: try to explain why the interrupt numbers are off by 16
Yang Li (2):
powerpc/mm: Fix typo of cpumask_clear_cpu()
powerpc/mpic: Fix problem that affinity is not updated
Yong Zhang (1):
powerpc/iseries: use DECLARE_COMPLETION_ONSTACK for non-constant completion
Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 ++++
arch/powerpc/boot/dts/katmai.dts | 52 ++++-
arch/powerpc/boot/dts/mpc8315erdb.dts | 27 ++
arch/powerpc/boot/dts/mpc8349emitx.dts | 82 +++++++-
arch/powerpc/boot/dts/warp.dts | 2 +-
arch/powerpc/boot/ugecon.c | 2 +-
arch/powerpc/configs/g5_defconfig | 6 +-
arch/powerpc/configs/iseries_defconfig | 4 +-
arch/powerpc/configs/ppc64_defconfig | 14 +-
arch/powerpc/configs/ppc64e_defconfig | 4 +-
arch/powerpc/configs/pseries_defconfig | 14 +-
arch/powerpc/include/asm/bug.h | 2 +-
arch/powerpc/include/asm/gpio.h | 5 +-
arch/powerpc/kernel/align.c | 63 ++++--
arch/powerpc/mm/hash_utils_64.c | 12 +-
arch/powerpc/mm/mmu_context_nohash.c | 2 +-
arch/powerpc/mm/pgtable_32.c | 2 +-
arch/powerpc/platforms/83xx/suspend.c | 52 ++++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 2 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 10 +-
arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c | 2 +-
arch/powerpc/platforms/iseries/mf.c | 147 +++++++-----
arch/powerpc/platforms/iseries/viopath.c | 2 +-
arch/powerpc/platforms/pseries/Kconfig | 2 +
arch/powerpc/platforms/pseries/cmm.c | 254 +++++++++++++++++++-
arch/powerpc/platforms/pseries/dlpar.c | 6 +-
arch/powerpc/platforms/pseries/smp.c | 4 +-
arch/powerpc/sysdev/cpm2_pic.c | 28 ++-
arch/powerpc/sysdev/fsl_pci.c | 8 +-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 21 ++-
arch/powerpc/sysdev/mpic.c | 19 +-
arch/powerpc/sysdev/mpic_msi.c | 11 +-
arch/powerpc/sysdev/mpic_u3msi.c | 46 +++-
drivers/base/memory.c | 19 ++
include/linux/memory.h | 27 ++
mm/page_alloc.c | 57 ++++-
37 files changed, 876 insertions(+), 178 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt
^ 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