* Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
From: Grant Likely @ 2013-10-15 22:55 UTC (permalink / raw)
To: Rob Herring, Thierry Reding
Cc: devicetree@vger.kernel.org, Russell King, linux-mips,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Rob Herring,
Ralf Baechle, sparclinux, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLE8aj511oF-gK7Gu5QfmHsQO3+oJ0KFkv0wmuo7i6eiw@mail.gmail.com>
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > The of_irq_to_resource() helper that is used to implement of_irq_count()
> > tries to resolve interrupts and in fact creates a mapping for resolved
> > interrupts. That's pretty heavy lifting for something that claims to
> > just return the number of interrupts requested by a given device node.
> >
> > Instead, use the more lightweight of_irq_map_one(), which, despite the
> > name, doesn't create an actual mapping. Perhaps a better name would be
> > of_irq_translate_one().
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
Applied, thanks.
g.
>
> > ---
> > drivers/of/irq.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 1752988..5f44388 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
> > */
> > int of_irq_count(struct device_node *dev)
> > {
> > + struct of_irq irq;
> > int nr = 0;
> >
> > - while (of_irq_to_resource(dev, nr, NULL))
> > + while (of_irq_map_one(dev, nr, &irq) == 0)
> > nr++;
> >
> > return nr;
> > --
> > 1.8.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
From: Grant Likely @ 2013-10-15 22:42 UTC (permalink / raw)
To: Rob Herring, Thierry Reding
Cc: devicetree@vger.kernel.org, Russell King, linux-mips,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Rob Herring,
Ralf Baechle, sparclinux, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLE8aj511oF-gK7Gu5QfmHsQO3+oJ0KFkv0wmuo7i6eiw@mail.gmail.com>
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > The of_irq_to_resource() helper that is used to implement of_irq_count()
> > tries to resolve interrupts and in fact creates a mapping for resolved
> > interrupts. That's pretty heavy lifting for something that claims to
> > just return the number of interrupts requested by a given device node.
> >
> > Instead, use the more lightweight of_irq_map_one(), which, despite the
> > name, doesn't create an actual mapping. Perhaps a better name would be
> > of_irq_translate_one().
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
Applied (and fixed to match the of_irq_map_one --> of_irq_parse_one
rename that I'm going to merge in v3.13).
g.
>
> > ---
> > drivers/of/irq.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 1752988..5f44388 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
> > */
> > int of_irq_count(struct device_node *dev)
> > {
> > + struct of_irq irq;
> > int nr = 0;
> >
> > - while (of_irq_to_resource(dev, nr, NULL))
> > + while (of_irq_map_one(dev, nr, &irq) == 0)
> > nr++;
> >
> > return nr;
> > --
> > 1.8.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
From: Benjamin Herrenschmidt @ 2013-10-15 20:47 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: linux-s390, gregkh, heiko.carstens, linuxppc-dev, linux-kernel,
brueckner, schwidefsky, jslaby
In-Reply-To: <20131015153626.GA6129@linux.vnet.ibm.com>
On Tue, 2013-10-15 at 17:36 +0200, Hendrik Brueckner wrote:
> Hi Benjamin,
>
> On Sat, Oct 12, 2013 at 07:43:24AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote:
> > > The tiocmget/tiocmset callbacks are used to set and get modem status and
> > > triggered through an tty ioctl.
> > >
> > > The dtr_rts() callback is different and it is used for DTS/RTS handshaking
> > > between the hvc_console (or any other tty_port) and the tty layer. The tty
> > > port layer uses this callback to signal the hvc_console whether to raise or
> > > lower the DTR/RTS lines. This is different than the ioctl interface to
> > > controls the modem status.
> >
> > Well, DTR at least is the same via both callbacks... Also normal handshaking
> > is normally RTS/CTS, only some HW setups "hijacks" DTR for RTS (old Macs come
> > to mind).
>
> Yep. DTR is changed in both callbacks but from different layers. The
> tiocmget/tiocmset are triggered through the ioctl. The dtr_rts() callback is
> called in hvc_close() to properly handle HUPCL to lower modem control lines
> after last process closes the device (hang up).
>
> This is also done in the hvsilib_close() in hvsi_lib.c:
>
> /* Clear our own DTR */
> if (!pv->tty || (pv->tty->termios.c_cflag & HUPCL))
> hvsilib_write_mctrl(pv, 0);
>
> This is actually what the dtr_rts() callback should trigger and I wonder
> whether it would be worth to introduce the dtr_rts() callback to encapsulate
> the "hvsilib_write_mctrl(pv, 0);" call from above.
>
> On the other hand, the dtr_rts() callback is a good encapsulation to not
> directly access the hp->tty to potentially prevent a layering violation. At
> least for the hvc_iucv() I do not want to deal with the "underlying" tty layer
> and introduce additional reference accounting.
>
> I hope this helps you to understand my rational for introducing the dtr_rts()
> callback.
I'm not sure :) We still end up basically with 2 callbacks to do the
same thing ... change the DTR line. It's odd at best, I still don't
quite see why hvc_console couldn't just use mctrl...
Cheers,
Ben.
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 20:39 UTC (permalink / raw)
To: Scott Wood; +Cc: Martin Hicks, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381868527.7979.713.camel@snotra.buserror.net>
On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> > > On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> > > <benh@kernel.crashing.org> wrote:
> > > > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> > > >> I've tracked the start of the strange instruction pointers in 'perf
> > > >> report' to a commit by Anton:
> > > >>
> > > >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> > > >> Author: Anton Blanchard <anton@samba.org>
> > > >> Date: Tue Jun 26 01:01:36 2012 +0000
> > > >>
> > > >> powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> > > >>
> > > >> I don't know enough about PPC to know what's going on, but reverting
> > > >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> > > >> report' output with 3.11.
> > > >
> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
> > > > (Scott ?)
> > >
> > > Yes, e300c3.
> >
> > Ok so I have a hard time figuring out how that patch can make a
> > difference since for all I can see, there is no perf backend upstream
> > for e300 at all :-(
> >
> > I must certainly be missing something ... Scott, can you have a look ?
>
> e300c3 has a core-fsl-emb style performance monitor (though Linux
> doesn't support it yet). If a bug was bisected to a change in
> core-book3s.c, then it's probably a coincidence due to moving code
> around.
Mort, can you see if just that change is enough to cause the problem ?
------------------- arch/powerpc/include/asm/perf_event.h --------------------
index 5c16b89..0bb2372 100644
@@ -26,8 +26,13 @@
#include <asm/ptrace.h>
#include <asm/reg.h>
+/*
+ * Overload regs->result to specify whether we should use the MSR (result
+ * is zero) or the SIAR (result is non zero).
+ */
#define perf_arch_fetch_caller_regs(regs, __ip) \
do { \
+ (regs)->result = 0; \
(regs)->nip = __ip; \
(regs)->gpr[1] = *(unsigned long *)__get_SP(); \
asm volatile("mfmsr %0" : "=r" ((regs)->msr)); \
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-10-15 20:33 UTC (permalink / raw)
To: leroy christophe; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <525D6CD4.5090403@c-s.fr>
On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote:
> Le 11/10/2013 17:13, Joakim Tjernlund a =C3=A9crit :
> > "Linuxppc-dev"
> > <linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@lists.ozlabs.or=
g>
> > wrote on 2013/10/11 14:56:40:
> >> Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of me=
mory
> > at
> >> bootup instead of 8. It is needed for "big" kernels for instance whe=
n
> > activating
> >> CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in init_=
32
> > too,
> >> otherwise memory allocation soon fails after startup.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>
> >> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S
> > linux-3.11/arch/powerpc/kernel/head_8xx.S
> >> --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02
> > 22:46:10.000000000 +0200
> >> +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.00000=
0000
> > +0200
> >> @@ -213,7 +213,12 @@
> >> */
> >> BUG_ON(first_memblock_base !=3D 0);
> >>
> >> +#ifdef CONFIG_PIN_TLB
> >> + /* 8xx can only access 24MB at the moment */
> >> + memblock_set_current_limit(min_t(u64, first_memblock_size,
> > 0x01800000));
> >> +#else
> >> /* 8xx can only access 8MB at the moment */
> >> memblock_set_current_limit(min_t(u64, first_memblock_size,
> > 0x00800000));
> >> +#endif
> >> }
> >> #endif /* CONFIG_8xx */
> > hmm, I think you should always map 24 MB (or less if RAM < 24 MB) and=
do
> > the same
> > in head_8xx.S.
> >
> > Or to keep it simple, just always map at least 16 MB here and in
> > head_8xx.S, assuming
> > that 16 MB is min RAM for any 8xx system running 3.x kernels.
> Yes we could do a more elaborated modification in the future. However i=
t=20
> also has an impact on the boot loader, so I'm not sure we should make i=
t=20
> the default without thinking twice.
>=20
> In the meantime, my patch does take into account the existing situation=
=20
> where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_TLB=
.
> I see it as a bug fix and I believe we should include it at least in=20
> order to allow including in the stable releases.
>=20
> Do you see any issue with this approach ?
The patch is fine, but I don't think it's stable material (BTW, if it
were, you should have marked it as such when submitting). If I
understand the situation correctly, there's no regression, and nothing
fails to work with CONFIG_PIN_TLB that would have worked without it.
It's just making CONFIG_PIN_TLB more useful.
-Scott
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Scott Wood @ 2013-10-15 20:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Martin Hicks, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381866837.17841.21.camel@pasglop>
On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> > On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> > >> I've tracked the start of the strange instruction pointers in 'perf
> > >> report' to a commit by Anton:
> > >>
> > >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> > >> Author: Anton Blanchard <anton@samba.org>
> > >> Date: Tue Jun 26 01:01:36 2012 +0000
> > >>
> > >> powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> > >>
> > >> I don't know enough about PPC to know what's going on, but reverting
> > >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> > >> report' output with 3.11.
> > >
> > > This is an e300 core right ? (603...). Do that have an SIAR at all
> > > (Scott ?)
> >
> > Yes, e300c3.
>
> Ok so I have a hard time figuring out how that patch can make a
> difference since for all I can see, there is no perf backend upstream
> for e300 at all :-(
>
> I must certainly be missing something ... Scott, can you have a look ?
e300c3 has a core-fsl-emb style performance monitor (though Linux
doesn't support it yet). If a bug was bisected to a change in
core-book3s.c, then it's probably a coincidence due to moving code
around.
-Scott
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 19:53 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3XmN2WNJ1cnorb5vfas7mB6tdNLxuupFja=u_wYS=cxmdQ@mail.gmail.com>
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> >> I've tracked the start of the strange instruction pointers in 'perf
> >> report' to a commit by Anton:
> >>
> >> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> >> Author: Anton Blanchard <anton@samba.org>
> >> Date: Tue Jun 26 01:01:36 2012 +0000
> >>
> >> powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
> >>
> >> I don't know enough about PPC to know what's going on, but reverting
> >> the changes to perf_instruction_pointer() gets me reasonable 'perf
> >> report' output with 3.11.
> >
> > This is an e300 core right ? (603...). Do that have an SIAR at all
> > (Scott ?)
>
> Yes, e300c3.
Ok so I have a hard time figuring out how that patch can make a
difference since for all I can see, there is no perf backend upstream
for e300 at all :-(
I must certainly be missing something ... Scott, can you have a look ?
Cheers,
Ben.
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Martin Hicks @ 2013-10-15 18:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381851009.17841.14.camel@pasglop>
On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
>> I've tracked the start of the strange instruction pointers in 'perf
>> report' to a commit by Anton:
>>
>> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
>> Author: Anton Blanchard <anton@samba.org>
>> Date: Tue Jun 26 01:01:36 2012 +0000
>>
>> powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
>>
>> I don't know enough about PPC to know what's going on, but reverting
>> the changes to perf_instruction_pointer() gets me reasonable 'perf
>> report' output with 3.11.
>
> This is an e300 core right ? (603...). Do that have an SIAR at all
> (Scott ?)
Yes, e300c3.
mh
--
Martin Hicks P.Eng. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
^ permalink raw reply
* Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Scott Wood @ 2013-10-15 17:40 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Mark Rutland, Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Li Yang-Leo-R58472, devicetree@vger.kernel.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B150C2B08@039-SN2MPN1-013.039d.mgd.msft.net>
On Mon, 2013-10-14 at 20:59 -0500, Tang Yuantian-B29983 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: 2013=E5=B9=B410=E6=9C=8815=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C=
6:13
> > To: Tang Yuantian-B29983
> > Cc: Wood Scott-B07421; Mark Rutland; devicetree@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org; Li Yang-Leo-R58472
> > Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in de=
vice
> > tree
> >=20
> > On Fri, 2013-10-11 at 21:52 -0500, Tang Yuantian-B29983 wrote:
> > > Thanks for your review.
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: 2013=E5=B9=B410=E6=9C=8812=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=
=AD 3:07
> > > > To: Mark Rutland
> > > > Cc: Tang Yuantian-B29983; devicetree@vger.kernel.org; linuxppc-
> > > > dev@lists.ozlabs.org; Li Yang-Leo-R58472
> > > > Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes i=
n
> > > > device tree
> > > >
> > > > I'm not sure I understand the "_0"/"_1" part, though. Doesn't ea=
ch
> > > > PLL just have one output, which the consumer may choose to divide=
by
> > > > 2 (or in some cases 4)? Why does that division need to be expose=
d
> > > > in the device tree as separate connections to the parent clock?
> > > >
> > > The device tree makes that quite clear.
> >=20
> > You chose to model it that way in the device tree; that doesn't make =
it
> > clear that the hardware works that way or that it's a good way to mod=
el
> > it.
> >=20
> > > Each PLL has several output which MUX node can take from.
> >=20
> > Point out where in the hardware documentation it says this. What I s=
ee
> > is a PLL that has one output, and a MUX register that can choose from
> > multiple PLL and divider options.
> >=20
> Take T4240 for example: see section 4.6.5.1 , (Page 141) in T4240RM Rev=
. D, 09/2012.
That shows the dividers as being somewhere in between the PLL and the
MUX. The MUX is where the divider is selected. There's nothing in the
PLL's programming interface that relates to the dividers. As such it's
simpler to model it as being part of the MUX.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: Joakim Tjernlund @ 2013-10-15 16:55 UTC (permalink / raw)
To: leroy christophe; +Cc: linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <525D6CD4.5090403@c-s.fr>
leroy christophe <christophe.leroy@c-s.fr> wrote on 2013/10/15 18:27:00:
>=20
>=20
> Le 11/10/2013 17:13, Joakim Tjernlund a =E9crit :
> > "Linuxppc-dev"
> > <linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@lists.ozlabs.org>
> > wrote on 2013/10/11 14:56:40:
> >> Activating CONFIG=5FPIN=5FTLB allows access to the 24 first Mbytes of =
memory
> > at
> >> bootup instead of 8. It is needed for "big" kernels for instance when
> > activating
> >> CONFIG=5FLOCKDEP=5FSUPPORT. This needs to be taken into account in=20
init=5F32
> > too,
> >> otherwise memory allocation soon fails after startup.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>
> >> diff -ur linux-3.11.org/arch/powerpc/kernel/head=5F8xx.S
> > linux-3.11/arch/powerpc/kernel/head=5F8xx.S
> >> --- linux-3.11.org/arch/powerpc/mm/init=5F32.c 2013-09-02
> > 22:46:10.000000000 +0200
> >> +++ linux-3.11/arch/powerpc/mm/init=5F32.c 2013-09-09=20
11:28:54.000000000
> > +0200
> >> @@ -213,7 +213,12 @@
> >> */
> >> BUG=5FON(first=5Fmemblock=5Fbase !=3D 0);
> >>
> >> +#ifdef CONFIG=5FPIN=5FTLB
> >> + /* 8xx can only access 24MB at the moment */
> >> + memblock=5Fset=5Fcurrent=5Flimit(min=5Ft(u64, first=5Fmemblock=5Fs=
ize,
> > 0x01800000));
> >> +#else
> >> /* 8xx can only access 8MB at the moment */
> >> memblock=5Fset=5Fcurrent=5Flimit(min=5Ft(u64, first=5Fmemblock=5F=
size,
> > 0x00800000));
> >> +#endif
> >> }
> >> #endif /* CONFIG=5F8xx */
> > hmm, I think you should always map 24 MB (or less if RAM < 24 MB) and=20
do
> > the same
> > in head=5F8xx.S.
> >
> > Or to keep it simple, just always map at least 16 MB here and in
> > head=5F8xx.S, assuming
> > that 16 MB is min RAM for any 8xx system running 3.x kernels.
> Yes we could do a more elaborated modification in the future. However it =
> also has an impact on the boot loader, so I'm not sure we should make it =
> the default without thinking twice.
>=20
> In the meantime, my patch does take into account the existing situation=20
> where you have 8Mb by default and 24Mb when you activate CONFIG=5FPIN=5FT=
LB.
> I see it as a bug fix and I believe we should include it at least in=20
> order to allow including in the stable releases.
>=20
> Do you see any issue with this approach ?
Not at all, so:
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: leroy christophe @ 2013-10-15 16:27 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <OFF3401910.4A8AA6D0-ONC1257C01.0052FC82-C1257C01.00539C55@transmode.se>
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
> "Linuxppc-dev"
> <linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org>
> wrote on 2013/10/11 14:56:40:
>> Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory
> at
>> bootup instead of 8. It is needed for "big" kernels for instance when
> activating
>> CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in init_32
> too,
>> otherwise memory allocation soon fails after startup.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S
> linux-3.11/arch/powerpc/kernel/head_8xx.S
>> --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02
> 22:46:10.000000000 +0200
>> +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.000000000
> +0200
>> @@ -213,7 +213,12 @@
>> */
>> BUG_ON(first_memblock_base != 0);
>>
>> +#ifdef CONFIG_PIN_TLB
>> + /* 8xx can only access 24MB at the moment */
>> + memblock_set_current_limit(min_t(u64, first_memblock_size,
> 0x01800000));
>> +#else
>> /* 8xx can only access 8MB at the moment */
>> memblock_set_current_limit(min_t(u64, first_memblock_size,
> 0x00800000));
>> +#endif
>> }
>> #endif /* CONFIG_8xx */
> hmm, I think you should always map 24 MB (or less if RAM < 24 MB) and do
> the same
> in head_8xx.S.
>
> Or to keep it simple, just always map at least 16 MB here and in
> head_8xx.S, assuming
> that 16 MB is min RAM for any 8xx system running 3.x kernels.
Yes we could do a more elaborated modification in the future. However it
also has an impact on the boot loader, so I'm not sure we should make it
the default without thinking twice.
In the meantime, my patch does take into account the existing situation
where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_TLB.
I see it as a bug fix and I believe we should include it at least in
order to allow including in the stable releases.
Do you see any issue with this approach ?
>
> Much of the need for pinning would go away if you adopted my 8MB pages
> from 2.4 to 3.x
>
> Jocke
>
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
From: Hendrik Brueckner @ 2013-10-15 15:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-s390, brueckner, gregkh, heiko.carstens, linuxppc-dev,
linux-kernel, Hendrik Brueckner, schwidefsky, jslaby
In-Reply-To: <1381524204.5630.91.camel@pasglop>
Hi Benjamin,
On Sat, Oct 12, 2013 at 07:43:24AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote:
> > The tiocmget/tiocmset callbacks are used to set and get modem status and
> > triggered through an tty ioctl.
> >
> > The dtr_rts() callback is different and it is used for DTS/RTS handshaking
> > between the hvc_console (or any other tty_port) and the tty layer. The tty
> > port layer uses this callback to signal the hvc_console whether to raise or
> > lower the DTR/RTS lines. This is different than the ioctl interface to
> > controls the modem status.
>
> Well, DTR at least is the same via both callbacks... Also normal handshaking
> is normally RTS/CTS, only some HW setups "hijacks" DTR for RTS (old Macs come
> to mind).
Yep. DTR is changed in both callbacks but from different layers. The
tiocmget/tiocmset are triggered through the ioctl. The dtr_rts() callback is
called in hvc_close() to properly handle HUPCL to lower modem control lines
after last process closes the device (hang up).
This is also done in the hvsilib_close() in hvsi_lib.c:
/* Clear our own DTR */
if (!pv->tty || (pv->tty->termios.c_cflag & HUPCL))
hvsilib_write_mctrl(pv, 0);
This is actually what the dtr_rts() callback should trigger and I wonder
whether it would be worth to introduce the dtr_rts() callback to encapsulate
the "hvsilib_write_mctrl(pv, 0);" call from above.
On the other hand, the dtr_rts() callback is a good encapsulation to not
directly access the hp->tty to potentially prevent a layering violation. At
least for the hvc_iucv() I do not want to deal with the "underlying" tty layer
and introduce additional reference accounting.
I hope this helps you to understand my rational for introducing the dtr_rts()
callback.
Thanks and kind regards,
Hendrik
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 15:30 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3X=LVHDMa+CTFS=O=F=DfU1=0cgcNzn-mEvXGaDXEZ+CBA@mail.gmail.com>
On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
> I've tracked the start of the strange instruction pointers in 'perf
> report' to a commit by Anton:
>
> commit 75382aa72f06823db7312ad069c3bae2eb3f8548
> Author: Anton Blanchard <anton@samba.org>
> Date: Tue Jun 26 01:01:36 2012 +0000
>
> powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
>
> I don't know enough about PPC to know what's going on, but reverting
> the changes to perf_instruction_pointer() gets me reasonable 'perf
> report' output with 3.11.
This is an e300 core right ? (603...). Do that have an SIAR at all
(Scott ?)
Cheers,
Ben.
> Thanks,
> mh
>
>
> On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks <mort@bork.org> wrote:
> > Hi,
> >
> > I've been trying to track down a performance regression that started
> > leading up to the v3.6 kernel, and while doing this I've been
> > gathering perf data on v3.6-rc and comparing it to v3.11 perf reports
> > of the same workload.
> >
> > With v3.6-rc kernels I get all symbols resolved like this:
> >
> > # Events: 39K cpu-clock-msecs
> > #
> > # Overhead Command Shared Object
> > Symbol
> > # ........ ........... ......................
> > ........................................
> > #
> > 9.69% nfsd [kernel.kallsyms] [k] csum_partial
> > 5.64% nfsd [kernel.kallsyms] [k] __do_softirq
> > 3.12% nfsd [sunrpc] [k] svc_create
> > 2.38% nfsd [kernel.kallsyms] [k] __queue_work
> > 1.91% nfsd [gianfar_driver] [k] gfar_poll
> > 1.73% nfsd [kernel.kallsyms] [k] memset
> > 1.54% nfsd [nfsd] [k] nfsd_vfs_read.isra.16
> > 1.40% ksoftirqd/0 [kernel.kallsyms] [k] finish_task_switch.isra.54
> > 1.30% nfsd [kernel.kallsyms] [k] get_page_from_freelist
> > 1.21% nfsd [gianfar_driver] [k] gfar_start_xmit
> > 1.20% nfsd [sunrpc] [k] svc_xprt_received
> >
> >
> > But when I perf on v3.11 kernels I see a lot of unresolved symbols:
> >
> > # Events: 69K cpu-clock-msecs
> > #
> > # Overhead Command Shared Object
> > Symbol
> > # ........ ............ .....................
> > ...................................
> > #
> > 73.80% nfsd [unknown] [k] 0x7ffff7fa
> > 7.57% nfsd [kernel.kallsyms] [k] csum_partial
> > 4.59% kworker/0:1 [unknown] [k] 0x7ffff832
> > 3.76% ksoftirqd/0 [unknown] [k] 0x7ffff96e
> > 0.94% kswapd0 [unknown] [k] 0x7ffffcc2
> > 0.92% swapper [unknown] [k] 0x7ffffa54
> > 0.62% nfsd [kernel.kallsyms] [k] __udp4_lib_lookup
> > 0.49% nfsd [kernel.kallsyms] [k] ip_append_page
> > 0.48% nfsd [kernel.kallsyms] [k] __do_softirq
> > 0.36% eventmon [unknown] [k] 0x7ffff9c4
> > 0.32% nfsd [kernel.kallsyms] [k] __getnstimeofday
> >
> >
> > Any ideas? Have I overlooked some necessary kernel config change?
> > Does perf need some binary that I may not have installed on this
> > embedded platform?
> >
> > Freescale mpc8379 (e300c4)
> > Gcc-4.7.2 uClibC built with ct-ng 1.18.0
> > binutils 2.22
> >
> > Thanks,
> > mh
> >
> > --
> > Martin Hicks P.Eng. | mort@bork.org
> > Bork Consulting Inc. | +1 (613) 266-2296
>
>
>
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-15 15:30 UTC (permalink / raw)
To: Mark Lord
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, H. Peter Anvin,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <52585FB3.7080508@start.ca>
On Fri, Oct 11, 2013 at 04:29:39PM -0400, Mark Lord wrote:
> > static int xx_alloc_msix_irqs(struct xx_dev *dev, int nvec)
> > {
> > nvec = roundup_pow_of_two(nvec); /* assume 0 > nvec <= 16 */
> >
> > xx_disable_all_irqs(dev);
> >
> > pci_lock_msi(dev->pdev);
> >
> > rc = pci_get_msix_limit(dev->pdev, nvec);
> > if (rc < 0)
> > goto err;
> >
> > nvec = min(nvec, rc); /* if limit is more than requested */
> > nvec = rounddown_pow_of_two(nvec); /* (a) */
> >
> > xx_prep_for_msix_vectors(dev, nvec);
> >
> > rc = pci_enable_msix(dev->pdev, dev->irqs, nvec); /* (b) */
> > if (rc < 0)
> > goto err;
> >
> > pci_unlock_msi(dev->pdev);
> >
> > dev->num_vectors = nvec; /* (b) */
> > return 0;
> >
> > err:
> > pci_unlock_msi(dev->pdev);
> >
> > kerr(dev->name, "pci_enable_msix() failed, err=%d", rc);
> > dev->num_vectors = 0;
> > return rc;
> > }
>
> That would still need a loop, to handle the natural race between
> the calls to pci_get_msix_limit() and pci_enable_msix() -- the driver and device
> can and should fall back to a smaller number of vectors when pci_enable_msix() fails.
Could you please explain why the value returned by pci_get_msix_limit()
might change before pci_enable_msix() returned, while both protected by
pci_lock_msi()?
Anyway, although the loop-free code (IMHO) reads better, pci_lock_msi()
it is not a part of the original proposal and the more I think about it
the less I like it.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* RE: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
From: Sethi Varun-B16395 @ 2013-10-15 14:35 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131015001611.GA9203@google.com>
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Bjorn Helgaas
> Sent: Tuesday, October 15, 2013 5:46 AM
> To: Sethi Varun-B16395
> Cc: Yoder Stuart-B08248; linux-kernel@vger.kernel.org; iommu@lists.linux-
> foundation.org; Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
>=20
> On Sun, Oct 13, 2013 at 02:02:32AM +0530, Varun Sethi wrote:
> > Factor out PCI specific code in the PAMU driver.
> >
> > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > ---
> > drivers/iommu/fsl_pamu_domain.c | 81 +++++++++++++++++++------------
> --------
> > 1 file changed, 40 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/iommu/fsl_pamu_domain.c
> > b/drivers/iommu/fsl_pamu_domain.c index c857c30..e02e1de 100644
> > --- a/drivers/iommu/fsl_pamu_domain.c
> > +++ b/drivers/iommu/fsl_pamu_domain.c
> > @@ -677,13 +677,9 @@ static int handle_attach_device(struct
> fsl_dma_domain *dma_domain,
> > return ret;
> > }
> >
> > -static int fsl_pamu_attach_device(struct iommu_domain *domain,
> > - struct device *dev)
> > +static void check_for_pci_dma_device(struct device **dev)
>=20
> "check_for_pci_dma_device()" doesn't give a good clue about what the
> function returns. And why return something via a reference parameter
> when you could return it directly?
[Sethi Varun-B16395] I will rename the function to get_dma_device and make =
it return a pointer.
>=20
> > {
> > - struct fsl_dma_domain *dma_domain =3D domain->priv;
> > - const u32 *liodn;
> > - u32 liodn_cnt;
> > - int len, ret =3D 0;
> > +#ifdef CONFIG_PCI
> > struct pci_dev *pdev =3D NULL;
> > struct pci_controller *pci_ctl;
>=20
> This is sort of a goofy looking function. It would read much better as
> something like this:
>=20
[Sethi Varun-B16395] Will make the change.
> struct device *dma_dev =3D dev;
>=20
> #ifdef CONFIG_PCI
> if (...) {
> dma_dev =3D ...;
> }
> #endif
>=20
> return dma_dev;
>=20
> Does this need to care about reference counting when you return a pointer
> to a different device?
>=20
[Sethi Varun-B16395] Reference counting isn't required, as we are just obta=
ining the LIODN value from the PCI controller.
-Varun
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Martin Hicks @ 2013-10-15 13:59 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3Xn4tHKvDK8tzLw09+zsEAJHEScV2DbZhH9KkYL-5iCmUA@mail.gmail.com>
I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:
commit 75382aa72f06823db7312ad069c3bae2eb3f8548
Author: Anton Blanchard <anton@samba.org>
Date: Tue Jun 26 01:01:36 2012 +0000
powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs
I don't know enough about PPC to know what's going on, but reverting
the changes to perf_instruction_pointer() gets me reasonable 'perf
report' output with 3.11.
Thanks,
mh
On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks <mort@bork.org> wrote:
> Hi,
>
> I've been trying to track down a performance regression that started
> leading up to the v3.6 kernel, and while doing this I've been
> gathering perf data on v3.6-rc and comparing it to v3.11 perf reports
> of the same workload.
>
> With v3.6-rc kernels I get all symbols resolved like this:
>
> # Events: 39K cpu-clock-msecs
> #
> # Overhead Command Shared Object
> Symbol
> # ........ ........... ......................
> ........................................
> #
> 9.69% nfsd [kernel.kallsyms] [k] csum_partial
> 5.64% nfsd [kernel.kallsyms] [k] __do_softirq
> 3.12% nfsd [sunrpc] [k] svc_create
> 2.38% nfsd [kernel.kallsyms] [k] __queue_work
> 1.91% nfsd [gianfar_driver] [k] gfar_poll
> 1.73% nfsd [kernel.kallsyms] [k] memset
> 1.54% nfsd [nfsd] [k] nfsd_vfs_read.isra.16
> 1.40% ksoftirqd/0 [kernel.kallsyms] [k] finish_task_switch.isra.54
> 1.30% nfsd [kernel.kallsyms] [k] get_page_from_freelist
> 1.21% nfsd [gianfar_driver] [k] gfar_start_xmit
> 1.20% nfsd [sunrpc] [k] svc_xprt_received
>
>
> But when I perf on v3.11 kernels I see a lot of unresolved symbols:
>
> # Events: 69K cpu-clock-msecs
> #
> # Overhead Command Shared Object
> Symbol
> # ........ ............ .....................
> ...................................
> #
> 73.80% nfsd [unknown] [k] 0x7ffff7fa
> 7.57% nfsd [kernel.kallsyms] [k] csum_partial
> 4.59% kworker/0:1 [unknown] [k] 0x7ffff832
> 3.76% ksoftirqd/0 [unknown] [k] 0x7ffff96e
> 0.94% kswapd0 [unknown] [k] 0x7ffffcc2
> 0.92% swapper [unknown] [k] 0x7ffffa54
> 0.62% nfsd [kernel.kallsyms] [k] __udp4_lib_lookup
> 0.49% nfsd [kernel.kallsyms] [k] ip_append_page
> 0.48% nfsd [kernel.kallsyms] [k] __do_softirq
> 0.36% eventmon [unknown] [k] 0x7ffff9c4
> 0.32% nfsd [kernel.kallsyms] [k] __getnstimeofday
>
>
> Any ideas? Have I overlooked some necessary kernel config change?
> Does perf need some binary that I may not have installed on this
> embedded platform?
>
> Freescale mpc8379 (e300c4)
> Gcc-4.7.2 uClibC built with ct-ng 1.18.0
> binutils 2.22
>
> Thanks,
> mh
>
> --
> Martin Hicks P.Eng. | mort@bork.org
> Bork Consulting Inc. | +1 (613) 266-2296
--
Martin Hicks P.Eng. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
^ permalink raw reply
* Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Mark Rutland @ 2013-10-15 13:38 UTC (permalink / raw)
To: Hongbo Zhang
Cc: devicetree@vger.kernel.org, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
djbw@fb.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52537A5F.7090802@freescale.com>
On Tue, Oct 08, 2013 at 04:22:07AM +0100, Hongbo Zhang wrote:
> Hi Mark, Stephen and other DT maintainers?
>
> The 1/3 had already been acked by Mark, and please have a further look
> at this patch 2/3.
> The DMA maintainer Vinod needs ack for the DT related patches so that
> he can take all this patch set.
Sorry for the delay.
This looks ok to me.
Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> On 09/26/2013 05:33 PM, hongbo.zhang@freescale.com wrote:
> > From: Hongbo Zhang <hongbo.zhang@freescale.com>
> >
> > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
> > the device tree nodes for them.
> >
> > Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> > ---
> > .../devicetree/bindings/powerpc/fsl/dma.txt | 70 +++++++++++++++++
> > arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
> > arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 ++++++++++++++++++++
> > arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 ++++++++++++++++++++
> > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
> > 5 files changed, 238 insertions(+), 4 deletions(-)
> > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > index 0584168..7fc1b01 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
> > @@ -128,6 +128,76 @@ Example:
> > };
> > };
> >
> > +** Freescale Elo3 DMA Controller
> > + DMA controller which has same function as EloPlus except that Elo3 has 8
> > + channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
> > + series chips, such as t1040, t4240, b4860.
> > +
> > +Required properties:
> > +
> > +- compatible : must include "fsl,elo3-dma"
> > +- reg : contains two entries for DMA General Status Registers,
> > + i.e. DGSR0 which includes status for channel 1~4, and
> > + DGSR1 for channel 5~8
> > +- ranges : describes the mapping between the address space of the
> > + DMA channels and the address space of the DMA controller
> > +
> > +- DMA channel nodes:
> > + - compatible : must include "fsl,eloplus-dma-channel"
> > + - reg : DMA channel specific registers
> > + - interrupts : interrupt specifier for DMA channel IRQ
> > + - interrupt-parent : optional, if needed for interrupt mapping
> > +
> > +Example:
> > +dma@100300 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,elo3-dma";
> > + reg = <0x100300 0x4>,
> > + <0x100600 0x4>;
> > + ranges = <0x0 0x100100 0x500>;
> > + dma-channel@0 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x0 0x80>;
> > + interrupts = <28 2 0 0>;
> > + };
> > + dma-channel@80 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x80 0x80>;
> > + interrupts = <29 2 0 0>;
> > + };
> > + dma-channel@100 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x100 0x80>;
> > + interrupts = <30 2 0 0>;
> > + };
> > + dma-channel@180 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x180 0x80>;
> > + interrupts = <31 2 0 0>;
> > + };
> > + dma-channel@300 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x300 0x80>;
> > + interrupts = <76 2 0 0>;
> > + };
> > + dma-channel@380 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x380 0x80>;
> > + interrupts = <77 2 0 0>;
> > + };
> > + dma-channel@400 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x400 0x80>;
> > + interrupts = <78 2 0 0>;
> > + };
> > + dma-channel@480 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x480 0x80>;
> > + interrupts = <79 2 0 0>;
> > + };
> > +};
> > +
> > Note on DMA channel compatible properties: The compatible property must say
> > "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
> > driver (fsldma). Any DMA channel used by fsldma cannot be used by another
> > diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > index 7399154..ea53ea1 100644
> > --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> > @@ -223,13 +223,13 @@
> > reg = <0xe2000 0x1000>;
> > };
> >
> > -/include/ "qoriq-dma-0.dtsi"
> > +/include/ "elo3-dma-0.dtsi"
> > dma@100300 {
> > fsl,iommu-parent = <&pamu0>;
> > fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
> > };
> >
> > -/include/ "qoriq-dma-1.dtsi"
> > +/include/ "elo3-dma-1.dtsi"
> > dma@101300 {
> > fsl,iommu-parent = <&pamu0>;
> > fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
> > diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> > new file mode 100644
> > index 0000000..3c210e0
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x100000 ]
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote products
> > + * derived from this software without specific prior written permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of the
> > + * GNU General Public License ("GPL") as published by the Free Software
> > + * Foundation, either version 2 of that License or (at your option) any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +dma0: dma@100300 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,elo3-dma";
> > + reg = <0x100300 0x4>,
> > + <0x100600 0x4>;
> > + ranges = <0x0 0x100100 0x500>;
> > + dma-channel@0 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x0 0x80>;
> > + interrupts = <28 2 0 0>;
> > + };
> > + dma-channel@80 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x80 0x80>;
> > + interrupts = <29 2 0 0>;
> > + };
> > + dma-channel@100 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x100 0x80>;
> > + interrupts = <30 2 0 0>;
> > + };
> > + dma-channel@180 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x180 0x80>;
> > + interrupts = <31 2 0 0>;
> > + };
> > + dma-channel@300 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x300 0x80>;
> > + interrupts = <76 2 0 0>;
> > + };
> > + dma-channel@380 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x380 0x80>;
> > + interrupts = <77 2 0 0>;
> > + };
> > + dma-channel@400 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x400 0x80>;
> > + interrupts = <78 2 0 0>;
> > + };
> > + dma-channel@480 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x480 0x80>;
> > + interrupts = <79 2 0 0>;
> > + };
> > +};
> > diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> > new file mode 100644
> > index 0000000..cccf3bb
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x101000 ]
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote products
> > + * derived from this software without specific prior written permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of the
> > + * GNU General Public License ("GPL") as published by the Free Software
> > + * Foundation, either version 2 of that License or (at your option) any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +dma1: dma@101300 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,elo3-dma";
> > + reg = <0x101300 0x4>,
> > + <0x101600 0x4>;
> > + ranges = <0x0 0x101100 0x500>;
> > + dma-channel@0 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x0 0x80>;
> > + interrupts = <32 2 0 0>;
> > + };
> > + dma-channel@80 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x80 0x80>;
> > + interrupts = <33 2 0 0>;
> > + };
> > + dma-channel@100 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x100 0x80>;
> > + interrupts = <34 2 0 0>;
> > + };
> > + dma-channel@180 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x180 0x80>;
> > + interrupts = <35 2 0 0>;
> > + };
> > + dma-channel@300 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x300 0x80>;
> > + interrupts = <80 2 0 0>;
> > + };
> > + dma-channel@380 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x380 0x80>;
> > + interrupts = <81 2 0 0>;
> > + };
> > + dma-channel@400 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x400 0x80>;
> > + interrupts = <82 2 0 0>;
> > + };
> > + dma-channel@480 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x480 0x80>;
> > + interrupts = <83 2 0 0>;
> > + };
> > +};
> > diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > index bd611a9..ec95c60 100644
> > --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > @@ -387,8 +387,8 @@
> > reg = <0xea000 0x4000>;
> > };
> >
> > -/include/ "qoriq-dma-0.dtsi"
> > -/include/ "qoriq-dma-1.dtsi"
> > +/include/ "elo3-dma-0.dtsi"
> > +/include/ "elo3-dma-1.dtsi"
> >
> > /include/ "qoriq-espi-0.dtsi"
> > spi@110000 {
>
>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
From: Gerhard Sittig @ 2013-10-15 13:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org list, Xie Xiaobo,
Linux Kernel list
In-Reply-To: <20131014200952.GA20517@kroah.com>
On Mon, Oct 14, 2013 at 13:09 -0700, Greg Kroah-Hartman wrote:
>
> On Mon, Oct 14, 2013 at 02:40:44PM -0500, Kumar Gala wrote:
> >
> > Greg,
> >
> > Wondering your thoughts on drivers/qe vs something like
> > drivers/soc/fsl/qe. The QuiccEngine (qe) is a communication core on
> > some of the Freescale networking SoCs that provides the ability to do
> > various networking/communication functionality. "Channels" on the QE
> > can be used for various different things from ethernet, ATM, UART, or
> > other functions.
>
> What makes the code "QE" specific? Are these devices that live on the
> QE "bus", or are they controlling the QE controller?
You may think of the QUICC as a "programmable bitbang machine" if
you like. The very same component runs arbitrary and rather
different protocols depending on how you setup its parameters.
There have been serial controllers capable of different protocols
like UART or SPI or I2S, but all of them are "serial
communication". There have been memory controllers which could
bitbang different protocols (NAND, NOR/SRAM, DRAM), but all of
them are "memory".
The QUICC is just a little more versatile, and appears to cover
cases which reside in different Linux kernel subsystems (like:
it's neither serial nor network exclusively, but can be either
and potentially more).
IIUC the question which Kumar Gala was asking is where to put
code for the component which is neither a strict subset of any
subsystem. Please correct me if I'm wrong.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Add a sys interface to enable/diable pw20 state or altivec idle, and
control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait "entry_bit" to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup("smt-snooze-delay=", setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT 63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns)
+{
+ u64 cycle;
+
+ if (ns >= 10000)
+ cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val)
+{
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ unsigned int cpu = dev->id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
+
+ value &= PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, "%u\n", value ? 1 : 0);
+}
+
+static void do_store_pw20_state(void *val)
+{
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state &= ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state);
+}
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 value;
+ unsigned int cpu = dev->id;
+
+ if (kstrtou32(buf, 0, &value))
+ return -EINVAL;
+
+ if (value > 1)
+ return -EINVAL;
+
+ smp_call_function_single(cpu, do_store_pw20_state, &value, 1);
+
+ return count;
+}
+
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev->id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
+ value = (value & PWRMGTCR0_PW20_ENT) >>
+ PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 << (MAX_BIT - value)) * 2;
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
+ } else {
+ time = pw20_wt;
+ }
+
+ return sprintf(buf, "%llu\n", time > 0 ? time : 0);
+}
+
+static void set_pw20_wait_entry_bit(void *val)
+{
+ u32 *value = val;
+ u32 pw20_idle;
+
+ pw20_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set Automatic PW20 Core Idle Count */
+ /* clear count */
+ pw20_idle &= ~PWRMGTCR0_PW20_ENT;
+
+ /* set count */
+ pw20_idle |= ((MAX_BIT - *value) << PWRMGTCR0_PW20_ENT_SHIFT);
+
+ mtspr(SPRN_PWRMGTCR0, pw20_idle);
+}
+
+static ssize_t store_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 entry_bit;
+ u64 value;
+
+ unsigned int cpu = dev->id;
+
+ if (kstrtou64(buf, 0, &value))
+ return -EINVAL;
+
+ if (!value)
+ return -EINVAL;
+
+ entry_bit = get_idle_ticks_bit(value);
+ if (entry_bit > MAX_BIT)
+ return -EINVAL;
+
+ pw20_wt = value;
+ smp_call_function_single(cpu, set_pw20_wait_entry_bit,
+ &entry_bit, 1);
+
+ return count;
+}
+
+static ssize_t show_altivec_idle(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ unsigned int cpu = dev->id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
+
+ value &= PWRMGTCR0_AV_IDLE_PD_EN;
+
+ return sprintf(buf, "%u\n", value ? 1 : 0);
+}
+
+static void do_store_altivec_idle(void *val)
+{
+ u32 *value = val;
+ u32 altivec_idle;
+
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ altivec_idle |= PWRMGTCR0_AV_IDLE_PD_EN;
+ else
+ altivec_idle &= ~PWRMGTCR0_AV_IDLE_PD_EN;
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
+
+static ssize_t store_altivec_idle(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 value;
+ unsigned int cpu = dev->id;
+
+ if (kstrtou32(buf, 0, &value))
+ return -EINVAL;
+
+ if (value > 1)
+ return -EINVAL;
+
+ smp_call_function_single(cpu, do_store_altivec_idle, &value, 1);
+
+ return count;
+}
+
+static ssize_t show_altivec_idle_wait_time(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev->id;
+
+ if (!altivec_idle_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
+ value = (value & PWRMGTCR0_AV_IDLE_CNT) >>
+ PWRMGTCR0_AV_IDLE_CNT_SHIFT;
+
+ tb_cycle = (1 << (MAX_BIT - value)) * 2;
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
+ } else {
+ time = altivec_idle_wt;
+ }
+
+ return sprintf(buf, "%llu\n", time > 0 ? time : 0);
+}
+
+static void set_altivec_idle_wait_entry_bit(void *val)
+{
+ u32 *value = val;
+ u32 altivec_idle;
+
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set Automatic AltiVec Idle Count */
+ /* clear count */
+ altivec_idle &= ~PWRMGTCR0_AV_IDLE_CNT;
+
+ /* set count */
+ altivec_idle |= ((MAX_BIT - *value) << PWRMGTCR0_AV_IDLE_CNT_SHIFT);
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
+
+static ssize_t store_altivec_idle_wait_time(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 entry_bit;
+ u64 value;
+
+ unsigned int cpu = dev->id;
+
+ if (kstrtou64(buf, 0, &value))
+ return -EINVAL;
+
+ if (!value)
+ return -EINVAL;
+
+ entry_bit = get_idle_ticks_bit(value);
+ if (entry_bit > MAX_BIT)
+ return -EINVAL;
+
+ altivec_idle_wt = value;
+ smp_call_function_single(cpu, set_altivec_idle_wait_entry_bit,
+ &entry_bit, 1);
+
+ return count;
+}
+
+/*
+ * Enable/Disable interface:
+ * 0, disable. 1, enable.
+ */
+static DEVICE_ATTR(pw20_state, 0600, show_pw20_state, store_pw20_state);
+static DEVICE_ATTR(altivec_idle, 0600, show_altivec_idle, store_altivec_idle);
+
+/*
+ * Set wait time interface:(Nanosecond)
+ * Example: Base on TBfreq is 41MHZ.
+ * 1~48(ns): TB[63]
+ * 49~97(ns): TB[62]
+ * 98~195(ns): TB[61]
+ * 196~390(ns): TB[60]
+ * 391~780(ns): TB[59]
+ * 781~1560(ns): TB[58]
+ * ...
+ */
+static DEVICE_ATTR(pw20_wait_time, 0600,
+ show_pw20_wait_time,
+ store_pw20_wait_time);
+static DEVICE_ATTR(altivec_idle_wait_time, 0600,
+ show_altivec_idle_wait_time,
+ store_altivec_idle_wait_time);
+#endif
+
/*
* Enabling PMCs will slow partition context switch times so we only do
* it the first time we write to the PMCs.
@@ -407,6 +685,15 @@ static void register_cpu_online(unsigned int cpu)
device_create_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+ if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
+ device_create_file(s, &dev_attr_pw20_state);
+ device_create_file(s, &dev_attr_pw20_wait_time);
+
+ device_create_file(s, &dev_attr_altivec_idle);
+ device_create_file(s, &dev_attr_altivec_idle_wait_time);
+ }
+#endif
cacheinfo_cpu_online(cpu);
}
@@ -479,6 +766,15 @@ static void unregister_cpu_online(unsigned int cpu)
device_remove_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+ if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
+ device_remove_file(s, &dev_attr_pw20_state);
+ device_remove_file(s, &dev_attr_pw20_wait_time);
+
+ device_remove_file(s, &dev_attr_altivec_idle);
+ device_remove_file(s, &dev_attr_altivec_idle_wait_time);
+ }
+#endif
cacheinfo_cpu_offline(cpu);
}
--
1.8.0
^ permalink raw reply related
* [PATCH v5 3/4] powerpc/85xx: add hardware automatically enter pw20 state
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Using hardware features make core automatically enter PW20 state.
Set a TB count to hardware, the effective count begins when PW10
is entered. When the effective period has expired, the core will
proceed from PW10 to PW20 if no exit conditions have occurred during
the period.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
*v3:
Assembly code instead of C code.
*v2:
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 4789056..49e738e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -55,6 +55,25 @@ _GLOBAL(__e500_dcache_setup)
/*
* FIXME - we haven't yet done testing to determine a reasonable default
+ * value for PW20_WAIT_IDLE_BIT.
+ */
+#define PW20_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */
+_GLOBAL(setup_pw20_idle)
+ mfspr r3, SPRN_PWRMGTCR0
+
+ /* Set PW20_WAIT bit, enable pw20 state*/
+ ori r3, r3, PWRMGTCR0_PW20_WAIT
+ li r11, PW20_WAIT_IDLE_BIT
+
+ /* Set Automatic PW20 Core Idle Count */
+ rlwimi r3, r11, PWRMGTCR0_PW20_ENT_SHIFT, PWRMGTCR0_PW20_ENT
+
+ mtspr SPRN_PWRMGTCR0, r3
+
+ blr
+
+/*
+ * FIXME - we haven't yet done testing to determine a reasonable default
* value for AV_WAIT_IDLE_BIT.
*/
#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */
@@ -77,6 +96,7 @@ _GLOBAL(__setup_cpu_e6500)
#ifdef CONFIG_PPC64
bl .setup_altivec_ivors
#endif
+ bl setup_pw20_idle
bl setup_altivec_idle
bl __setup_cpu_e5500
mtlr r6
@@ -139,6 +159,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
+ bl .setup_pw20_idle
bl .setup_altivec_idle
bl __restore_cpu_e5500
mtlr r5
--
1.8.0
^ permalink raw reply related
* [PATCH v5 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
Each core's AltiVec unit may be placed into a power savings mode
by turning off power to the unit. Core hardware will automatically
power down the AltiVec unit after no AltiVec instructions have
executed in N cycles. The AltiVec power-control is triggered by hardware.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
*v3:
Assembly code instead of C code.
*v2:
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.
Move:
move setup_* into __setup/restore_cpu_e6500.
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index bfb18c7..4789056 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -53,11 +53,31 @@ _GLOBAL(__e500_dcache_setup)
isync
blr
+/*
+ * FIXME - we haven't yet done testing to determine a reasonable default
+ * value for AV_WAIT_IDLE_BIT.
+ */
+#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */
+_GLOBAL(setup_altivec_idle)
+ mfspr r3, SPRN_PWRMGTCR0
+
+ /* Enable Altivec Idle */
+ oris r3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h
+ li r11, AV_WAIT_IDLE_BIT
+
+ /* Set Automatic AltiVec Idle Count */
+ rlwimi r3, r11, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT
+
+ mtspr SPRN_PWRMGTCR0, r3
+
+ blr
+
_GLOBAL(__setup_cpu_e6500)
mflr r6
#ifdef CONFIG_PPC64
bl .setup_altivec_ivors
#endif
+ bl setup_altivec_idle
bl __setup_cpu_e5500
mtlr r6
blr
@@ -119,6 +139,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
+ bl .setup_altivec_idle
bl __restore_cpu_e5500
mtlr r5
blr
--
1.8.0
^ permalink raw reply related
* [PATCH v5 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
From: Wang Dongsheng <dongsheng.wang@freescale.com>
E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
idle patches.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
*v3:
Add bit definitions for PWRMGTCR0.
arch/powerpc/include/asm/reg.h | 2 ++
arch/powerpc/include/asm/reg_booke.h | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 64264bf..d4160ca 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1053,6 +1053,8 @@
#define PVR_8560 0x80200000
#define PVR_VER_E500V1 0x8020
#define PVR_VER_E500V2 0x8021
+#define PVR_VER_E6500 0x8040
+
/*
* For the 8xx processors, all of them report the same PVR family for
* the PowerPC core. The various versions of these processors must be
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index ed8f836..4a6457e 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -170,6 +170,7 @@
#define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1 */
#define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */
#define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */
+#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */
#define SPRN_SVR 0x3FF /* System Version Register */
/*
@@ -216,6 +217,14 @@
#define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity checking */
#define CCR1_TCS 0x00000080 /* Timer Clock Select */
+/* Bit definitions for PWRMGTCR0. */
+#define PWRMGTCR0_PW20_WAIT (1 << 14) /* PW20 state enable bit */
+#define PWRMGTCR0_PW20_ENT_SHIFT 8
+#define PWRMGTCR0_PW20_ENT 0x3F00
+#define PWRMGTCR0_AV_IDLE_PD_EN (1 << 22) /* Altivec idle enable */
+#define PWRMGTCR0_AV_IDLE_CNT_SHIFT 16
+#define PWRMGTCR0_AV_IDLE_CNT 0x3F0000
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
--
1.8.0
^ permalink raw reply related
* Re: [PATCH -V2 00/14] Allow PR and HV KVM to coexist in one kernel
From: Aneesh Kumar K.V @ 2013-10-15 9:00 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1381164482-31001-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Hi Alex,
Any update on this ?
-aneesh
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> Hi All,
>
> This patch series support enabling HV and PR KVM together in the same kernel. We
> extend machine property with new property "kvm_type". A value of "HV" will force HV
> KVM and "PR" PR KVM. If we don't specify kvm_type we will select the fastest KVM mode.
> ie, HV if that is supported otherwise PR.
>
> With Qemu command line having
>
> -machine pseries,accel=kvm,kvm_type=HV
>
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]# modprobe kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]# modprobe kvm-hv
> [root@llmp24l02 qemu]# bash ../qemu
>
> now with
>
> -machine pseries,accel=kvm,kvm_type=PR
>
> [root@llmp24l02 qemu]# rmmod kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]#
> [root@llmp24l02 qemu]# modprobe kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
>
> Changes from V1:
> * Build fixes for BOOKE (only compile tested)
> * Address review feedback
>
> -aneesh
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Build regressions/improvements in v3.12-rc5
From: Geert Uytterhoeven @ 2013-10-15 6:37 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <1381818878-19469-1-git-send-email-geert@linux-m68k.org>
On Tue, Oct 15, 2013 at 8:34 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.12-rc5 to v3.12-rc4[3], the summaries are:
> - build errors: +13/-6
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'KEXEC_CORE_NOTE_NAME' undeclared (first use in this function): =>
521:36
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'crashing_cpu' undeclared (first use in this function): => 408:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'note_buf_t' undeclared (first use in this function): => 624:49
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'vmcoreinfo_max_size' undeclared (first use in this function): =>
874:18
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'crash_save_vmcoreinfo'
[-Werror=implicit-function-declaration]: => 410:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'elf_core_copy_kernel_regs'
[-Werror=implicit-function-declaration]: => 520:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'paddr_vmcoreinfo_note'
[-Werror=implicit-function-declaration]: => 872:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: storage
size of 'prstatus' isn't known: => 513:22
powerpc-randconfig
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'DMTE6_IRQ' undeclared (first use in this function): => 58:21
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error:
implicit declaration of function 'dma_alloc_writecombine'
[-Werror=implicit-function-declaration]: => 91:2
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error:
implicit declaration of function 'dma_free_writecombine'
[-Werror=implicit-function-declaration]: => 176:3
sh-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6776/ (all 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6753/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] powerpc: Use 32 bit loads and stores when operating on condition register values
From: Anton Blanchard @ 2013-10-15 3:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: mikey, linuxppc-dev, amodra
In-Reply-To: <20131015034206.GB17233@drongo>
Hi Paul,
> Does this make any practical difference or fix any bugs, or is this
> just for aesthetics?
There is talk of the other 32 bits of that word being used for a
stack canary in a future ABI revision. So right now it is just
cosmetic, but it could be important in the future.
I guess it could be an issue for kgdb since the CR will be in
the wrong spot on BE.
Anton
^ 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