* USB host on 83xx
From: Gary Thomas @ 2010-01-27 20:20 UTC (permalink / raw)
To: linuxppc-dev
I have two nearly identical boards, with very different behavior.
Older 8347 (PVR: 0x80830011)
New 8347 (PVR: 0x80830031)
I've tried a number of kernels (vintages) on both with wild results.
2.6.20 - Same kernel works on both(*)
2.6.28 - Kernel runs great on OLD, machine check on NEW
2.6.32.6 - Ditto
The problem occurs (only on the new silicon) during the USB host
initialization. The root hub is found and initialized, then the
EHCI subsystem is reset (to force it to find siblings on the bus).
This results in a machine check at the point where the PHY is
being reinitialized.
I've peppered the driver with messages - here's what I see:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
********** ehci_fsl_setup.272
********** ehci_fsl_setup.296
********** ehci_fsl_setup.299
********** ehci_fsl_reinit.257
********** mpc83xx_usb_setup.192
********** mpc83xx_usb_setup.207
********** mpc83xx_usb_setup.215
********** mpc83xx_usb_setup.220
********** mpc83xx_setup_phy.163
********** mpc83xx_setup_phy.180
********** mpc83xx_setup_phy.182
********** mpc83xx_usb_setup.238
********** mpc83xx_usb_setup.245
********** mpc83xx_usb_setup.249
********** mpc83xx_usb_setup.251
********** ehci_fsl_reinit.259
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
********** ehci_fsl_reinit.261
********** ehci_fsl_setup.301
fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
********** ehci_hub_control.559 - req: 40966
********** ehci_hub_control.637
hub 1-0:1.0: 2 ports detected
********** ehci_hub_control.559 - req: 40960
********** ehci_hub_control.642
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
********** ehci_fsl_setup.272
********** ehci_fsl_setup.296
********** ehci_fsl_setup.299
********** ehci_fsl_reinit.257
********** mpc83xx_usb_setup.192
********** mpc83xx_usb_setup.207
********** mpc83xx_usb_setup.215
********** mpc83xx_setup_phy.163
********** mpc83xx_setup_phy.180
MACHINE CHECK - so dead it can't even print the message!
At this point, it should carry on like this:
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
********** ehci_hub_control.559 - req: 41728
********** ehci_hub_control.648
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
********** ehci_hub_control.559 - req: 41728
********** ehci_hub_control.648
You can see that it successfully found the connected external HUB.
Any ideas why this happens? This [basic] code used to work (2.6.20)
on both platforms. I know that's a long time ago, but MACHINE CHECK??
(*) To get this platform to run 2.6.20, I had to patch the CPU tables
to recognize it as 8347 (kernels of that vintage relied on the SVR to
make choices, not PVR)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [RFC PATCH] PCI-E broken on PPC (regression)
From: Benjamin Herrenschmidt @ 2010-01-27 22:00 UTC (permalink / raw)
To: Jesse Barnes
Cc: Linux PCI, Jay Vosburgh, David Miller, Ron Mercer,
kaneshige.kenji, linuxppc-dev, Breno Leitao
In-Reply-To: <20100127082624.4a91323a@jbarnes-piketon>
On Wed, 2010-01-27 at 08:26 -0800, Jesse Barnes wrote:
>
> Thanks Ben. Any refactoring we need to handle this stuff better is
> fine with me too. I guess on some platforms calling pci_setup_device
> may cause problems with special platform devices?
Well, we don't call pci_setup_device() because part of the deal is to
avoid all of that config space reading that it does :-) Especially in
the case of some of the IBM EADS bridges which don't let you access
everything we may want.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Dynamically allocate pacas
From: Michael Ellerman @ 2010-01-27 22:47 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <4389.1264575576@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Wed, 2010-01-27 at 17:29 +1030, Michael Neuling wrote:
> > On 64-bit kernels we currently have a 512 byte struct paca_struct for
> > each cpu (usually just called "the paca"). Currently they are statically
> > allocated, which means a kernel built for a large number of cpus will
> > waste a lot of space if it's booted on a machine with few cpus.
> >
> > We can avoid that by only allocating the number of pacas we need at
> > boot. However this is complicated by the fact that we need to access
> > the paca before we know how many cpus there are in the system.
> >
> > The solution is to dynamically allocate enough space for NR_CPUS pacas,
> > but then later in boot when we know how many cpus we have, we free any
> > unused pacas.
> >
> > Lightly booted on Legacy iSeries & pSeries LPAR.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> <snip>
>
> > --- a/arch/powerpc/kernel/setup-common.c
> > +++ b/arch/powerpc/kernel/setup-common.c
> > @@ -493,6 +493,8 @@ void __init smp_setup_cpu_maps(void)
> > * here will have to be reworked
> > */
> > cpu_init_thread_core_maps(nthreads);
> > +
> > + free_unused_pacas();
>
> This is still barfing for me on 32bit.
Darn, what config? I built at least one :)
> Putting an #include <asm/paca.h> at the top of setup-common.c fixes it.
Gah, I saw it was coming via somewhere else but decided not to add it,
wrong decision :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Dynamically allocate pacas
From: Michael Neuling @ 2010-01-27 23:27 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1264632445.6352.6.camel@concordia>
> > > On 64-bit kernels we currently have a 512 byte struct paca_struct for
> > > each cpu (usually just called "the paca"). Currently they are staticall=
> y
> > > allocated, which means a kernel built for a large number of cpus will
> > > waste a lot of space if it's booted on a machine with few cpus.
> > >=20
> > > We can avoid that by only allocating the number of pacas we need at
> > > boot. However this is complicated by the fact that we need to access
> > > the paca before we know how many cpus there are in the system.
> > >=20
> > > The solution is to dynamically allocate enough space for NR_CPUS pacas,
> > > but then later in boot when we know how many cpus we have, we free any
> > > unused pacas.
> > >=20
> > > Lightly booted on Legacy iSeries & pSeries LPAR.
> > >=20
> > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> >=20
> > <snip>
> >=20
> > > --- a/arch/powerpc/kernel/setup-common.c
> > > +++ b/arch/powerpc/kernel/setup-common.c
> > > @@ -493,6 +493,8 @@ void __init smp_setup_cpu_maps(void)
> > > * here will have to be reworked
> > > */
> > > cpu_init_thread_core_maps(nthreads);
> > > +
> > > + free_unused_pacas();
> >=20
> > This is still barfing for me on 32bit.
>
> Darn, what config? I built at least one :)
I think I used mpc86xx_defconfig.
> > Putting an #include <asm/paca.h> at the top of setup-common.c fixes it.
>
> Gah, I saw it was coming via somewhere else but decided not to add it,
> wrong decision :)
IMHO, if it's used we should put it in. Otherwise some other random
include file will remove it and break us.
Mikey
^ permalink raw reply
* Re: [RFC PATCH] PCI-E broken on PPC (regression)
From: David Miller @ 2010-01-28 0:01 UTC (permalink / raw)
To: benh
Cc: linux-pci, fubar, jbarnes, ron.mercer, kaneshige.kenji,
linuxppc-dev, leitao
In-Reply-To: <1264629612.3601.176.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 28 Jan 2010 09:00:12 +1100
> On Wed, 2010-01-27 at 08:26 -0800, Jesse Barnes wrote:
>>
>> Thanks Ben. Any refactoring we need to handle this stuff better is
>> fine with me too. I guess on some platforms calling pci_setup_device
>> may cause problems with special platform devices?
>
> Well, we don't call pci_setup_device() because part of the deal is to
> avoid all of that config space reading that it does :-) Especially in
> the case of some of the IBM EADS bridges which don't let you access
> everything we may want.
Same problem on sparc64, it's not safe to poke config space
arbitrarily. Some PCI controllers even have bugs which cause them to
hang if you try to access some parts of the host controller's PCI
config space.
^ permalink raw reply
* Re: USB host on 83xx
From: Gary Thomas @ 2010-01-28 0:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4B60A014.50304@mlbassoc.com>
On 01/27/2010 01:20 PM, Gary Thomas wrote:
> I have two nearly identical boards, with very different behavior.
>
> Older 8347 (PVR: 0x80830011)
> New 8347 (PVR: 0x80830031)
I lied (more precisely I was lied to and I passed it on - I've never
seen these boards in person, just worked on them from thousands of
miles away).
The boards have more than a rev difference:
OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011)
NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031)
Could this have any bearing on the problems?
> I've tried a number of kernels (vintages) on both with wild results.
>
> 2.6.20 - Same kernel works on both(*)
> 2.6.28 - Kernel runs great on OLD, machine check on NEW
> 2.6.32.6 - Ditto
>
> The problem occurs (only on the new silicon) during the USB host
> initialization. The root hub is found and initialized, then the
> EHCI subsystem is reset (to force it to find siblings on the bus).
> This results in a machine check at the point where the PHY is
> being reinitialized.
>
> I've peppered the driver with messages - here's what I see:
>
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> ********** ehci_fsl_setup.272
> ********** ehci_fsl_setup.296
> ********** ehci_fsl_setup.299
> ********** ehci_fsl_reinit.257
> ********** mpc83xx_usb_setup.192
> ********** mpc83xx_usb_setup.207
> ********** mpc83xx_usb_setup.215
> ********** mpc83xx_usb_setup.220
> ********** mpc83xx_setup_phy.163
> ********** mpc83xx_setup_phy.180
> ********** mpc83xx_setup_phy.182
> ********** mpc83xx_usb_setup.238
> ********** mpc83xx_usb_setup.245
> ********** mpc83xx_usb_setup.249
> ********** mpc83xx_usb_setup.251
> ********** ehci_fsl_reinit.259
> ********** ehci_hub_control.559 - req: 8961
> ********** ehci_hub_control.574
> ********** ehci_hub_control.559 - req: 8961
> ********** ehci_hub_control.574
> ********** ehci_fsl_reinit.261
> ********** ehci_fsl_setup.301
> fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> ********** ehci_hub_control.559 - req: 40966
> ********** ehci_hub_control.637
> hub 1-0:1.0: 2 ports detected
> ********** ehci_hub_control.559 - req: 40960
> ********** ehci_hub_control.642
> ********** ehci_hub_control.559 - req: 8963
> ********** ehci_hub_control.805
> ********** ehci_hub_control.559 - req: 8963
> ********** ehci_hub_control.805
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: Freescale On-Chip EHCI Host Controller
> usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
> usb usb1: SerialNumber: fsl-ehci.0
> fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
> ********** ehci_fsl_setup.272
> ********** ehci_fsl_setup.296
> ********** ehci_fsl_setup.299
> ********** ehci_fsl_reinit.257
> ********** mpc83xx_usb_setup.192
> ********** mpc83xx_usb_setup.207
> ********** mpc83xx_usb_setup.215
> ********** mpc83xx_setup_phy.163
> ********** mpc83xx_setup_phy.180
> MACHINE CHECK - so dead it can't even print the message!
>
> At this point, it should carry on like this:
>
> ********** ehci_hub_control.559 - req: 8963
> ********** ehci_hub_control.805
> ********** ehci_hub_control.559 - req: 41728
> ********** ehci_hub_control.648
> ********** ehci_hub_control.559 - req: 8961
> ********** ehci_hub_control.574
> usb 1-1: configuration #1 chosen from 1 choice
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
> usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> usb 1-1: Product: USB2.0 Hub
> ********** ehci_hub_control.559 - req: 41728
> ********** ehci_hub_control.648
>
> You can see that it successfully found the connected external HUB.
>
> Any ideas why this happens? This [basic] code used to work (2.6.20)
> on both platforms. I know that's a long time ago, but MACHINE CHECK??
>
> (*) To get this platform to run 2.6.20, I had to patch the CPU tables
> to recognize it as 8347 (kernels of that vintage relied on the SVR to
> make choices, not PVR)
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] powerpc: Dynamically allocate pacas
From: Stephen Rothwell @ 2010-01-28 0:08 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <8748.1264634853@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Thu, 28 Jan 2010 09:57:33 +1030 Michael Neuling <mikey@neuling.org> wrote:
>
> > > Putting an #include <asm/paca.h> at the top of setup-common.c fixes it.
> >
> > Gah, I saw it was coming via somewhere else but decided not to add it,
> > wrong decision :)
Always the wrong decision, Mr Ellerman :-)
> IMHO, if it's used we should put it in. Otherwise some other random
> include file will remove it and break us.
I see this a lot in linux-next builds ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] PCI-E broken on PPC (regression)
From: Jesse Barnes @ 2010-01-28 0:03 UTC (permalink / raw)
To: David Miller
Cc: fubar, linux-pci, ron.mercer, kaneshige.kenji, linuxppc-dev,
leitao
In-Reply-To: <20100127.160121.71577531.davem@davemloft.net>
On Wed, 27 Jan 2010 16:01:21 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Thu, 28 Jan 2010 09:00:12 +1100
>
> > On Wed, 2010-01-27 at 08:26 -0800, Jesse Barnes wrote:
> >>
> >> Thanks Ben. Any refactoring we need to handle this stuff better is
> >> fine with me too. I guess on some platforms calling pci_setup_device
> >> may cause problems with special platform devices?
> >
> > Well, we don't call pci_setup_device() because part of the deal is to
> > avoid all of that config space reading that it does :-) Especially in
> > the case of some of the IBM EADS bridges which don't let you access
> > everything we may want.
>
> Same problem on sparc64, it's not safe to poke config space
> arbitrarily. Some PCI controllers even have bugs which cause them to
> hang if you try to access some parts of the host controller's PCI
> config space.
Ok, that's what I thought. We'll need to make these functions
available then...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Andrew Morton @ 2010-01-28 1:05 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, David Woodhouse
In-Reply-To: <OF0311C7C7.F02F52A9-ONC12576B6.002D4A11-C12576B6.002DC689@transmode.se>
On Mon, 25 Jan 2010 09:19:59 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
> new optimized inflate only available on arch's that
> define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
> fixes it by defining our own endian independent versions
> of unaligned access.
(I hope I picked up the right version of
whatever-it-was-i-was-supposed-to-pick-up - I wasn't paying attention).
The changelog sucks. You say the patch fixes "it", but what is "it"?
Is "it" a build error? If so, what? Or is "it" a
make-optimized-inflate-available-on-ppc patch, in which case it's a
"feature"?
Confuzzzzzed.
^ permalink raw reply
* UIO / of_genirq driver
From: John Williams @ 2010-01-28 7:13 UTC (permalink / raw)
To: Linux Kernel list; +Cc: gregkh, devicetree-discuss, hjk, linuxppc-dev
Hi,
I came across this thread/patchset from around June last year:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073086.html
where Wolfgang proposed a generic OF-driven UIO driver. The
discussion seemed to stall after Grant Likely indicated he didn't like
the use of a linux-specific compatible binding in the device tree
(compatible="generic-uio").
I guess I have a couple of questions:
* did this patchset go anywhere? I've been using it here the last
few days and it works great.
and more generally:
* Is there a better way to handle the OF bindings for this sort of thing?
Grant's complaint seems to come up often - when you have generic
controllers in a system (SPI/I2C also spring to mind), we need a way
of signalling somehow to the kernel that each instance has a
particular usage intended.
However, the device-tree guys complain whenever anyone tries to encode
anything non-hardware related into the DTS itself.
I guess I'd like to just open up a discussion, see if there's been any
progress towards a general solution.
Thanks,
John
--
John Williams
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: K.Prasad @ 2010-01-28 7:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frederic Weisbecker, linuxppc-dev, shaggy, David Gibson
In-Reply-To: <1264365121.3601.43.camel@pasglop>
On Mon, Jan 25, 2010 at 07:32:00AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote:
> >
> > Some of the benefits of using these generic interfaces include:
> > - Interoperability with other users of debug register (such as
> > parallel
> > kernel requests) i.e. non-exclusive use of debug registers.
> > - Enables debugging/tracing tools such as perf-events and ftrace to
> > make
> > use of debug registers.
> > - Re-use of common code available in kernel (kernel/hw_breakpoint.c).
> >
> > Let me know what you think.
>
> This might have changed but last I looked the "generic" breakpoint
> interface was still too x86-centric and wasn't capable of expressing
> some of the features of the BookE debug register set such as the data
> value compare, the ranged breakpoints, etc...
>
> I'd rather have this more dedicated and more complete interface merged
> for gdb's sake, and in a second step look at unifying.
>
While the hw-breakpoint infrastructure is more generic (than
what can be termed x86-centric), it cannot support sophisticated
features like DVC register - atleast in its present form.
My idea was to align the Book-E processor's use of debug registers with
the existing breakpoint framework, and in the process make improvements/
changes to the common framework as necessitated.
It could be done in a two-step process to ease the development and review
process (more on this below).
> I believe that the generic breakpoint infrastructure should not be the
> mid-layer. IE. It cannot be made in any clean shape of form, to express
> all of the subtle features that a given architecture or platform can
> support and as such would always be inferior to a dedicated one.
>
> I can see the interest in exposing some kind of generic API that
> implements a common subset of breakpoint or watchpoint facilities to
> generic code such as the event tracer. This could be layered on top of
> an arch specific mechanism
>
Given the diversity of debug register implementation (across
processors), concerns about having a poorly-featured mid-layer is
understandable.
But our design goal is to be as flexible as required to accomodate newer
architectures, while providing them the benefit of using the common
framework - such as register arbitration (existing implementation would
assume mutually exclusive access to debug registers), scheduling and
abstraction through generic interfaces.
> But having the generic mechanism at the core for everybody is another
> attempt of "make everybody look like x86" which I believe in this case
> is sub optimal.
>
No, it is not! In fact patches that port the framework to PPC64 and S390
have already been posted to the respective communities and are under
review.
> Again, I might have missed some evolutions of the latest versions of
> your infrastructure that would make it good enough to fully bridge the
> gap with our requirements, and I'll let Shaggy decide here what he wants
> to do. But I will not block his current patches neither if he thinks
> that they are good enough as is.
>
As I mentioned above, the generic framework may need to be extended to
support all features required by processors such as Book-E. Any
feature that is very unique to a given processor and exotic to the
hw-breakpoint framework can be kept outside its purview (and implemented
to support only ptrace with exclusive access to those registers).
Sure, let's wait to hear from Shaggy to know how he'd like to proceed.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-28 8:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, David Woodhouse
In-Reply-To: <20100127170536.23634cdf.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote on 2010/01/28 02:05:36:
>
> On Mon, 25 Jan 2010 09:19:59 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
> > new optimized inflate only available on arch's that
> > define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
> > fixes it by defining our own endian independent versions
> > of unaligned access.
>
> (I hope I picked up the right version of
> whatever-it-was-i-was-supposed-to-pick-up - I wasn't paying attention).
It was the right one.
>
> The changelog sucks. You say the patch fixes "it", but what is "it"?
> Is "it" a build error? If so, what? Or is "it" a
> make-optimized-inflate-available-on-ppc patch, in which case it's a
> "feature"?
Here is a new version with a somewhat better commit msg and
checkpatch fixes.
Jocke
BTW, I get duplicate mails from your patch handling tools,
one to Joakim.Tjernlund@transmode.se and one to joakim.tjernlund@transmode.se
>From 612bfb4cc6cc55243c2a4f536ae2ae71065b57b0 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Sun, 24 Jan 2010 11:12:56 +0100
Subject: [PATCH] zlib: Make new optimized inflate endian independent
Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
new optimized inflate only available on arch's that
define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
will again enable the optimization for all arch's by
by defining our own endian independent version
of unaligned access. As an added bonus, arch's that
define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a
plain load instead.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
v2:
- fix checkpatch complaints.
- Improve commit msg.
lib/zlib_inflate/inffast.c | 70 +++++++++++++++++++-------------------------
1 files changed, 30 insertions(+), 40 deletions(-)
diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 215447c..fa62fc7 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -8,21 +8,6 @@
#include "inflate.h"
#include "inffast.h"
-/* Only do the unaligned "Faster" variant when
- * CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set
- *
- * On powerpc, it won't be as we don't include autoconf.h
- * automatically for the boot wrapper, which is intended as
- * we run in an environment where we may not be able to deal
- * with (even rare) alignment faults. In addition, we do not
- * define __KERNEL__ for arch/powerpc/boot unlike x86
- */
-
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-#include <asm/unaligned.h>
-#include <asm/byteorder.h>
-#endif
-
#ifndef ASMINF
/* Allow machine dependent optimization for post-increment or pre-increment.
@@ -36,14 +21,31 @@
- Pentium III (Anderson)
- M68060 (Nikl)
*/
+union uu {
+ unsigned short us;
+ unsigned char b[2];
+};
+
+/* Endian independed version */
+static inline unsigned short
+get_unaligned16(const unsigned short *p)
+{
+ union uu mm;
+ unsigned char *b = (unsigned char *)p;
+
+ mm.b[0] = b[0];
+ mm.b[1] = b[1];
+ return mm.us;
+}
+
#ifdef POSTINC
# define OFF 0
# define PUP(a) *(a)++
-# define UP_UNALIGNED(a) get_unaligned((a)++)
+# define UP_UNALIGNED(a) get_unaligned16((a)++)
#else
# define OFF 1
# define PUP(a) *++(a)
-# define UP_UNALIGNED(a) get_unaligned(++(a))
+# define UP_UNALIGNED(a) get_unaligned16(++(a))
#endif
/*
@@ -256,7 +258,6 @@ void inflate_fast(z_streamp strm, unsigned start)
}
}
else {
-#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
unsigned short *sout;
unsigned long loops;
@@ -274,7 +275,11 @@ void inflate_fast(z_streamp strm, unsigned start)
sfrom = (unsigned short *)(from - OFF);
loops = len >> 1;
do
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+ PUP(sout) = PUP(sfrom);
+#else
PUP(sout) = UP_UNALIGNED(sfrom);
+#endif
while (--loops);
out = (unsigned char *)sout + OFF;
from = (unsigned char *)sfrom + OFF;
@@ -282,14 +287,13 @@ void inflate_fast(z_streamp strm, unsigned start)
unsigned short pat16;
pat16 = *(sout-2+2*OFF);
- if (dist == 1)
-#if defined(__BIG_ENDIAN)
- pat16 = (pat16 & 0xff) | ((pat16 & 0xff) << 8);
-#elif defined(__LITTLE_ENDIAN)
- pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00) >> 8);
-#else
-#error __BIG_ENDIAN nor __LITTLE_ENDIAN is defined
-#endif
+ if (dist == 1) {
+ union uu mm;
+ /* copy one char pattern to both bytes */
+ mm.us = pat16;
+ mm.b[0] = mm.b[1];
+ pat16 = mm.us;
+ }
loops = len >> 1;
do
PUP(sout) = pat16;
@@ -298,20 +302,6 @@ void inflate_fast(z_streamp strm, unsigned start)
}
if (len & 1)
PUP(out) = PUP(from);
-#else /* CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
- from = out - dist; /* copy direct from output */
- do { /* minimum length is three */
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- len -= 3;
- } while (len > 2);
- if (len) {
- PUP(out) = PUP(from);
- if (len > 1)
- PUP(out) = PUP(from);
- }
-#endif /* !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS */
}
}
else if ((op & 64) == 0) { /* 2nd level distance code */
--
1.6.4.4
^ permalink raw reply related
* Re: UIO / of_genirq driver
From: Wolfram Sang @ 2010-01-28 10:45 UTC (permalink / raw)
To: John Williams
Cc: gregkh, devicetree-discuss, hjk, Linux Kernel list, linuxppc-dev
In-Reply-To: <1d3f23371001272313i62fc9158se4cd9173f196fb12@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]
John,
> I came across this thread/patchset from around June last year:
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073086.html
>
> where Wolfgang proposed a generic OF-driven UIO driver. The
Wolfram, please ;)
> discussion seemed to stall after Grant Likely indicated he didn't like
> the use of a linux-specific compatible binding in the device tree
> (compatible="generic-uio").
I agree with him on that.
> I guess I have a couple of questions:
>
> * did this patchset go anywhere? I've been using it here the last
> few days and it works great.
The idea was to create a mechanism to instantiate bindings at runtime, similar
to new_id for PCI/PCMCIA, e.g.:
$ echo "commodore,c64" > /sys/bus/of_platform/drivers/of_uio_genirq/new_compatible
so we don't have to maintain an ever growing list of hardcoded
compatible-properties for those UIO-devices.
> * Is there a better way to handle the OF bindings for this sort of thing?
Run-time instantiation might help in a couple of other cases; still, in the
progress of unifying/extending the OF-support, it was discussed if it was
possible to get rid of of_platform entirely. It looks like a very challenging
task, but seems to be favoured designwise (at least I do).
> However, the device-tree guys complain whenever anyone tries to encode
> anything non-hardware related into the DTS itself.
Well, if I get a device tree including special properties for Linux and BSD and
whatever may follow, that could get quite confusing :)
> I guess I'd like to just open up a discussion, see if there's been any
> progress towards a general solution.
I decided to wait for the outcome of the of_platform-removal-idea. Though, I
have to admit that in the last weeks I haven't followed of-related things due
to other commitments.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: USB host on 83xx
From: Gary Thomas @ 2010-01-28 12:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4B60D4D0.4020606@mlbassoc.com>
On 01/27/2010 05:05 PM, Gary Thomas wrote:
> On 01/27/2010 01:20 PM, Gary Thomas wrote:
>> I have two nearly identical boards, with very different behavior.
>>
>> Older 8347 (PVR: 0x80830011)
>> New 8347 (PVR: 0x80830031)
>
> I lied (more precisely I was lied to and I passed it on - I've never
> seen these boards in person, just worked on them from thousands of
> miles away).
>
> The boards have more than a rev difference:
> OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011)
> NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031)
This turned out to be a powerup/strapping issue. This is now fixed
and the SVR is 0x80550030 on the failing board. No change in behavior.
Does anyone have any ideas about this?
>
> Could this have any bearing on the problems?
>
>> I've tried a number of kernels (vintages) on both with wild results.
>>
>> 2.6.20 - Same kernel works on both(*)
>> 2.6.28 - Kernel runs great on OLD, machine check on NEW
>> 2.6.32.6 - Ditto
>>
>> The problem occurs (only on the new silicon) during the USB host
>> initialization. The root hub is found and initialized, then the
>> EHCI subsystem is reset (to force it to find siblings on the bus).
>> This results in a machine check at the point where the PHY is
>> being reinitialized.
>>
>> I've peppered the driver with messages - here's what I see:
>>
>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
>> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
>> ********** ehci_fsl_setup.272
>> ********** ehci_fsl_setup.296
>> ********** ehci_fsl_setup.299
>> ********** ehci_fsl_reinit.257
>> ********** mpc83xx_usb_setup.192
>> ********** mpc83xx_usb_setup.207
>> ********** mpc83xx_usb_setup.215
>> ********** mpc83xx_usb_setup.220
>> ********** mpc83xx_setup_phy.163
>> ********** mpc83xx_setup_phy.180
>> ********** mpc83xx_setup_phy.182
>> ********** mpc83xx_usb_setup.238
>> ********** mpc83xx_usb_setup.245
>> ********** mpc83xx_usb_setup.249
>> ********** mpc83xx_usb_setup.251
>> ********** ehci_fsl_reinit.259
>> ********** ehci_hub_control.559 - req: 8961
>> ********** ehci_hub_control.574
>> ********** ehci_hub_control.559 - req: 8961
>> ********** ehci_hub_control.574
>> ********** ehci_fsl_reinit.261
>> ********** ehci_fsl_setup.301
>> fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000
>> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
>> usb usb1: configuration #1 chosen from 1 choice
>> hub 1-0:1.0: USB hub found
>> ********** ehci_hub_control.559 - req: 40966
>> ********** ehci_hub_control.637
>> hub 1-0:1.0: 2 ports detected
>> ********** ehci_hub_control.559 - req: 40960
>> ********** ehci_hub_control.642
>> ********** ehci_hub_control.559 - req: 8963
>> ********** ehci_hub_control.805
>> ********** ehci_hub_control.559 - req: 8963
>> ********** ehci_hub_control.805
>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>> usb usb1: Product: Freescale On-Chip EHCI Host Controller
>> usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
>> usb usb1: SerialNumber: fsl-ehci.0
>> fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
>> fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
>> ********** ehci_fsl_setup.272
>> ********** ehci_fsl_setup.296
>> ********** ehci_fsl_setup.299
>> ********** ehci_fsl_reinit.257
>> ********** mpc83xx_usb_setup.192
>> ********** mpc83xx_usb_setup.207
>> ********** mpc83xx_usb_setup.215
>> ********** mpc83xx_setup_phy.163
>> ********** mpc83xx_setup_phy.180
>> MACHINE CHECK - so dead it can't even print the message!
>>
>> At this point, it should carry on like this:
>>
>> ********** ehci_hub_control.559 - req: 8963
>> ********** ehci_hub_control.805
>> ********** ehci_hub_control.559 - req: 41728
>> ********** ehci_hub_control.648
>> ********** ehci_hub_control.559 - req: 8961
>> ********** ehci_hub_control.574
>> usb 1-1: configuration #1 chosen from 1 choice
>> hub 1-1:1.0: USB hub found
>> hub 1-1:1.0: 4 ports detected
>> usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
>> usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
>> usb 1-1: Product: USB2.0 Hub
>> ********** ehci_hub_control.559 - req: 41728
>> ********** ehci_hub_control.648
>>
>> You can see that it successfully found the connected external HUB.
>>
>> Any ideas why this happens? This [basic] code used to work (2.6.20)
>> on both platforms. I know that's a long time ago, but MACHINE CHECK??
>>
>> (*) To get this platform to run 2.6.20, I had to patch the CPU tables
>> to recognize it as 8347 (kernels of that vintage relied on the SVR to
>> make choices, not PVR)
>>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: USB host on 83xx
From: Gary Thomas @ 2010-01-28 13:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4B61804C.3090503@mlbassoc.com>
On 01/28/2010 05:17 AM, Gary Thomas wrote:
> On 01/27/2010 05:05 PM, Gary Thomas wrote:
>> On 01/27/2010 01:20 PM, Gary Thomas wrote:
>>> I have two nearly identical boards, with very different behavior.
>>>
>>> Older 8347 (PVR: 0x80830011)
>>> New 8347 (PVR: 0x80830031)
>>
>> I lied (more precisely I was lied to and I passed it on - I've never
>> seen these boards in person, just worked on them from thousands of
>> miles away).
>>
>> The boards have more than a rev difference:
>> OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011)
>> NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031)
>
> This turned out to be a powerup/strapping issue. This is now fixed
> and the SVR is 0x80550030 on the failing board. No change in behavior.
>
> Does anyone have any ideas about this?
>
Even more data; it turns out that after the first write to the USB/DR
port status/control register, the processor is dead :-( Using a BDI:
** Dump the USB/DR machine registers
asp8347>md 0xff023100
ff023100 : 40000001 11000100 06000000 00000000 @...............
ff023110 : 00000000 00000000 00000000 00000000 ................
ff023120 : 01000000 86010000 00000000 00000000 ................
ff023130 : 00000000 00000000 00000000 00000000 ................
ff023140 : 00000800 00000000 00000000 00000000 ................
ff023150 : 00000000 00000000 00000000 00000000 ................
ff023160 : 10100000 00000000 00000000 00000000 ................
ff023170 : 00000008 00000000 00000000 00000000 ................
ff023180 : 01000000 00000090 00000000 00000000 ................
ff023190 : 00000000 00000000 00000000 00000000 ................
ff0231a0 : 00000000 20100000 00000000 00000000 .... ...........
ff0231b0 : 00000000 00000000 00000000 00000000 ................
ff0231c0 : 80008000 00000000 00000000 00000000 ................
ff0231d0 : 00000000 00000000 00000000 00000000 ................
ff0231e0 : 00000000 00000000 00000000 00000000 ................
ff0231f0 : 00000000 00000000 00000000 00000000 ................
** Write to the port status/control register
asp8347>mm 0xff023184 0x80
** Display the USB/DR registers
asp8347>md 0xff023100
# SAP: read access failed
This of course works fine on the 1.1 silicon.
>>
>> Could this have any bearing on the problems?
>>
>>> I've tried a number of kernels (vintages) on both with wild results.
>>>
>>> 2.6.20 - Same kernel works on both(*)
>>> 2.6.28 - Kernel runs great on OLD, machine check on NEW
>>> 2.6.32.6 - Ditto
>>>
>>> The problem occurs (only on the new silicon) during the USB host
>>> initialization. The root hub is found and initialized, then the
>>> EHCI subsystem is reset (to force it to find siblings on the bus).
>>> This results in a machine check at the point where the PHY is
>>> being reinitialized.
>>>
>>> I've peppered the driver with messages - here's what I see:
>>>
>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
>>> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
>>> ********** ehci_fsl_setup.272
>>> ********** ehci_fsl_setup.296
>>> ********** ehci_fsl_setup.299
>>> ********** ehci_fsl_reinit.257
>>> ********** mpc83xx_usb_setup.192
>>> ********** mpc83xx_usb_setup.207
>>> ********** mpc83xx_usb_setup.215
>>> ********** mpc83xx_usb_setup.220
>>> ********** mpc83xx_setup_phy.163
>>> ********** mpc83xx_setup_phy.180
>>> ********** mpc83xx_setup_phy.182
>>> ********** mpc83xx_usb_setup.238
>>> ********** mpc83xx_usb_setup.245
>>> ********** mpc83xx_usb_setup.249
>>> ********** mpc83xx_usb_setup.251
>>> ********** ehci_fsl_reinit.259
>>> ********** ehci_hub_control.559 - req: 8961
>>> ********** ehci_hub_control.574
>>> ********** ehci_hub_control.559 - req: 8961
>>> ********** ehci_hub_control.574
>>> ********** ehci_fsl_reinit.261
>>> ********** ehci_fsl_setup.301
>>> fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000
>>> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
>>> usb usb1: configuration #1 chosen from 1 choice
>>> hub 1-0:1.0: USB hub found
>>> ********** ehci_hub_control.559 - req: 40966
>>> ********** ehci_hub_control.637
>>> hub 1-0:1.0: 2 ports detected
>>> ********** ehci_hub_control.559 - req: 40960
>>> ********** ehci_hub_control.642
>>> ********** ehci_hub_control.559 - req: 8963
>>> ********** ehci_hub_control.805
>>> ********** ehci_hub_control.559 - req: 8963
>>> ********** ehci_hub_control.805
>>> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>>> usb usb1: Product: Freescale On-Chip EHCI Host Controller
>>> usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
>>> usb usb1: SerialNumber: fsl-ehci.0
>>> fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
>>> fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
>>> ********** ehci_fsl_setup.272
>>> ********** ehci_fsl_setup.296
>>> ********** ehci_fsl_setup.299
>>> ********** ehci_fsl_reinit.257
>>> ********** mpc83xx_usb_setup.192
>>> ********** mpc83xx_usb_setup.207
>>> ********** mpc83xx_usb_setup.215
>>> ********** mpc83xx_setup_phy.163
>>> ********** mpc83xx_setup_phy.180
>>> MACHINE CHECK - so dead it can't even print the message!
>>>
>>> At this point, it should carry on like this:
>>>
>>> ********** ehci_hub_control.559 - req: 8963
>>> ********** ehci_hub_control.805
>>> ********** ehci_hub_control.559 - req: 41728
>>> ********** ehci_hub_control.648
>>> ********** ehci_hub_control.559 - req: 8961
>>> ********** ehci_hub_control.574
>>> usb 1-1: configuration #1 chosen from 1 choice
>>> hub 1-1:1.0: USB hub found
>>> hub 1-1:1.0: 4 ports detected
>>> usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
>>> usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
>>> usb 1-1: Product: USB2.0 Hub
>>> ********** ehci_hub_control.559 - req: 41728
>>> ********** ehci_hub_control.648
>>>
>>> You can see that it successfully found the connected external HUB.
>>>
>>> Any ideas why this happens? This [basic] code used to work (2.6.20)
>>> on both platforms. I know that's a long time ago, but MACHINE CHECK??
>>>
>>> (*) To get this platform to run 2.6.20, I had to patch the CPU tables
>>> to recognize it as 8347 (kernels of that vintage relied on the SVR to
>>> make choices, not PVR)
>>>
>>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH v4 0/3] i2c-mpc: add support for the Freescale MPC512x and other fixes
From: Wolfgang Grandegger @ 2010-01-28 13:25 UTC (permalink / raw)
To: Linux-i2c; +Cc: Devicetree-discuss, Linuxppc-dev, Ben Dooks
This patch series adds support for the MPC512x from Freescale to the
i2c-mpc driver. At that occasion, issues with __devinit[data] have
been fixed and the doc of the FSL I2C dts bindings updated. It has
been tested on a MPC5121ADS, TQM5200 and TQM8560 board
Changes since v1:
- use macro MPC_I2C_CLOCK_PRESERVE/SAFE for the special clock settings.
- document the special DTS node "fsl,mpc5121-i2c-ctrl".
- update and correct the Kconfig help.
- some other minor fixes as suggested by Wolfram.
Changes since v2:
- use __init[data] instead of __devinit[data] for this driver.
Changes since v3:
- switch back to __devinit[data] as pointed out by Ben.
Wolfgang
Wolfgang Grandegger (3):
i2c-mpc: use __devinit[data] for initialization functions and data
i2c-mpc: add support for the MPC512x processors from Freescale
powerpc: doc/dts-bindings: update doc of FSL I2C bindings
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 30 +++-
drivers/i2c/busses/Kconfig | 7 +-
drivers/i2c/busses/i2c-mpc.c | 194 +++++++++++++++---------
3 files changed, 148 insertions(+), 83 deletions(-)
^ permalink raw reply
* [PATCH v4 1/3] i2c-mpc: use __devinit[data] for initialization functions and data
From: Wolfgang Grandegger @ 2010-01-28 13:25 UTC (permalink / raw)
To: Linux-i2c
Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger, Ben Dooks
In-Reply-To: <1264685141-26391-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@denx.de>
"__devinit[data]" has not yet been used for all initialization functions
and data. To avoid truncating lines, the struct "mpc_i2c_match_data" has
been renamed to "mpc_i2c_data", which is even the better name.
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
---
drivers/i2c/busses/i2c-mpc.c | 103 +++++++++++++++++++----------------------
1 files changed, 48 insertions(+), 55 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index f627001..275ebe6 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -66,7 +66,7 @@ struct mpc_i2c_divider {
u16 fdr; /* including dfsrr */
};
-struct mpc_i2c_match_data {
+struct mpc_i2c_data {
void (*setclock)(struct device_node *node,
struct mpc_i2c *i2c,
u32 clock, u32 prescaler);
@@ -165,7 +165,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
}
#ifdef CONFIG_PPC_MPC52xx
-static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
+static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
{28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
{36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
@@ -186,7 +186,8 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
};
-int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
+static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
+ int prescaler)
{
const struct mpc_i2c_divider *div = NULL;
unsigned int pvr = mfspr(SPRN_PVR);
@@ -215,9 +216,9 @@ int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
return div ? (int)div->fdr : -EINVAL;
}
-static void mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
@@ -230,15 +231,15 @@ static void mpc_i2c_setclock_52xx(struct device_node *node,
dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
}
#else /* !CONFIG_PPC_MPC52xx */
-static void mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
#endif /* CONFIG_PPC_MPC52xx*/
#ifdef CONFIG_FSL_SOC
-static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
+static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
{160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
{288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
{416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
@@ -258,7 +259,7 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
{49152, 0x011e}, {61440, 0x011f}
};
-u32 mpc_i2c_get_sec_cfg_8xxx(void)
+static u32 __devinit mpc_i2c_get_sec_cfg_8xxx(void)
{
struct device_node *node = NULL;
u32 __iomem *reg;
@@ -287,7 +288,8 @@ u32 mpc_i2c_get_sec_cfg_8xxx(void)
return val;
}
-int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
+static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
+ u32 prescaler)
{
const struct mpc_i2c_divider *div = NULL;
u32 divider;
@@ -320,9 +322,9 @@ int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
return div ? (int)div->fdr : -EINVAL;
}
-static void mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
@@ -338,9 +340,9 @@ static void mpc_i2c_setclock_8xxx(struct device_node *node,
}
#else /* !CONFIG_FSL_SOC */
-static void mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
#endif /* CONFIG_FSL_SOC */
@@ -529,8 +531,8 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
clock = *prop;
if (match->data) {
- struct mpc_i2c_match_data *data =
- (struct mpc_i2c_match_data *)match->data;
+ struct mpc_i2c_data *data =
+ (struct mpc_i2c_data *)match->data;
data->setclock(op->node, i2c, clock, data->prescaler);
} else {
/* Backwards compatibility */
@@ -582,44 +584,35 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
return 0;
};
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_52xx = {
+ .setclock = mpc_i2c_setclock_52xx,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8313 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8543 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 2,
+};
+
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_8544 = {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 3,
+};
+
static const struct of_device_id mpc_i2c_of_match[] = {
- {.compatible = "mpc5200-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc5200b-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc5200-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_52xx,
- },
- },
- {.compatible = "fsl,mpc8313-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- },
- },
- {.compatible = "fsl,mpc8543-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- .prescaler = 2,
- },
- },
- {.compatible = "fsl,mpc8544-i2c",
- .data = &(struct mpc_i2c_match_data) {
- .setclock = mpc_i2c_setclock_8xxx,
- .prescaler = 3,
- },
+ {.compatible = "mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
+ {.compatible = "fsl,mpc5200b-i2c", .data = &mpc_i2c_data_52xx, },
+ {.compatible = "fsl,mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
+ {.compatible = "fsl,mpc8313-i2c", .data = &mpc_i2c_data_8313, },
+ {.compatible = "fsl,mpc8543-i2c", .data = &mpc_i2c_data_8543, },
+ {.compatible = "fsl,mpc8544-i2c", .data = &mpc_i2c_data_8544, },
/* Backward compatibility */
- },
{.compatible = "fsl-i2c", },
{},
};
-
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
@@ -634,7 +627,7 @@ static struct of_platform_driver mpc_i2c_driver = {
},
};
-static int __init fsl_i2c_init(void)
+static int __devinit fsl_i2c_init(void)
{
int rv;
@@ -645,7 +638,7 @@ static int __init fsl_i2c_init(void)
return rv;
}
-static void __exit fsl_i2c_exit(void)
+static void __devexit fsl_i2c_exit(void)
{
of_unregister_platform_driver(&mpc_i2c_driver);
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH v4 2/3] i2c-mpc: add support for the MPC512x processors from Freescale
From: Wolfgang Grandegger @ 2010-01-28 13:25 UTC (permalink / raw)
To: Linux-i2c
Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger, Ben Dooks
In-Reply-To: <1264685141-26391-2-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@denx.de>
The "setclock" initialization functions have been renamed to "setup"
because I2C interrupts must be enabled for the MPC512x. This requires
to handle "fsl,preserve-clocking" in a slighly different way. Also,
the old settings are now reported calling dev_dbg(). For the MPC512x
the clock setup function of the MPC52xx can be re-used. Furthermore,
the Kconfig help has been updated and corrected.
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
---
drivers/i2c/busses/Kconfig | 7 +-
drivers/i2c/busses/i2c-mpc.c | 127 ++++++++++++++++++++++++++++++------------
2 files changed, 94 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 5f318ce..5477e41 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -418,13 +418,12 @@ config I2C_IXP2000
instead.
config I2C_MPC
- tristate "MPC107/824x/85xx/52xx/86xx"
+ tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx"
depends on PPC32
help
If you say yes to this option, support will be included for the
- built-in I2C interface on the MPC107/Tsi107/MPC8240/MPC8245 and
- MPC85xx/MPC8641 family processors. The driver may also work on 52xx
- family processors, though interrupts are known not to work.
+ built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx,
+ MPC8240, MPC8245, MPC83xx, MPC85xx and MPC8641 family processors.
This driver can also be built as a module. If so, the module
will be called i2c-mpc.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 275ebe6..1af0730 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -31,6 +31,9 @@
#define DRV_NAME "mpc-i2c"
+#define MPC_I2C_CLOCK_SAFE 0
+#define MPC_I2C_CLOCK_PRESERVE (~0U)
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
@@ -67,9 +70,8 @@ struct mpc_i2c_divider {
};
struct mpc_i2c_data {
- void (*setclock)(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler);
+ void (*setup)(struct device_node *node, struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler);
u32 prescaler;
};
@@ -164,7 +166,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
return 0;
}
-#ifdef CONFIG_PPC_MPC52xx
+#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
{28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
@@ -216,12 +218,18 @@ static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
return div ? (int)div->fdr : -EINVAL;
}
-static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
+ if (clock == MPC_I2C_CLOCK_PRESERVE) {
+ dev_dbg(i2c->dev, "using fdr %d\n",
+ readb(i2c->base + MPC_I2C_FDR));
+ return;
+ }
+
ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
@@ -230,13 +238,49 @@ static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
if (ret >= 0)
dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
}
-#else /* !CONFIG_PPC_MPC52xx */
-static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+#else /* !(CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x) */
+static void __devinit mpc_i2c_setup_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+}
+#endif /* CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x */
+
+#ifdef CONFIG_PPC_MPC512x
+static void __devinit mpc_i2c_setup_512x(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ struct device_node *node_ctrl;
+ void __iomem *ctrl;
+ const u32 *pval;
+ u32 idx;
+
+ /* Enable I2C interrupts for mpc5121 */
+ node_ctrl = of_find_compatible_node(NULL, NULL,
+ "fsl,mpc5121-i2c-ctrl");
+ if (node_ctrl) {
+ ctrl = of_iomap(node_ctrl, 0);
+ if (ctrl) {
+ /* Interrupt enable bits for i2c-0/1/2: bit 24/26/28 */
+ pval = of_get_property(node, "reg", NULL);
+ idx = (*pval & 0xff) / 0x20;
+ setbits32(ctrl, 1 << (24 + idx * 2));
+ iounmap(ctrl);
+ }
+ of_node_put(node_ctrl);
+ }
+
+ /* The clock setup for the 52xx works also fine for the 512x */
+ mpc_i2c_setup_52xx(node, i2c, clock, prescaler);
+}
+#else /* CONFIG_PPC_MPC512x */
+static void __devinit mpc_i2c_setup_512x(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
-#endif /* CONFIG_PPC_MPC52xx*/
+#endif /* CONFIG_PPC_MPC512x */
#ifdef CONFIG_FSL_SOC
static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
@@ -322,12 +366,19 @@ static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
return div ? (int)div->fdr : -EINVAL;
}
-static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
int ret, fdr;
+ if (clock == MPC_I2C_CLOCK_PRESERVE) {
+ dev_dbg(i2c->dev, "using dfsrr %d, fdr %d\n",
+ readb(i2c->base + MPC_I2C_DFSRR),
+ readb(i2c->base + MPC_I2C_FDR));
+ return;
+ }
+
ret = mpc_i2c_get_fdr_8xxx(node, clock, prescaler);
fdr = (ret >= 0) ? ret : 0x1031; /* backward compatibility */
@@ -340,9 +391,9 @@ static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
}
#else /* !CONFIG_FSL_SOC */
-static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
- struct mpc_i2c *i2c,
- u32 clock, u32 prescaler)
+static void __devinit mpc_i2c_setup_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
{
}
#endif /* CONFIG_FSL_SOC */
@@ -496,7 +547,7 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
{
struct mpc_i2c *i2c;
const u32 *prop;
- u32 clock = 0;
+ u32 clock = MPC_I2C_CLOCK_SAFE;
int result = 0;
int plen;
@@ -525,21 +576,21 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
}
}
- if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
+ if (of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
+ clock = MPC_I2C_CLOCK_PRESERVE;
+ } else {
prop = of_get_property(op->node, "clock-frequency", &plen);
if (prop && plen == sizeof(u32))
clock = *prop;
+ }
- if (match->data) {
- struct mpc_i2c_data *data =
- (struct mpc_i2c_data *)match->data;
- data->setclock(op->node, i2c, clock, data->prescaler);
- } else {
- /* Backwards compatibility */
- if (of_get_property(op->node, "dfsrr", NULL))
- mpc_i2c_setclock_8xxx(op->node, i2c,
- clock, 0);
- }
+ if (match->data) {
+ struct mpc_i2c_data *data = match->data;
+ data->setup(op->node, i2c, clock, data->prescaler);
+ } else {
+ /* Backwards compatibility */
+ if (of_get_property(op->node, "dfsrr", NULL))
+ mpc_i2c_setup_8xxx(op->node, i2c, clock, 0);
}
dev_set_drvdata(&op->dev, i2c);
@@ -584,21 +635,25 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
return 0;
};
+static struct mpc_i2c_data __devinitdata mpc_i2c_data_512x = {
+ .setup = mpc_i2c_setup_512x,
+};
+
static struct mpc_i2c_data __devinitdata mpc_i2c_data_52xx = {
- .setclock = mpc_i2c_setclock_52xx,
+ .setup = mpc_i2c_setup_52xx,
};
static struct mpc_i2c_data __devinitdata mpc_i2c_data_8313 = {
- .setclock = mpc_i2c_setclock_8xxx,
+ .setup = mpc_i2c_setup_8xxx,
};
static struct mpc_i2c_data __devinitdata mpc_i2c_data_8543 = {
- .setclock = mpc_i2c_setclock_8xxx,
+ .setup = mpc_i2c_setup_8xxx,
.prescaler = 2,
};
static struct mpc_i2c_data __devinitdata mpc_i2c_data_8544 = {
- .setclock = mpc_i2c_setclock_8xxx,
+ .setup = mpc_i2c_setup_8xxx,
.prescaler = 3,
};
@@ -606,6 +661,7 @@ static const struct of_device_id mpc_i2c_of_match[] = {
{.compatible = "mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
{.compatible = "fsl,mpc5200b-i2c", .data = &mpc_i2c_data_52xx, },
{.compatible = "fsl,mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
+ {.compatible = "fsl,mpc5121-i2c", .data = &mpc_i2c_data_512x, },
{.compatible = "fsl,mpc8313-i2c", .data = &mpc_i2c_data_8313, },
{.compatible = "fsl,mpc8543-i2c", .data = &mpc_i2c_data_8543, },
{.compatible = "fsl,mpc8544-i2c", .data = &mpc_i2c_data_8544, },
@@ -615,7 +671,6 @@ static const struct of_device_id mpc_i2c_of_match[] = {
};
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
-
/* Structure for a device driver */
static struct of_platform_driver mpc_i2c_driver = {
.match_table = mpc_i2c_of_match,
@@ -648,5 +703,5 @@ module_exit(fsl_i2c_exit);
MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
MODULE_DESCRIPTION("I2C-Bus adapter for MPC107 bridge and "
- "MPC824x/85xx/52xx processors");
+ "MPC824x/85xx/512x/52xx processors");
MODULE_LICENSE("GPL");
--
1.6.2.5
^ permalink raw reply related
* [PATCH v4 3/3] powerpc: doc/dts-bindings: update doc of FSL I2C bindings
From: Wolfgang Grandegger @ 2010-01-28 13:25 UTC (permalink / raw)
To: Linux-i2c
Cc: Devicetree-discuss, Linuxppc-dev, Wolfgang Grandegger, Ben Dooks
In-Reply-To: <1264685141-26391-3-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@denx.de>
This patch adds the MPC5121 to the list of supported devices,
enhances the doc of the "clock-frequency" property and removes
the obsolete "cell-index" property from the example nodes.
Furthermore and example for the MPC5121 has been added.
Signed-off-by: Wolfgang Grandegger <wg@denx.de>
---
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 30 +++++++++++++++++++----
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/i2c.txt
index b6d2e21..2f62dae 100644
--- a/Documentation/powerpc/dts-bindings/fsl/i2c.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/i2c.txt
@@ -9,8 +9,9 @@ Recommended properties :
- compatible : compatibility list with 2 entries, the first should
be "fsl,CHIP-i2c" where CHIP is the name of a compatible processor,
- e.g. mpc8313, mpc8543, mpc8544, mpc5200 or mpc5200b. The second one
- should be "fsl-i2c".
+ e.g. mpc8313, mpc8543, mpc8544, mpc5121, mpc5200 or mpc5200b. The
+ second one should be "fsl-i2c". For the mpc5121, an additional node
+ "fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
@@ -20,29 +21,46 @@ Recommended properties :
services interrupts for this device.
- fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
- - clock-frequency : desired I2C bus clock frequency in Hz.
+ - clock-frequency : desired I2C bus clock frequency in Hz. If this
+ property and "fsl,preserve-clocking" is not defined, a safe fixed
+ clock divider value is used (resulting in a small clock frequency).
Examples :
+ /* MPC5121 based board */
+ i2c@1740 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+ reg = <0x1740 0x20>;
+ interrupts = <11 0x8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <100000>;
+ };
+
+ i2ccontrol@1760 {
+ compatible = "fsl,mpc5121-i2c-ctrl";
+ reg = <0x1760 0x8>;
+ };
+
+ /* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
- cell-index = <0>;
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
+ /* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
- cell-index = <1>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
};
-
--
1.6.2.5
^ permalink raw reply related
* [PATCH] powerpc/mpc512x: Add gpio driver
From: Matthias Fuchs @ 2010-01-28 13:48 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
---
arch/powerpc/include/asm/mpc512x_gpio.h | 30 +++++
arch/powerpc/platforms/Kconfig | 9 ++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/mpc512x_gpio.c | 179 +++++++++++++++++++++++++++++++
4 files changed, 219 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpc512x_gpio.h
create mode 100644 arch/powerpc/sysdev/mpc512x_gpio.c
diff --git a/arch/powerpc/include/asm/mpc512x_gpio.h b/arch/powerpc/include/asm/mpc512x_gpio.h
new file mode 100644
index 0000000..8b6922d
--- /dev/null
+++ b/arch/powerpc/include/asm/mpc512x_gpio.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2010 Matthias Fuchs <matthias.fuchs@esd.eu>, esd gmbh
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#ifndef MPC512X_GPIO_H
+#define MPC512X_GPIO_H
+
+struct mpc512x_gpio_regs {
+ u32 gpdir;
+ u32 gpodr;
+ u32 gpdat;
+ u32 gpier;
+ u32 gpimr;
+ u32 gpicr1;
+ u32 gpicr2;
+};
+
+#endif /* MPC512X_GPIO_H */
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..76234cd 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -312,6 +312,15 @@ config MPC8xxx_GPIO
Say Y here if you're going to use hardware that connects to the
MPC831x/834x/837x/8572/8610 GPIOs.
+config MPC512x_GPIO
+ bool "MPC512x GPIO support"
+ depends on PPC_MPC512x
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ MPC512x GPIOs.
+
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
depends on PPC
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..cb61f2a 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_MPC512x_GPIO) += mpc512x_gpio.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/mpc512x_gpio.c b/arch/powerpc/sysdev/mpc512x_gpio.c
new file mode 100644
index 0000000..09f075b
--- /dev/null
+++ b/arch/powerpc/sysdev/mpc512x_gpio.c
@@ -0,0 +1,179 @@
+/*
+ * MPC512x gpio driver
+ *
+ * Copyright (c) 2010 Matthias Fuchs <matthias.fuchs@esd.eu>, esd gmbh
+ *
+ * derived from ppc4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Steve Falco <sfalco@harris.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+#include <linux/types.h>
+#include <asm/mpc512x_gpio.h>
+
+#define GPIO_MASK(gpio) (0x80000000 >> (gpio))
+
+struct mpc512x_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 32 gpios in each gpio controller.
+ */
+static inline struct mpc512x_chip *
+to_mpc512x_gpiochip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct mpc512x_chip, mm_gc);
+}
+
+static int mpc512x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+ return in_be32(®s->gpdat) & GPIO_MASK(gpio);
+}
+
+static inline void
+__mpc512x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+ if (val)
+ setbits32(®s->gpdat, GPIO_MASK(gpio));
+ else
+ clrbits32(®s->gpdat, GPIO_MASK(gpio));
+}
+
+static void
+mpc512x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ __mpc512x_gpio_set(gc, gpio, val);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc512x_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* Disable open-drain function */
+ clrbits32(®s->gpodr, GPIO_MASK(gpio));
+
+ /* Float the pin */
+ clrbits32(®s->gpdir, GPIO_MASK(gpio));
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ return 0;
+}
+
+static int
+mpc512x_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* First set initial value */
+ __mpc512x_gpio_set(gc, gpio, val);
+
+ /* Disable open-drain function */
+ clrbits32(®s->gpodr, GPIO_MASK(gpio));
+
+ /* Drive the pin */
+ setbits32(®s->gpdir, GPIO_MASK(gpio));
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+static int __init mpc512x_add_gpiochips(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio") {
+ int ret;
+ struct mpc512x_chip *mpc512x_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ mpc512x_gc = kzalloc(sizeof(*mpc512x_gc), GFP_KERNEL);
+ if (!mpc512x_gc) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&mpc512x_gc->lock);
+
+ mm_gc = &mpc512x_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ gc->ngpio = 32;
+ gc->direction_input = mpc512x_gpio_dir_in;
+ gc->direction_output = mpc512x_gpio_dir_out;
+ gc->get = mpc512x_gpio_get;
+ gc->set = mpc512x_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+ continue;
+err:
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(mpc512x_gc);
+ /* try others anyway */
+ }
+ return 0;
+}
+arch_initcall(mpc512x_add_gpiochips);
--
1.5.6.3
^ permalink raw reply related
* mmap performance of reserved top sdram in powerpc platform
From: Lonsn @ 2010-01-28 14:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lonsn
Hi all:
I have reserved top 128MBytes sdram for PCI DMA usage. External PCI
master sends data to top sdram and then wake up user space app.
User space use /dev/mem and mmap to access this region and then send
them to network using socket.
I found send speed of memory data in /dev/mem to network is very slow.
(300Mbits/s)
If I malloc memory data in user space and then send to network, the
speed is much higher. (750Mbits/s).
I know the reason is the sdram in /dev/mem marked as un-cached.
How can I set the top sdram as cached to impove performance and be
sure that the data is coherent.
My kernel version is DENX-v2.6.32.
Thanks.
^ permalink raw reply
* Is it normal when kernel printed "xxx used greatest stack depth"
From: hank peng @ 2010-01-28 15:53 UTC (permalink / raw)
To: linuxppc-dev
On my MPC8548 based board, sometimes kernel printed out the following
messages, I wonder if it indicates the system is not normal?
pdflush used greatest stack depth: 4048 bytes left
pdflush used greatest stack depth: 4028 bytes left
pdflush used greatest stack depth: 3964 bytes left
pdflush used greatest stack depth: 3916 bytes left
--
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* Re: Is it normal when kernel printed "xxx used greatest stack depth"
From: Arnd Bergmann @ 2010-01-28 20:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, hank peng
In-Reply-To: <389deec71001280753n2df39d98m4b8c60f971a29bc7@mail.gmail.com>
On Thursday 28 January 2010, hank peng wrote:
> On my MPC8548 based board, sometimes kernel printed out the following
> messages, I wonder if it indicates the system is not normal?
>
> pdflush used greatest stack depth: 4048 bytes left
> pdflush used greatest stack depth: 4028 bytes left
> pdflush used greatest stack depth: 3964 bytes left
> pdflush used greatest stack depth: 3916 bytes left
It's a debug option that you have enabled in the kernel configuration.
3916 bytes left is not unusual, there is nothing to worry here,
but on production systems, you might want to disable
CONFIG_DEBUG_STACK_USAGE.
Arnd
^ permalink raw reply
* Re: [PATCHv2 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Joel Schopp @ 2010-01-28 22:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, Ingo Molnar, linuxppc-dev, Peter Zijlstra, ego
In-Reply-To: <1264553577.3601.144.camel@pasglop>
>
> What about an early exit if !cpu_has_feature(CPU_FTR_SMT) ? That would
> de-facto compile it out for 32-bit CPU platforms that don't support SMT
> at all and avoid some overhead on POWER3,4,970...
>
If the SD_SHARE_CPUPOWER flag isn't set for the sched domain this
function isn't called. So an extra check here is wasteful.
>
>> + unsigned long weight = cpumask_weight(sibling_map);
>> + unsigned long smt_gain = sd->smt_gain;
>> +
>> + if (cpu_has_feature(CPU_FTR_ASYNC_SMT4) && weight == 4) {
>>
>
> So that will only handle the case where all 4 threads are online right ?
> There is no provision for the case where the user play tricks like
> offlining thread, in which case it will stop trying to "push down"
> processes right ? Not a big deal per-se I suppose, just something to be
> aware of.
>
I've tested it with manually offlined threads and it behaves as I'd like
it to.
> Also, can you add a comment as to why this is done in the code itself ?
> above the if (cpu_has_feature(...)) statement.
>
OK. v3 coming soon with the comment.
^ permalink raw reply
* [PATCHv3 0/2] sched: arch_scale_smt_powers
From: Joel Schopp @ 2010-01-28 23:20 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: ego, linux-kernel, Ingo Molnar, linuxppc-dev
In-Reply-To: <1264548479.12239.54.camel@jschopp-laptop>
The new Power7 processor has 4 way SMT. This 4 way SMT benefits from
dynamic power updates that arch_scale_smt_power was designed to provide.
The first patch fixes a generic scheduler bug necessary for arch_scale_smt
to properly function. The second patch implements arch_scale_smt_power
for powerpc, and in particular for Power7 processors.
Version 2 changes:
- Drop Patch 1 from the original series since it's in the -tip tree now
- Move enabling the cpu feature into it's own patch (now patch 1)
- Add stubbing out broken x86 implementation to patch 1
- clean up coding style in patch 2
Version 3 changes:
- Added a comment to Patch 2
---
Joel Schopp (2):
powerpc: implement arch_scale_smt_power for Power7
sched: enable ARCH_POWER
arch/powerpc/include/asm/cputable.h | 3 +
arch/powerpc/kernel/smp.c | 56
++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/sched.c | 6 +--
kernel/sched_features.h | 2 -
4 files changed, 61 insertions(+), 6 deletions(-)
^ 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