* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Segher Boessenkool @ 2011-06-24 2:36 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@ozlabs.org, paulus@samba.org,
McClintock Matthew-B29882, Gala Kumar-B11780, Timur Tabi
In-Reply-To: <20110623124802.7aeb6b66@schlenkerla.am.freescale.net>
>> But does that mean that a guest should never be allowed to modify a
>> virtualized
>> timebase register, even if the hypervisor can support it?
>
> The book3e mtspr writeup doesn't appear to specify the behavior when
> writing to a read-only SPR, so perhaps you could argue that something
> other
> than a no-op is implementation-specific behavior.
v2.06 III-E 9.2.1:
"Writing the Time Base is hypervisor privileged."
v2.06 III-E 2.1:
"If a hypervisor-privileged register is accessed in the guest supervisor
state (MSR[GS PR] = 0b10), an Embedded Hypervisor Privilege exception
occurs."
(v2.06 III-E 5.4.1, the big SPR table, also shows the TB regs (for
writing,
i.e. 284 and 285) to be hypervisor privileged. Consistency, hurray :-)
)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc, 460gt: Add 460gt as compatible in the check for 460ex-compatible crypto
From: Segher Boessenkool @ 2011-06-24 2:14 UTC (permalink / raw)
To: Mike Williams; +Cc: linuxppc-dev
In-Reply-To: <BANLkTinisHPrEN8Xc_KoqFwxknMooE=H4w@mail.gmail.com>
>>> - =A0 =A0 =A0 if (of_find_compatible_node(NULL, NULL,=20
>>> "amcc,ppc460ex-crypto")) {
>>> + =A0 =A0 =A0 if (of_find_compatible_node(NULL, NULL,=20
>>> "amcc,ppc460ex-crypto") ||
>>> + =A0 =A0 =A0 =A0 =A0 of_find_compatible_node(NULL, NULL,=20
>>> "amcc,ppc460gt-crypto")) {
>>
>> If the device is actually compatible, the device tree node should=20
>> claim
>> it is, and you do not need this code change.
>
> That was actually my first instinct, however I tried to follow the
> current convention in the glacier and canyonlands DTS files, which is
> to set every device compatible to 460gt or 460ex, depending on the
> processor. Many of the devices are identical between the two, since
> they are variations of the same SoC, so which is the preferred method?
> Follow the device tree convention and add the compatibility check in
> the driver,
That is not the convention.
> or alter the device trees? I'll send another patch if it's
> the latter.
You say
compatible =3D "amcc,ppc460gt-crypto", "amcc,ppc460ex-crypto";
So, a unique name for the actual device first, followed by the name of
what it is compatible to. The driver for 460ex-crypto will then work
without any changes, but it can also do some 460gt-specific workarounds
or enhancements; or you could even have a totally separate driver for
the 460gt-crypto (you'll have to arrange for it to be used preferably
then).
You should document this 460gt-crypto binding, btw (a single line in
the 460ex-crypto binding doc will do).
Segher
^ permalink raw reply
* [PATCH v9 11/13] powerpc: select HAVE_SECCOMP_FILTER and provide seccomp_execve
From: Will Drewry @ 2011-06-24 0:36 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Will Drewry, fweisbec, scarybeasts, djm, jmorris,
rostedt, tglx, mingo, Paul Mackerras, kees.cook, torvalds, segoon
In-Reply-To: <1308875813-20122-1-git-send-email-wad@chromium.org>
Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility
system call numbering for execve and selecting HAVE_SECCOMP_FILTER.
v9: rebase on to bccaeafd7c117acee36e90d37c7e05c19be9e7bf
Signed-off-by: Will Drewry <wad@chromium.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/seccomp.h | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2729c66..030d392 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -129,6 +129,7 @@ config PPC
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
+ select HAVE_SECCOMP_FILTER
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
index 00c1d91..3cb9cc1 100644
--- a/arch/powerpc/include/asm/seccomp.h
+++ b/arch/powerpc/include/asm/seccomp.h
@@ -7,10 +7,12 @@
#define __NR_seccomp_write __NR_write
#define __NR_seccomp_exit __NR_exit
#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#define __NR_seccomp_execve __NR_execve
#define __NR_seccomp_read_32 __NR_read
#define __NR_seccomp_write_32 __NR_write
#define __NR_seccomp_exit_32 __NR_exit
#define __NR_seccomp_sigreturn_32 __NR_sigreturn
+#define __NR_seccomp_execve_32 __NR_execve
#endif /* _ASM_POWERPC_SECCOMP_H */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] STAGING: Comedi: Build only on arches providing PAGE_KERNEL_NOCACHE
From: Benjamin Herrenschmidt @ 2011-06-23 22:01 UTC (permalink / raw)
To: Ralf Baechle
Cc: devel, David Howells, linux-m32r, Paul Mundt, linux-sh,
Greg Kroah-Hartman, linux-kernel, Chris Metcalf, Martyn Welch,
linux-am33-list, Paul Mackerras, linux-m32r-ja, H. Peter Anvin,
Thomas Gleixner, linux-arch, linuxppc-dev, Ingo Molnar, x86
In-Reply-To: <20110623120234.GA22524@linux-mips.org>
On Thu, 2011-06-23 at 13:02 +0100, Ralf Baechle wrote:
> On Thu, Jun 23, 2011 at 12:53:36PM +0100, Martyn Welch wrote:
>
> > On 23/06/11 12:45, Ralf Baechle wrote:
> > > On architectures that don't define PAGE_KERNEL_NOCACHE, the Comedi driver turns
> > > into tragedy:
> > >
> > > CC [M] drivers/staging/comedi/drivers.o
> > > drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> > > drivers/staging/comedi/drivers.c:505:41: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
> > > drivers/staging/comedi/drivers.c:505:41: note: each undeclared identifier is rep orted only once for each function it appears in
> > > make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> > >
> > > Restrict the driver to only those architectures that define PAGE_KERNEL_NOCACHE.
> > >
> > > PAGE_KERNEL_NOCACHE is a kludge - some system architectures such as SGI IP27
> > > are even uable to offer uncached operation - at least in the way an unwitting
> > > driver might assume. I haven't looked in details how the driver is using
> > > the area vmaped with PAGE_KERNEL_NOCACHE but maybe doing it XFS-style using
> > > cached memory and the flush_kernel_vmap_range / invalidate_kernel_vmap_range
> > > APIs in conjunction with the DMA API is a practical alternative.
> > >
> > > Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> > >
> > > drivers/staging/comedi/Kconfig | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
> > > index 1502d80..bccdc12 100644
> > > --- a/drivers/staging/comedi/Kconfig
> > > +++ b/drivers/staging/comedi/Kconfig
> > > @@ -2,6 +2,7 @@ config COMEDI
> > > tristate "Data acquisition support (comedi)"
> > > default N
> > > depends on m
> > > + depends on BROKEN || FRV || M32R || MN10300 || SUPERH || TILE || X86
> >
> > I'm sure I got comedi to compile on a 32-bit PPC board not that long ago. Has
> > something changed, or is this just not an exhaustive list?
It went away. There's a proper API (pgprot_noncached), but it depends
what this is used for and it's likely to be broken anyways... what is
that driver trying to map non-cached ?
Cheers,
Ben.
> (Adding the PPC folks to cc.)
>
> A "git grep -w PAGE_KERNEL_NOCACHE arch/powerpc/" doesn't find anything so
> I don't think the driver will build there. I don't have a PPC toolchain
> to verify that.
>
> Ralf
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] libata/sas: only set FROZEN flag if new EH is supported
From: Benjamin Herrenschmidt @ 2011-06-23 21:43 UTC (permalink / raw)
To: Brian King
Cc: jgarzik, wayneb, linux-kernel, linux-ide, mbizon, Tejun Heo,
Nishanth Aravamudan, linuxppc-dev
In-Reply-To: <4E039C95.3070907@linux.vnet.ibm.com>
On Thu, 2011-06-23 at 15:05 -0500, Brian King wrote:
>
> Same here.
>
> When did this last work on this system? It seems like this is
> completely
> separate from the libata issue.
It's separate. See my other internal message. This is a BML system and
it's broken as far as 2.6.36 but the BML "patched" kernel works,
anyways, moving that off list for now.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/5] drivers/amba: create devices from device tree
From: Grant Likely @ 2011-06-23 20:55 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Pitre, Russell King, Arnd Bergmann, devicetree-discuss,
linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4E00F9ED.1020500@gmail.com>
On Tue, Jun 21, 2011 at 2:07 PM, Rob Herring <robherring2@gmail.com> wrote:
> Grant,
>
> On 06/21/2011 01:45 PM, Grant Likely wrote:
>> Add a function to create amba_devices (i.e. primecell peripherals)
>> from device tree nodes. The device tree scanning is done by the
>> of_platform_populate() function which can call of_amba_device_create
>> based on a match table entry.
>>
>> Nodes with a "arm,primecell-periphid" property can override the h/w
>> peripheral id value.
>>
>> Based on the original work by Jeremy Kerr.
>>
>> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>> [grant.likely: add Jeremy's original s-o-b line, changes from review
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0comments, and moved all code to drivers/o=
f/platform.c]
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>> =A0.../devicetree/bindings/arm/primecell.txt =A0 =A0 =A0 =A0 =A0| =A0 21=
++++++
>> =A0drivers/of/platform.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0| =A0 71 ++++++++++++++++++++
>> =A02 files changed, 92 insertions(+), 0 deletions(-)
>> =A0create mode 100644 Documentation/devicetree/bindings/arm/primecell.tx=
t
>>
>> diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Docum=
entation/devicetree/bindings/arm/primecell.txt
>> new file mode 100644
>> index 0000000..1d5d7a8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/primecell.txt
>> @@ -0,0 +1,21 @@
>> +* ARM Primecell Peripherals
>> +
>> +ARM, Ltd. Primecell peripherals have a standard id register that can be=
used to
>> +identify the peripheral type, vendor, and revision. This value can be u=
sed for
>> +driver matching.
>> +
>> +Required properties:
>> +
>> +- compatible : should be a specific value for peripheral and "arm,prime=
cell"
>
> Can I review what I wrote... Perhaps we should put strings in for all
> existing drivers in the kernel. This should be a complete list:
>
> arm,pl010
> arm,pl011
> st,pl011
> arm,pl022
> st,pl022
> st,pl023
> arm,pl030
> arm,pl031
> st,pl031
> arm,pl061
> arm,pl050
> arm,pl080
> arm,pl081
> st,pl080
> arm,pl110
> arm,pl180
> arm,pl330
> arm,sp804
> arm,sp805
Yes, this whole list should be added.
g.
^ permalink raw reply
* Re: Connecting SGMII PHY to eTSEC1 on P1022
From: Felix Radensky @ 2011-06-23 20:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4E02229B.50707@embedded-sol.com>
Hi,
On 06/22/2011 08:12 PM, Felix Radensky wrote:
> Hi Timur,
>
> On 06/22/2011 07:18 PM, Timur Tabi wrote:
>> Felix Radensky wrote:
>>> What am I doing wrong ?
>> Can you debug the PHY driver to see if it's getting called and
>> trying to talk to
>> the PHY itself?
>>
> I'll do that tomorrow and report back.
I've found the problem by looking at the code. My SGMII PHY is Marvell
88E1112.
Marvell PHY driver claims it supports that PHY, but in reality it
doesn't. It uses
routines initially written for 88E1111 to configure 88E1112,
essentially writing
to registers that do not exist on that PHY. After disabling Marvell
PHY driver my
PHY started working.
Felix.
^ permalink raw reply
* [PATCH] fsl-diu-fb: remove check for pixel clock ranges
From: Timur Tabi @ 2011-06-23 20:20 UTC (permalink / raw)
To: lethal, linux-fbdev, agust, yorksun, linuxppc-dev
The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
the pixel clock. These values, however, are true only for one platform
clock rate (533MHz) and only for the MPC8610. So the actual range for
the pixel clock is chip-specific, which means the current values are almost
always wrong. The chance of an out-of-range pixel clock being used are also
remote.
Rather than try to detect an out-of-range clock in the DIU driver, we depend
on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
to clamp the pixel clock to a supported value.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/video/fsl-diu-fb.c | 16 ----------------
include/linux/fsl-diu-fb.h | 6 ------
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..0acc7d6 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -555,8 +555,6 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
static int fsl_diu_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
- unsigned long htotal, vtotal;
-
pr_debug("check_var xres: %d\n", var->xres);
pr_debug("check_var yres: %d\n", var->yres);
@@ -635,20 +633,6 @@ static int fsl_diu_check_var(struct fb_var_screeninfo *var,
break;
}
- /* If the pixclock is below the minimum spec'd value then set to
- * refresh rate for 60Hz since this is supported by most monitors.
- * Refer to Documentation/fb/ for calculations.
- */
- if ((var->pixclock < MIN_PIX_CLK) || (var->pixclock > MAX_PIX_CLK)) {
- htotal = var->xres + var->right_margin + var->hsync_len +
- var->left_margin;
- vtotal = var->yres + var->lower_margin + var->vsync_len +
- var->upper_margin;
- var->pixclock = (vtotal * htotal * 6UL) / 100UL;
- var->pixclock = KHZ2PICOS(var->pixclock);
- pr_debug("pixclock set for 60Hz refresh = %u ps\n",
- var->pixclock);
- }
var->height = -1;
var->width = -1;
diff --git a/include/linux/fsl-diu-fb.h b/include/linux/fsl-diu-fb.h
index 781d467..daa9952 100644
--- a/include/linux/fsl-diu-fb.h
+++ b/include/linux/fsl-diu-fb.h
@@ -24,12 +24,6 @@
* See mpc8610fb_set_par(), map_video_memory(), and unmap_video_memory()
*/
#define MEM_ALLOC_THRESHOLD (1024*768*4+32)
-/* Minimum value that the pixel clock can be set to in pico seconds
- * This is determined by platform clock/3 where the minimum platform
- * clock is 533MHz. This gives 5629 pico seconds.
- */
-#define MIN_PIX_CLK 5629
-#define MAX_PIX_CLK 96096
#include <linux/types.h>
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] libata/sas: only set FROZEN flag if new EH is supported
From: Brian King @ 2011-06-23 20:05 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Wayne Boyer, linux-kernel, linux-ide, jgarzik, Tejun Heo, mbizon,
linuxppc-dev
In-Reply-To: <20110623171502.GA11855@us.ibm.com>
On 06/23/2011 12:15 PM, Nishanth Aravamudan wrote:
> On 23.06.2011 [14:42:00 +1000], Benjamin Herrenschmidt wrote:
>> On Thu, 2011-06-23 at 14:31 +1000, Benjamin Herrenschmidt wrote:
>>> On Tue, 2011-06-21 at 15:30 -0500, Brian King wrote:
>>>> Looks good to me. Jeff/Tejun - any issues with merging this?
>>>
>>> BTW. Current upstream with that patch applied on a machine here leads to
>>> several oddities, I don't know at this point whether any of that is
>>> actually a regression :
>>
>> Ooops... pressed "send" too quickly. Here's a log excerpt with some
>> comments:
>
> Hrm, I didn't see any of this on my box, which I thought was the same as
> yours :)
>
>> ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (April 27, 2011)
>> ipr 0000:04:00.0: Found IOA with IRQ: 129
>> ipr 0000:04:00.0: Initializing IOA.
>> ipr 0000:04:00.0: Starting IOA initialization sequence.
>> ipr 0000:04:00.0: Adapter firmware version: 04220029
>> ipr 0000:04:00.0: IOA initialized.
>> scsi0 : IBM 2B4C Storage Adapter
>> scsi 0:0:4:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
>> scsi scan: INQUIRY result too short (5), using 36
>>
>> -> Are these odd INQUIRY results expected ?
Looking at the log, my guess is that we are dealing with a zero buffer. If we were
to get an all zero buffer on the Inquiry, we would think it was a Direct-Access
device with an inquiry response buffer of 5 bytes in length.
>> scsi 0:0:5:0: Direct-Access PQ: 0 ANSI: 0
>> scsi 0:0:6:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
>> scsi 0:0:7:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
>> scsi scan: INQUIRY result too short (5), using 36
>> scsi 0:0:18:0: Direct-Access PQ: 0 ANSI: 0
I'm guessing this should really be an Enclosure device here rather than a disk,
which would be symptomatic of the all zero inquiry buffer.
>> scsi 0:2:18:0: Enclosure IBM PSBPD6E4A 3GSAS 0109 PQ: 0 ANSI: 4
>> scsi: unknown device type 31
>> scsi 0:255:255:255: No Device IBM 2B4C001SISIOA 0150 PQ: 0 ANSI: 0
>>
>> -> The above looks odd, not sure what it means
>
> The "unknown device type"? I see it all the time on lots of different
> machines.
That is normal and expected on an ipr adapter. The unknown device seen on every ipr
adapter at SCSI bus/target/lun 255:255:255 is the adapter itself. It is used by
the RAID management tools in Linux to do things like RAID configuration via SG_IO.
>
>> ipr 0000:05:00.0: Found IOA with IRQ: 130
>> ipr 0000:05:00.0: Initializing IOA.
>> scsi 0:254:0:0: Processor IBM 57CB001SISIOA 0150 PQ: 0 ANSI: 0
>> ipr 0000:05:00.0: Starting IOA initialization sequence.
>> ipr 0000:05:00.0: Adapter firmware version: 04220029
>> ipr 0000:05:00.0: IOA initialized.
>> scsi1 : IBM 57CB Storage Adapter
>> scsi scan: INQUIRY result too short (5), using 36
>> scsi 1:0:4:0: Direct-Access PQ: 0 ANSI: 0
>> scsi 1:0:5:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
>> scsi scan: INQUIRY result too short (5), using 36
>> scsi 1:0:6:0: Direct-Access PQ: 0 ANSI: 0
>> scsi 1:0:7:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
>> scsi 1:0:18:0: Enclosure IBM PSBPD6E4A 3GSAS 0109 PQ: 0 ANSI: 4
>> scsi: On host 1 channel 0 id 18 only 511 (max_scsi_report_luns) of 402653184 luns reported, try increasing max_scsi_report_luns.
>> scsi: host 1 channel 0 id 18 lun 0xc0000007f01e810f has a LUN larger than currently supported.
>>
>> -> Now that looks horribly wrong... that LUN number looks like a kernel pointer
>
> Yeah, that's weird.
>
>> scsi scan: INQUIRY result too short (5), using 36
>> scsi 1:2:18:0: Direct-Access PQ: 0 ANSI: 0
>> ata1.00: ATAPI: IBM RMBO0040532, SA61, max UDMA/100
>> ata1.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)
>> ata1.00: revalidation failed (errno=-22)
>> ata1.00: disabled
>>
>> -> So SATA works "better" with the patch but doesn't actually work properly :-)
>>
>> scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
>>
>> -> That error could give us more info... not sure what it means, we do have plenty of
>> memory...
>
> That message is sort of strange. It's not necessarily referring to
> memory allocation failing, but the port allocation failing in the SCSI
> code. And that just means an error, like the failed to IDENTIFY above,
> is occurring in the allocation path. It *can* also mean memory
> allocation failure, I think, just not in this case.
>
> I don't know much about the following errors, though, sorry.
>
> -Nish
>
>> scsi 1:8:0:0: Enclosure IBM VSBPD6E4B 3GSAS 01 PQ: 0 ANSI: 2
>> scsi: unknown device type 31
>> scsi 1:255:255:255: No Device IBM 57CB001SISIOA 0150 PQ: 0 ANSI: 0
>> work_for_cpu used greatest stack depth: 9520 bytes left
>> st: Version 20101219, fixed bufsize 32768, s/g segs 256
>> sd 0:0:4:0: [sda] 585937500 512-byte logical blocks: (300 GB/279 GiB)
>> sd 0:0:5:0: [sdb] 585937500 512-byte logical blocks: (300 GB/279 GiB)
>> sd 0:0:6:0: [sdc] 585937500 512-byte logical blocks: (300 GB/279 GiB)
>> sd 0:0:7:0: [sdd] 585937500 512-byte logical blocks: (300 GB/279 GiB)
>> sd 0:0:18:0: [sde] READ CAPACITY failed
>> sd 0:0:18:0: [sde] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
>> sd 0:0:18:0: [sde] Sense Key : Illegal Request [current]
>> sd 0:0:18:0: [sde] Add. Sense: Invalid command operation code
>>
>> -> Any idea what's up with that guy ?
If this guy is really an enclosure, this is the response you would get
on a Read Capacity.
>>
>> sd 0:0:4:0: Attached scsi generic sg0 type 0
>> sd 0:0:5:0: [sdb] Write Protect is off
>> sd 0:0:5:0: Attached scsi generic sg1 type 0
>> sd 0:0:18:0: [sde] Test WP failed, assume Write Enabled
>> sd 0:0:6:0: Attached scsi generic sg2 type 0
>> sd 0:0:18:0: [sde] Asking for cache data failed
>> sd 0:0:7:0: Attached scsi generic sg3 type 0
>> sd 0:0:18:0: [sde] Assuming drive cache: write through
>> sd 1:2:18:0: [sdj] READ CAPACITY failed
>> sd 1:2:18:0: [sdj] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
>> sd 1:2:18:0: [sdj] Sense Key : Illegal Request [current]
>> sd 1:2:18:0: [sdj] Add. Sense: Invalid command operation code
>>
>> -> And this one ?
Same here.
When did this last work on this system? It seems like this is completely
separate from the libata issue.
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] powerpc/85xx: clamp the P1022DS DIU pixel clock to allowed values
From: Timur Tabi @ 2011-06-23 19:48 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
To ensure that the DIU pixel clock will not be set to an invalid value,
clamp the PXCLK divider to the allowed range (2-255). This also acts as
a limiter for the pixel clock.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index e083e1f..266b3aa 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -195,8 +195,13 @@ void p1022ds_set_pixel_clock(unsigned int pixclock)
do_div(temp, pixclock);
freq = temp;
- /* pixclk is the ratio of the platform clock to the pixel clock */
+ /*
+ * 'pxclk' is the ratio of the platform clock to the pixel clock.
+ * This number is programmed into the CLKDVDR register, and the valid
+ * range of values is 2-255.
+ */
pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+ pxclk = clamp_t(u32, pxclk, 2, 255);
/* Disable the pixel clock, and set it to non-inverted and no delay */
clrbits32(&guts->clkdvdr,
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc/85xx: enable the framebuffer console for the defconfigs
From: Timur Tabi @ 2011-06-23 19:48 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
In-Reply-To: <1308858535-17396-1-git-send-email-timur@freescale.com>
Enable framebuffer console support by default in the defconfigs for the
Freescale 85xx-based reference board. This allows the boot messages to
be shown on the video display on the P1022DS.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/mpc85xx_defconfig | 4 ++++
arch/powerpc/configs/mpc85xx_smp_defconfig | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 96b89df..b212e3d 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -128,6 +128,10 @@ CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FB_FSL_DIU=y
# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index de65841..87fbb2e 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -130,6 +130,10 @@ CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FB_FSL_DIU=y
# CONFIG_VGA_CONSOLE is not set
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
CONFIG_SOUND=y
CONFIG_SND=y
# CONFIG_SND_SUPPORT_OLD_API is not set
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-23 17:48 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, linuxppc-dev@ozlabs.org, paulus@samba.org,
McClintock Matthew-B29882, Gala Kumar-B11780
In-Reply-To: <4E0378F4.5010501@freescale.com>
On Thu, 23 Jun 2011 12:33:40 -0500
Timur Tabi <timur@freescale.com> wrote:
> Scott Wood wrote:
> > From Power ISA 2.06B, book III-E, section 9.2.1:
> >
> > Virtualized Implementation Note:
> >
> > In virtualized implementations, TBU and TBL are
> > read-only.
>
> But does that mean that a guest should never be allowed to modify a virtualized
> timebase register, even if the hypervisor can support it?
The book3e mtspr writeup doesn't appear to specify the behavior when
writing to a read-only SPR, so perhaps you could argue that something other
than a no-op is implementation-specific behavior.
For a guest, the safe thing is to not write to those registers unless you
specifically know it's going to do what you want under a particular
implementation. It's not specifically a Topaz limitation.
> >> > So a generic HV mode bit is not going to help me, unless there's also a bit
> >> > that's specific to our hypervisor. And even then, we would need some way to
> >> > differentiate among different versions of our hypervisor, in case some future
> >> > version adds timebase support.
>
> > That's very unlikely to happen.
>
> I know. I was just being architecturally pedantic.
It's not as if it would hurt anything to ignore such a capability.
> > Ideally we would avoid doing this sync even when not running under a
> > hypervisor, as long as firmware has done the sync, and kexec hasn't messed
> > it up. Besides being a waste of boot time, the firmware's sync is
> > probably tighter since it can use a platform-specific mechanism to start all
> > the timebases at once.
>
> I agree with that, but for now, I need to work around that kexec "limitation".
Is there any way we can detect whether we booted via kexec (as opposed to
just having kexec support enabled), and only do the sync in that case?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Timur Tabi @ 2011-06-23 17:33 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@ozlabs.org, paulus@samba.org,
McClintock Matthew-B29882, Gala Kumar-B11780
In-Reply-To: <20110623122210.06ee9f55@schlenkerla.am.freescale.net>
Scott Wood wrote:
> From Power ISA 2.06B, book III-E, section 9.2.1:
>
> Virtualized Implementation Note:
>
> In virtualized implementations, TBU and TBL are
> read-only.
But does that mean that a guest should never be allowed to modify a virtualized
timebase register, even if the hypervisor can support it?
>> > So a generic HV mode bit is not going to help me, unless there's also a bit
>> > that's specific to our hypervisor. And even then, we would need some way to
>> > differentiate among different versions of our hypervisor, in case some future
>> > version adds timebase support.
> That's very unlikely to happen.
I know. I was just being architecturally pedantic.
> Ideally we would avoid doing this sync even when not running under a
> hypervisor, as long as firmware has done the sync, and kexec hasn't messed
> it up. Besides being a waste of boot time, the firmware's sync is
> probably tighter since it can use a platform-specific mechanism to start all
> the timebases at once.
I agree with that, but for now, I need to work around that kexec "limitation".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-23 17:22 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, linuxppc-dev@ozlabs.org, paulus@samba.org,
McClintock Matthew-B29882, Gala Kumar-B11780
In-Reply-To: <4E020268.2020809@freescale.com>
On Wed, 22 Jun 2011 09:55:36 -0500
Timur Tabi <timur@freescale.com> wrote:
> Kumar Gala wrote:
> >> >=20
> >> > Well, not exactly. Paul wants to break that up since we're adding so=
me
> >> > primitive support for 201 HV mode too (for 970's). Last we discussed,
> >> > the plan was to go for a generic HV mode bit and a separate bit for =
the
> >> > version.
> >> >=20
> >> > Cheers,
> >> > Ben.
>=20
> > Any ETA on Paul's intro of the FTR bit? If not I'll pull this into my =
'next' tree and we can clean up later.
>=20
> Just FYI, this particular patch is because of a limitation in the Freesca=
le
> hypervisor. It's not because we're running in guest mode. If the hyperv=
isor
> provided full emulation of the timebase register, then we wouldn't need t=
his
> patch. The same can be said of KVM or any other hypervisor.
=46rom Power ISA 2.06B, book III-E, section 9.2.1:
Virtualized Implementation Note:
In virtualized implementations, TBU and TBL are
read-only.
> So a generic HV mode bit is not going to help me, unless there's also a b=
it
> that's specific to our hypervisor. And even then, we would need some way=
to
> differentiate among different versions of our hypervisor, in case some fu=
ture
> version adds timebase support.=20
That's very unlikely to happen.
Ideally we would avoid doing this sync even when not running under a
hypervisor, as long as firmware has done the sync, and kexec hasn't messed
it up. Besides being a waste of boot time, the firmware's sync is
probably tighter since it can use a platform-specific mechanism to start all
the timebases at once.
-Scott
^ permalink raw reply
* Re: [PATCH] libata/sas: only set FROZEN flag if new EH is supported
From: Nishanth Aravamudan @ 2011-06-23 17:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, jgarzik, wayneb, linux-kernel, Tejun Heo, Brian King,
mbizon, linuxppc-dev
In-Reply-To: <1308804120.32158.202.camel@pasglop>
On 23.06.2011 [14:42:00 +1000], Benjamin Herrenschmidt wrote:
> On Thu, 2011-06-23 at 14:31 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2011-06-21 at 15:30 -0500, Brian King wrote:
> > > Looks good to me. Jeff/Tejun - any issues with merging this?
> >
> > BTW. Current upstream with that patch applied on a machine here leads to
> > several oddities, I don't know at this point whether any of that is
> > actually a regression :
>
> Ooops... pressed "send" too quickly. Here's a log excerpt with some
> comments:
Hrm, I didn't see any of this on my box, which I thought was the same as
yours :)
> ipr: IBM Power RAID SCSI Device Driver version: 2.5.2 (April 27, 2011)
> ipr 0000:04:00.0: Found IOA with IRQ: 129
> ipr 0000:04:00.0: Initializing IOA.
> ipr 0000:04:00.0: Starting IOA initialization sequence.
> ipr 0000:04:00.0: Adapter firmware version: 04220029
> ipr 0000:04:00.0: IOA initialized.
> scsi0 : IBM 2B4C Storage Adapter
> scsi 0:0:4:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
> scsi scan: INQUIRY result too short (5), using 36
>
> -> Are these odd INQUIRY results expected ?
>
> scsi 0:0:5:0: Direct-Access PQ: 0 ANSI: 0
> scsi 0:0:6:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
> scsi 0:0:7:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
> scsi scan: INQUIRY result too short (5), using 36
> scsi 0:0:18:0: Direct-Access PQ: 0 ANSI: 0
> scsi 0:2:18:0: Enclosure IBM PSBPD6E4A 3GSAS 0109 PQ: 0 ANSI: 4
> scsi: unknown device type 31
> scsi 0:255:255:255: No Device IBM 2B4C001SISIOA 0150 PQ: 0 ANSI: 0
>
> -> The above looks odd, not sure what it means
The "unknown device type"? I see it all the time on lots of different
machines.
> ipr 0000:05:00.0: Found IOA with IRQ: 130
> ipr 0000:05:00.0: Initializing IOA.
> scsi 0:254:0:0: Processor IBM 57CB001SISIOA 0150 PQ: 0 ANSI: 0
> ipr 0000:05:00.0: Starting IOA initialization sequence.
> ipr 0000:05:00.0: Adapter firmware version: 04220029
> ipr 0000:05:00.0: IOA initialized.
> scsi1 : IBM 57CB Storage Adapter
> scsi scan: INQUIRY result too short (5), using 36
> scsi 1:0:4:0: Direct-Access PQ: 0 ANSI: 0
> scsi 1:0:5:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
> scsi scan: INQUIRY result too short (5), using 36
> scsi 1:0:6:0: Direct-Access PQ: 0 ANSI: 0
> scsi 1:0:7:0: Direct-Access IBM ST9300603SS BB09 PQ: 0 ANSI: 6
> scsi 1:0:18:0: Enclosure IBM PSBPD6E4A 3GSAS 0109 PQ: 0 ANSI: 4
> scsi: On host 1 channel 0 id 18 only 511 (max_scsi_report_luns) of 402653184 luns reported, try increasing max_scsi_report_luns.
> scsi: host 1 channel 0 id 18 lun 0xc0000007f01e810f has a LUN larger than currently supported.
>
> -> Now that looks horribly wrong... that LUN number looks like a kernel pointer
Yeah, that's weird.
> scsi scan: INQUIRY result too short (5), using 36
> scsi 1:2:18:0: Direct-Access PQ: 0 ANSI: 0
> ata1.00: ATAPI: IBM RMBO0040532, SA61, max UDMA/100
> ata1.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)
> ata1.00: revalidation failed (errno=-22)
> ata1.00: disabled
>
> -> So SATA works "better" with the patch but doesn't actually work properly :-)
>
> scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
>
> -> That error could give us more info... not sure what it means, we do have plenty of
> memory...
That message is sort of strange. It's not necessarily referring to
memory allocation failing, but the port allocation failing in the SCSI
code. And that just means an error, like the failed to IDENTIFY above,
is occurring in the allocation path. It *can* also mean memory
allocation failure, I think, just not in this case.
I don't know much about the following errors, though, sorry.
-Nish
> scsi 1:8:0:0: Enclosure IBM VSBPD6E4B 3GSAS 01 PQ: 0 ANSI: 2
> scsi: unknown device type 31
> scsi 1:255:255:255: No Device IBM 57CB001SISIOA 0150 PQ: 0 ANSI: 0
> work_for_cpu used greatest stack depth: 9520 bytes left
> st: Version 20101219, fixed bufsize 32768, s/g segs 256
> sd 0:0:4:0: [sda] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 0:0:5:0: [sdb] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 0:0:6:0: [sdc] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 0:0:7:0: [sdd] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 0:0:18:0: [sde] READ CAPACITY failed
> sd 0:0:18:0: [sde] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sd 0:0:18:0: [sde] Sense Key : Illegal Request [current]
> sd 0:0:18:0: [sde] Add. Sense: Invalid command operation code
>
> -> Any idea what's up with that guy ?
>
> sd 0:0:4:0: Attached scsi generic sg0 type 0
> sd 0:0:5:0: [sdb] Write Protect is off
> sd 0:0:5:0: Attached scsi generic sg1 type 0
> sd 0:0:18:0: [sde] Test WP failed, assume Write Enabled
> sd 0:0:6:0: Attached scsi generic sg2 type 0
> sd 0:0:18:0: [sde] Asking for cache data failed
> sd 0:0:7:0: Attached scsi generic sg3 type 0
> sd 0:0:18:0: [sde] Assuming drive cache: write through
> sd 1:2:18:0: [sdj] READ CAPACITY failed
> sd 1:2:18:0: [sdj] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sd 1:2:18:0: [sdj] Sense Key : Illegal Request [current]
> sd 1:2:18:0: [sdj] Add. Sense: Invalid command operation code
>
> -> And this one ?
>
> There's more below ...
>
> sd 0:0:18:0: Attached scsi generic sg4 type 0
> sd 1:0:4:0: [sdf] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> scsi 0:2:18:0: Attached scsi generic sg5 type 13
> sd 1:0:6:0: [sdh] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> scsi 0:255:255:255: Attached scsi generic sg6 type 31
> scsi 0:254:0:0: Attached scsi generic sg7 type 3
> sd 1:0:4:0: Attached scsi generic sg8 type 0
> sd 1:2:18:0: [sdj] Test WP failed, assume Write Enabled
> sd 1:0:5:0: Attached scsi generic sg9 type 0
> sd 1:0:6:0: Attached scsi generic sg10 type 0
> sd 1:0:7:0: [sdi] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 1:2:18:0: [sdj] Asking for cache data failed
> sd 1:2:18:0: [sdj] Assuming drive cache: write through
> sd 1:0:7:0: Attached scsi generic sg11 type 0
> scsi 1:0:18:0: Attached scsi generic sg12 type 13
> sd 0:0:4:0: [sda] Write Protect is off
> sd 1:2:18:0: Attached scsi generic sg13 type 0
> sd 0:0:18:0: [sde] READ CAPACITY failed
> sd 0:0:18:0: [sde] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sd 0:0:18:0: [sde] Sense Key : Illegal Request [current]
> sd 0:0:18:0: [sde] Add. Sense: Invalid command operation code
> scsi 1:8:0:0: Attached scsi generic sg14 type 13
> scsi 1:255:255:255: Attached scsi generic sg15 type 31
> e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
> e1000: Copyright (c) 1999-2006 Intel Corporation.
> e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
> e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> sd 1:0:6:0: [sdh] Write Protect is off
> sd 0:0:5:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 0:0:18:0: [sde] Test WP failed, assume Write Enabled
> sd 0:0:7:0: [sdd] Write Protect is off
> sd 1:2:18:0: [sdj] READ CAPACITY failed
> sd 1:2:18:0: [sdj] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sd 1:2:18:0: [sdj] Sense Key : Illegal Request [current]
> sd 1:2:18:0: [sdj] Add. Sense: Invalid command operation code
> sd 0:0:18:0: [sde] Asking for cache data failed
> sd 0:0:18:0: [sde] Assuming drive cache: write through
> sd 0:0:18:0: [sde] Attached SCSI disk
> sd 1:0:5:0: [sdg] 585937500 512-byte logical blocks: (300 GB/279 GiB)
> sd 1:0:4:0: [sdf] Write Protect is off
> sd 1:2:18:0: [sdj] Test WP failed, assume Write Enabled
> sd 0:0:6:0: [sdc] Write Protect is off
> sd 1:2:18:0: [sdj] Asking for cache data failed
> sd 1:2:18:0: [sdj] Assuming drive cache: write through
> sd 1:2:18:0: [sdj] Attached SCSI disk
> sd 0:0:7:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 0:0:4:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 1:0:6:0: [sdh] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 1:0:4:0: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 1:0:5:0: [sdg] Write Protect is off
> sd 1:0:7:0: [sdi] Write Protect is off
> sd 0:0:6:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 1:0:7:0: [sdi] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sd 1:0:5:0: [sdg] Write cache: disabled, read cache: enabled, supports DPO and FUA
> sdb: unknown partition table
> sdd: unknown partition table
> sdh: unknown partition table
> sdi: unknown partition table
> sdf: [AIX] unknown partition table
> sdg: unknown partition table
> e1000e 0002:03:00.0: Disabling ASPM L1
> sdc: unknown partition table
> e1000e 0002:03:00.0: (unregistered net_device): Failed to initialize MSI interrupts. Falling back to legacy interrupts.
> scsi 1:254:0:0: Processor IBM 2B4C001SISIOA 0150 PQ: 0 ANSI: 0
> sda: [AIX] unknown partition table
> sd 0:0:5:0: [sdb] Attached SCSI disk
> sd 1:0:6:0: [sdh] Attached SCSI disk
> sd 1:0:7:0: [sdi] Attached SCSI disk
> sd 0:0:6:0: [sdc] Attached SCSI disk
> sd 1:0:5:0: [sdg] Attached SCSI disk
> sd 0:0:7:0: [sdd] Attached SCSI disk
> scsi 1:254:0:0: Attached scsi generic sg16 type 3
> sd 1:0:4:0: [sdf] Attached SCSI disk
> sd 0:0:4:0: [sda] Attached SCSI disk
>
> Cheers,
> Ben.
> >
> >
> > > Thanks,
> > >
> > > Brian
> > >
> > > On 06/21/2011 11:07 AM, Nishanth Aravamudan wrote:
> > > > Ping on this -- Tejun, Brian, Jeff, this is a pretty annoying 2.6.39
> > > > regression which it would be good to have fixed in 3.0.
> > > >
> > > > Thanks,
> > > > Nish
> > > >
> > > > On 16.06.2011 [08:28:36 -0700], Nishanth Aravamudan wrote:
> > > >> On 16.06.2011 [08:28:39 -0500], Brian King wrote:
> > > >>> On 06/16/2011 02:51 AM, Tejun Heo wrote:
> > > >>>> On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote:
> > > >>>>>> That looks like the right thing to do. For ipr's usage of
> > > >>>>>> libata, we don't have the concept of a port frozen state, so this flag
> > > >>>>>> should really never get set. The alternate way to fix this would be to
> > > >>>>>> only set ATA_PFLAG_FROZEN in ata_port_alloc if ap->ops->error_handler
> > > >>>>>> is not NULL.
> > > >>>>>
> > > >>>>> It seemed like ipr is as you say, but I wasn't sure if it was
> > > >>>>> appropriate to make the change above in the common libata-scis code or
> > > >>>>> not. I don't want to break some other device on accident.
> > > >>>>>
> > > >>>>> Also, I tried your suggestion, but I don't think that can happen in
> > > >>>>> ata_port_alloc? ata_port_alloc is allocated ap itself, and it seems like
> > > >>>>> ap->ops typically gets set only after ata_port_alloc returns?
> > > >>>>
> > > >>>> Maybe we can test error_handler in ata_sas_port_start()?
> > > >>>
> > > >>> Good point. Since libsas is converted to the new eh now, we would need to have
> > > >>> this test.
> > > >>
> > > >> Commit 7b3a24c57d2eeda8dba9c205342b12689c4679f9 ("ahci: don't enable
> > > >> port irq before handler is registered") caused a regression for CD-ROMs
> > > >> attached to the IPR SATA bus on Power machines:
> > > >>
> > > >> ata_port_alloc: ENTER
> > > >> ata_port_probe: ata1: bus probe begin
> > > >> ata1.00: ata_dev_read_id: ENTER
> > > >> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
> > > >> ata1.00: ata_dev_read_id: ENTER
> > > >> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
> > > >> ata1.00: limiting speed to UDMA7:PIO5
> > > >> ata1.00: ata_dev_read_id: ENTER
> > > >> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x40)
> > > >> ata1.00: disabled
> > > >> ata_port_probe: ata1: bus probe end
> > > >> scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
> > > >>
> > > >> The FROZEN flag added in that commit is only cleared by the new EH code,
> > > >> which is not used by ipr. Clear this flag in the SAS code if we don't
> > > >> support new EH.
> > > >>
> > > >> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > >> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > > >>
> > > >> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> > > >> index d51f979..ebe1685 100644
> > > >> --- a/drivers/ata/libata-scsi.c
> > > >> +++ b/drivers/ata/libata-scsi.c
> > > >> @@ -3797,6 +3797,12 @@ EXPORT_SYMBOL_GPL(ata_sas_port_alloc);
> > > >> */
> > > >> int ata_sas_port_start(struct ata_port *ap)
> > > >> {
> > > >> + /*
> > > >> + * the port is marked as frozen at allocation time, but if we don't
> > > >> + * have new eh, we won't thaw it
> > > >> + */
> > > >> + if (!ap->ops->error_handler)
> > > >> + ap->pflags &= ~ATA_PFLAG_FROZEN;
> > > >> return 0;
> > > >> }
> > > >> EXPORT_SYMBOL_GPL(ata_sas_port_start);
> > > >>
> > > >>
> > > >> --
> > > >> Nishanth Aravamudan <nacc@us.ibm.com>
> > > >> IBM Linux Technology Center
> > > >
> > >
> > >
> >
>
>
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 1/2] powerpc/86xx: enable the framebuffer console on the MPC8610 HPCD
From: Timur Tabi @ 2011-06-23 16:16 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Enable framebuffer console support by default in the defconfig on the
Freescale MPC8610 HPCD reference board. This allows the boot messages to
be shown on the video display.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig
index 036bfb2..0db9ba0 100644
--- a/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig
@@ -89,6 +89,11 @@ CONFIG_I2C_MPC=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FB_FSL_DIU=y
+CONFIG_VGACON_SOFT_SCROLLBACK=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_MIXER_OSS=y
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/86xx: improve calculation of DIU pixel clock on the MPC8610 HPCD
From: Timur Tabi @ 2011-06-23 16:16 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
In-Reply-To: <1308845808-11392-1-git-send-email-timur@freescale.com>
mpc8610hpcd_set_pixel_clock() calculates the correct value of the PXCLK
bits in the CLKDVDR register for a given pixel clock rate. The code which
performs this calculation is overly complicated and includes an error
estimation routine that doesn't work most of the time anyway. Replace the
code with the simpler routine that's currently used on the P1022DS.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 107 ++++++++++++---------------
1 files changed, 48 insertions(+), 59 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index a896511..74e018e 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -39,12 +39,19 @@
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/simple_gpio.h>
+#include <asm/fsl_guts.h>
#include "mpc86xx.h"
static struct device_node *pixis_node;
static unsigned char *pixis_bdcfg0, *pixis_arch;
+/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */
+#define CLKDVDR_PXCKEN 0x80000000
+#define CLKDVDR_PXCKINV 0x10000000
+#define CLKDVDR_PXCKDLY 0x06000000
+#define CLKDVDR_PXCLK_MASK 0x001F0000
+
#ifdef CONFIG_SUSPEND
static irqreturn_t mpc8610_sw9_irq(int irq, void *data)
{
@@ -205,72 +212,54 @@ void mpc8610hpcd_set_monitor_port(int monitor_port)
bdcfg[monitor_port]);
}
+/**
+ * mpc8610hpcd_set_pixel_clock: program the DIU's clock
+ *
+ * @pixclock: the wavelength, in picoseconds, of the clock
+ */
void mpc8610hpcd_set_pixel_clock(unsigned int pixclock)
{
- u32 __iomem *clkdvdr;
- u32 temp;
- /* variables for pixel clock calcs */
- ulong bestval, bestfreq, speed_ccb, minpixclock, maxpixclock;
- ulong pixval;
- long err;
- int i;
-
- clkdvdr = ioremap(get_immrbase() + 0xe0800, sizeof(u32));
- if (!clkdvdr) {
- printk(KERN_ERR "Err: can't map clock divider register!\n");
+ struct device_node *guts_np = NULL;
+ struct ccsr_guts_86xx __iomem *guts;
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, "fsl,mpc8610-guts");
+ if (!guts_np) {
+ pr_err("mpc8610hpcd: missing global utilties device node\n");
return;
}
- /* Pixel Clock configuration */
- speed_ccb = fsl_get_sys_freq();
-
- /* Calculate the pixel clock with the smallest error */
- /* calculate the following in steps to avoid overflow */
- pr_debug("DIU pixclock in ps - %d\n", pixclock);
- temp = 1000000000/pixclock;
- temp *= 1000;
- pixclock = temp;
- pr_debug("DIU pixclock freq - %u\n", pixclock);
-
- temp = pixclock * 5 / 100;
- pr_debug("deviation = %d\n", temp);
- minpixclock = pixclock - temp;
- maxpixclock = pixclock + temp;
- pr_debug("DIU minpixclock - %lu\n", minpixclock);
- pr_debug("DIU maxpixclock - %lu\n", maxpixclock);
- pixval = speed_ccb/pixclock;
- pr_debug("DIU pixval = %lu\n", pixval);
-
- err = 100000000;
- bestval = pixval;
- pr_debug("DIU bestval = %lu\n", bestval);
-
- bestfreq = 0;
- for (i = -1; i <= 1; i++) {
- temp = speed_ccb / ((pixval+i) + 1);
- pr_debug("DIU test pixval i= %d, pixval=%lu, temp freq. = %u\n",
- i, pixval, temp);
- if ((temp < minpixclock) || (temp > maxpixclock))
- pr_debug("DIU exceeds monitor range (%lu to %lu)\n",
- minpixclock, maxpixclock);
- else if (abs(temp - pixclock) < err) {
- pr_debug("Entered the else if block %d\n", i);
- err = abs(temp - pixclock);
- bestval = pixval+i;
- bestfreq = temp;
- }
+ guts = of_iomap(guts_np, 0);
+ of_node_put(guts_np);
+ if (!guts) {
+ pr_err("mpc8610hpcd: could not map global utilties device\n");
+ return;
}
- pr_debug("DIU chose = %lx\n", bestval);
- pr_debug("DIU error = %ld\n NomPixClk ", err);
- pr_debug("DIU: Best Freq = %lx\n", bestfreq);
- /* Modify PXCLK in GUTS CLKDVDR */
- pr_debug("DIU: Current value of CLKDVDR = 0x%08x\n", (*clkdvdr));
- temp = (*clkdvdr) & 0x2000FFFF;
- *clkdvdr = temp; /* turn off clock */
- *clkdvdr = temp | 0x80000000 | (((bestval) & 0x1F) << 16);
- pr_debug("DIU: Modified value of CLKDVDR = 0x%08x\n", (*clkdvdr));
- iounmap(clkdvdr);
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ /*
+ * 'pxclk' is the ratio of the platform clock to the pixel clock.
+ * On the MPC8610, the value programmed into CLKDVDR is the ratio
+ * minus one. The valid range of values is 2-31.
+ */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq) - 1;
+ pxclk = clamp_t(u32, pxclk, 2, 31);
+
+ /* Disable the pixel clock, and set it to non-inverted and no delay */
+ clrbits32(&guts->clkdvdr,
+ CLKDVDR_PXCKEN | CLKDVDR_PXCKDLY | CLKDVDR_PXCLK_MASK);
+
+ /* Enable the clock and set the pxclk */
+ setbits32(&guts->clkdvdr, CLKDVDR_PXCKEN | (pxclk << 16));
+
+ iounmap(guts);
}
ssize_t mpc8610hpcd_show_monitor_port(int monitor_port, char *buf)
--
1.7.3.4
^ permalink raw reply related
* Fwd: [PATCH] powerpc, 460gt: Add 460gt as compatible in the check for 460ex-compatible crypto
From: Mike Williams @ 2011-06-23 14:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BANLkTikKNqEoQxGA642h14eOUjZ3hGZaQw@mail.gmail.com>
On Wed, Jun 22, 2011 at 7:24 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>> - =A0 =A0 =A0 if (of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-cry=
pto")) {
>> + =A0 =A0 =A0 if (of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-cry=
pto") ||
>> + =A0 =A0 =A0 =A0 =A0 of_find_compatible_node(NULL, NULL, "amcc,ppc460gt=
-crypto")) {
>
> If the device is actually compatible, the device tree node should claim
> it is, and you do not need this code change.
That was actually my first instinct, however I tried to follow the
current convention in the glacier and canyonlands DTS files, which is
to set every device compatible to 460gt or 460ex, depending on the
processor. Many of the devices are identical between the two, since
they are variations of the same SoC, so which is the preferred method?
Follow the device tree convention and add the compatibility check in
the driver, or alter the device trees? I'll send another patch if it's
the latter.
Thanks,
Mike
>
>
> Segher
>
>
^ permalink raw reply
* Re: [PATCH] STAGING: Comedi: Build only on arches providing PAGE_KERNEL_NOCACHE
From: Kumar Gala @ 2011-06-23 12:10 UTC (permalink / raw)
To: Ralf Baechle
Cc: devel, David Howells, linux-m32r, Paul Mundt, linux-sh,
Greg Kroah-Hartman, linux-kernel, Chris Metcalf, Martyn Welch,
linux-am33-list, Paul Mackerras, linux-m32r-ja, H. Peter Anvin,
Thomas Gleixner, linux-arch, linuxppc-dev, Ingo Molnar, x86
In-Reply-To: <20110623120234.GA22524@linux-mips.org>
On Jun 23, 2011, at 7:02 AM, Ralf Baechle wrote:
> On Thu, Jun 23, 2011 at 12:53:36PM +0100, Martyn Welch wrote:
>=20
>> On 23/06/11 12:45, Ralf Baechle wrote:
>>> On architectures that don't define PAGE_KERNEL_NOCACHE, the Comedi =
driver turns
>>> into tragedy:
>>>=20
>>> CC [M] drivers/staging/comedi/drivers.o
>>> drivers/staging/comedi/drivers.c: In function =91comedi_buf_alloc=92:
>>> drivers/staging/comedi/drivers.c:505:41: error: =
=91PAGE_KERNEL_NOCACHE=92 undeclared (first use in this function)
>>> drivers/staging/comedi/drivers.c:505:41: note: each undeclared =
identifier is rep orted only once for each function it appears in
>>> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
>>>=20
>>> Restrict the driver to only those architectures that define =
PAGE_KERNEL_NOCACHE.
>>>=20
>>> PAGE_KERNEL_NOCACHE is a kludge - some system architectures such as =
SGI IP27
>>> are even uable to offer uncached operation - at least in the way an =
unwitting
>>> driver might assume. I haven't looked in details how the driver is =
using
>>> the area vmaped with PAGE_KERNEL_NOCACHE but maybe doing it =
XFS-style using
>>> cached memory and the flush_kernel_vmap_range / =
invalidate_kernel_vmap_range
>>> APIs in conjunction with the DMA API is a practical alternative.
>>>=20
>>> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>>>=20
>>> drivers/staging/comedi/Kconfig | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>=20
>>> diff --git a/drivers/staging/comedi/Kconfig =
b/drivers/staging/comedi/Kconfig
>>> index 1502d80..bccdc12 100644
>>> --- a/drivers/staging/comedi/Kconfig
>>> +++ b/drivers/staging/comedi/Kconfig
>>> @@ -2,6 +2,7 @@ config COMEDI
>>> tristate "Data acquisition support (comedi)"
>>> default N
>>> depends on m
>>> + depends on BROKEN || FRV || M32R || MN10300 || SUPERH || TILE || =
X86
>>=20
>> I'm sure I got comedi to compile on a 32-bit PPC board not that long =
ago. Has
>> something changed, or is this just not an exhaustive list?
>=20
> (Adding the PPC folks to cc.)
>=20
> A "git grep -w PAGE_KERNEL_NOCACHE arch/powerpc/" doesn't find =
anything so
> I don't think the driver will build there. I don't have a PPC =
toolchain
> to verify that.
I can verify it fails on PPC as well:
drivers/staging/comedi/drivers.c: In function 'comedi_buf_alloc':
drivers/staging/comedi/drivers.c:505:37: error: 'PAGE_KERNEL_NOCACHE' =
undeclared (first use in this function)
drivers/staging/comedi/drivers.c:505:37: note: each undeclared =
identifier is reported only once for each function it appears in
However, we do have a #define for PAGE_KERNEL_NC.
- k=
^ permalink raw reply
* Re: [PATCH] STAGING: Comedi: Build only on arches providing PAGE_KERNEL_NOCACHE
From: Ralf Baechle @ 2011-06-23 12:02 UTC (permalink / raw)
To: Martyn Welch
Cc: devel, linux-m32r-ja, linux-m32r, Paul Mundt, linux-sh,
Greg Kroah-Hartman, linux-kernel, Chris Metcalf, David Howells,
linux-am33-list, Paul Mackerras, H. Peter Anvin, Thomas Gleixner,
linux-arch, linuxppc-dev, Ingo Molnar, x86
In-Reply-To: <4E032940.5010205@ge.com>
On Thu, Jun 23, 2011 at 12:53:36PM +0100, Martyn Welch wrote:
> On 23/06/11 12:45, Ralf Baechle wrote:
> > On architectures that don't define PAGE_KERNEL_NOCACHE, the Comedi driver turns
> > into tragedy:
> >
> > CC [M] drivers/staging/comedi/drivers.o
> > drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> > drivers/staging/comedi/drivers.c:505:41: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
> > drivers/staging/comedi/drivers.c:505:41: note: each undeclared identifier is rep orted only once for each function it appears in
> > make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> >
> > Restrict the driver to only those architectures that define PAGE_KERNEL_NOCACHE.
> >
> > PAGE_KERNEL_NOCACHE is a kludge - some system architectures such as SGI IP27
> > are even uable to offer uncached operation - at least in the way an unwitting
> > driver might assume. I haven't looked in details how the driver is using
> > the area vmaped with PAGE_KERNEL_NOCACHE but maybe doing it XFS-style using
> > cached memory and the flush_kernel_vmap_range / invalidate_kernel_vmap_range
> > APIs in conjunction with the DMA API is a practical alternative.
> >
> > Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> >
> > drivers/staging/comedi/Kconfig | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
> > index 1502d80..bccdc12 100644
> > --- a/drivers/staging/comedi/Kconfig
> > +++ b/drivers/staging/comedi/Kconfig
> > @@ -2,6 +2,7 @@ config COMEDI
> > tristate "Data acquisition support (comedi)"
> > default N
> > depends on m
> > + depends on BROKEN || FRV || M32R || MN10300 || SUPERH || TILE || X86
>
> I'm sure I got comedi to compile on a 32-bit PPC board not that long ago. Has
> something changed, or is this just not an exhaustive list?
(Adding the PPC folks to cc.)
A "git grep -w PAGE_KERNEL_NOCACHE arch/powerpc/" doesn't find anything so
I don't think the driver will build there. I don't have a PPC toolchain
to verify that.
Ralf
^ permalink raw reply
* Re: [PATCH] STAGING: Comedi: Build only on arches providing PAGE_KERNEL_NOCACHE
From: Martyn Welch @ 2011-06-23 12:13 UTC (permalink / raw)
To: Ralf Baechle
Cc: devel, linux-m32r-ja, linux-m32r, Paul Mundt, linux-sh,
Greg Kroah-Hartman, linux-kernel, Chris Metcalf, David Howells,
linux-am33-list, Paul Mackerras, H. Peter Anvin, Thomas Gleixner,
linux-arch, linuxppc-dev, Ingo Molnar, x86
In-Reply-To: <20110623120234.GA22524@linux-mips.org>
On 23/06/11 13:02, Ralf Baechle wrote:
> On Thu, Jun 23, 2011 at 12:53:36PM +0100, Martyn Welch wrote:
>
>> On 23/06/11 12:45, Ralf Baechle wrote:
>>> On architectures that don't define PAGE_KERNEL_NOCACHE, the Comedi driver turns
>>> into tragedy:
>>>
>>> CC [M] drivers/staging/comedi/drivers.o
>>> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
>>> drivers/staging/comedi/drivers.c:505:41: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
>>> drivers/staging/comedi/drivers.c:505:41: note: each undeclared identifier is rep orted only once for each function it appears in
>>> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
>>>
>>> Restrict the driver to only those architectures that define PAGE_KERNEL_NOCACHE.
>>>
>>> PAGE_KERNEL_NOCACHE is a kludge - some system architectures such as SGI IP27
>>> are even uable to offer uncached operation - at least in the way an unwitting
>>> driver might assume. I haven't looked in details how the driver is using
>>> the area vmaped with PAGE_KERNEL_NOCACHE but maybe doing it XFS-style using
>>> cached memory and the flush_kernel_vmap_range / invalidate_kernel_vmap_range
>>> APIs in conjunction with the DMA API is a practical alternative.
>>>
>>> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>>>
>>> drivers/staging/comedi/Kconfig | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
>>> index 1502d80..bccdc12 100644
>>> --- a/drivers/staging/comedi/Kconfig
>>> +++ b/drivers/staging/comedi/Kconfig
>>> @@ -2,6 +2,7 @@ config COMEDI
>>> tristate "Data acquisition support (comedi)"
>>> default N
>>> depends on m
>>> + depends on BROKEN || FRV || M32R || MN10300 || SUPERH || TILE || X86
>>
>> I'm sure I got comedi to compile on a 32-bit PPC board not that long ago. Has
>> something changed, or is this just not an exhaustive list?
>
> (Adding the PPC folks to cc.)
>
> A "git grep -w PAGE_KERNEL_NOCACHE arch/powerpc/" doesn't find anything so
> I don't think the driver will build there. I don't have a PPC toolchain
> to verify that.
Ah, just found the tree looks like I had a little patch to make it seemingly
work, though it will make it "not work" for most other archs at a guess (it
may not even be right on PPC):
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index 44d6b62..263ad3d 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -505,7 +505,7 @@ int comedi_buf_alloc(struct comedi_device *dev, struct
comedi_subdevice *s,
}
if (i == n_pages) {
async->prealloc_buf =
- vmap(pages, n_pages, VM_MAP, PAGE_KERNEL_NOCACHE);
+ vmap(pages, n_pages, VM_MAP, PAGE_KERNEL_NC);
}
vfree(pages);
(Sorry for the wrapping)
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply related
* [PATCH] powerpc/85xx: Add P4080 SoC device tree include stub
From: Kumar Gala @ 2011-06-23 12:06 UTC (permalink / raw)
To: linuxppc-dev
Split out common (non-board specific) parts of the SoC related device
tree into a stub so multiple board dts files can include it and we can
reduce duplication and maintenance effort.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p4080ds.dts | 588 +--------------------------------
arch/powerpc/boot/dts/p4080si.dtsi | 661 ++++++++++++++++++++++++++++++++++++
2 files changed, 662 insertions(+), 587 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p4080si.dtsi
diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts
index 5b083bb..eb11098 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -32,7 +32,7 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-/dts-v1/;
+/include/ "p4080si.dtsi"
/ {
model = "fsl,P4080DS";
@@ -41,341 +41,12 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
- aliases {
- ccsr = &soc;
-
- serial0 = &serial0;
- serial1 = &serial1;
- serial2 = &serial2;
- serial3 = &serial3;
- pci0 = &pci0;
- pci1 = &pci1;
- pci2 = &pci2;
- usb0 = &usb0;
- usb1 = &usb1;
- dma0 = &dma0;
- dma1 = &dma1;
- sdhc = &sdhc;
- msi0 = &msi0;
- msi1 = &msi1;
- msi2 = &msi2;
-
- crypto = &crypto;
- sec_jr0 = &sec_jr0;
- sec_jr1 = &sec_jr1;
- sec_jr2 = &sec_jr2;
- sec_jr3 = &sec_jr3;
- rtic_a = &rtic_a;
- rtic_b = &rtic_b;
- rtic_c = &rtic_c;
- rtic_d = &rtic_d;
- sec_mon = &sec_mon;
-
- rio0 = &rapidio0;
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: PowerPC,4080@0 {
- device_type = "cpu";
- reg = <0>;
- next-level-cache = <&L2_0>;
- L2_0: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu1: PowerPC,4080@1 {
- device_type = "cpu";
- reg = <1>;
- next-level-cache = <&L2_1>;
- L2_1: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu2: PowerPC,4080@2 {
- device_type = "cpu";
- reg = <2>;
- next-level-cache = <&L2_2>;
- L2_2: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu3: PowerPC,4080@3 {
- device_type = "cpu";
- reg = <3>;
- next-level-cache = <&L2_3>;
- L2_3: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu4: PowerPC,4080@4 {
- device_type = "cpu";
- reg = <4>;
- next-level-cache = <&L2_4>;
- L2_4: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu5: PowerPC,4080@5 {
- device_type = "cpu";
- reg = <5>;
- next-level-cache = <&L2_5>;
- L2_5: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu6: PowerPC,4080@6 {
- device_type = "cpu";
- reg = <6>;
- next-level-cache = <&L2_6>;
- L2_6: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- cpu7: PowerPC,4080@7 {
- device_type = "cpu";
- reg = <7>;
- next-level-cache = <&L2_7>;
- L2_7: l2-cache {
- next-level-cache = <&cpc>;
- };
- };
- };
-
memory {
device_type = "memory";
};
soc: soc@ffe000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "soc";
- compatible = "simple-bus";
- ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
- reg = <0xf 0xfe000000 0 0x00001000>;
-
- soc-sram-error {
- compatible = "fsl,soc-sram-error";
- interrupts = <16 2 1 29>;
- };
-
- corenet-law@0 {
- compatible = "fsl,corenet-law";
- reg = <0x0 0x1000>;
- fsl,num-laws = <32>;
- };
-
- memory-controller@8000 {
- compatible = "fsl,qoriq-memory-controller-v4.4", "fsl,qoriq-memory-controller";
- reg = <0x8000 0x1000>;
- interrupts = <16 2 1 23>;
- };
-
- memory-controller@9000 {
- compatible = "fsl,qoriq-memory-controller-v4.4","fsl,qoriq-memory-controller";
- reg = <0x9000 0x1000>;
- interrupts = <16 2 1 22>;
- };
-
- cpc: l3-cache-controller@10000 {
- compatible = "fsl,p4080-l3-cache-controller", "cache";
- reg = <0x10000 0x1000
- 0x11000 0x1000>;
- interrupts = <16 2 1 27
- 16 2 1 26>;
- };
-
- corenet-cf@18000 {
- compatible = "fsl,corenet-cf";
- reg = <0x18000 0x1000>;
- interrupts = <16 2 1 31>;
- fsl,ccf-num-csdids = <32>;
- fsl,ccf-num-snoopids = <32>;
- };
-
- iommu@20000 {
- compatible = "fsl,pamu-v1.0", "fsl,pamu";
- reg = <0x20000 0x5000>;
- interrupts = <
- 24 2 0 0
- 16 2 1 30>;
- };
-
- mpic: pic@40000 {
- clock-frequency = <0>;
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <4>;
- reg = <0x40000 0x40000>;
- compatible = "fsl,mpic", "chrp,open-pic";
- device_type = "open-pic";
- };
-
- msi0: msi@41600 {
- compatible = "fsl,mpic-msi";
- reg = <0x41600 0x200>;
- msi-available-ranges = <0 0x100>;
- interrupts = <
- 0xe0 0 0 0
- 0xe1 0 0 0
- 0xe2 0 0 0
- 0xe3 0 0 0
- 0xe4 0 0 0
- 0xe5 0 0 0
- 0xe6 0 0 0
- 0xe7 0 0 0>;
- };
-
- msi1: msi@41800 {
- compatible = "fsl,mpic-msi";
- reg = <0x41800 0x200>;
- msi-available-ranges = <0 0x100>;
- interrupts = <
- 0xe8 0 0 0
- 0xe9 0 0 0
- 0xea 0 0 0
- 0xeb 0 0 0
- 0xec 0 0 0
- 0xed 0 0 0
- 0xee 0 0 0
- 0xef 0 0 0>;
- };
-
- msi2: msi@41a00 {
- compatible = "fsl,mpic-msi";
- reg = <0x41a00 0x200>;
- msi-available-ranges = <0 0x100>;
- interrupts = <
- 0xf0 0 0 0
- 0xf1 0 0 0
- 0xf2 0 0 0
- 0xf3 0 0 0
- 0xf4 0 0 0
- 0xf5 0 0 0
- 0xf6 0 0 0
- 0xf7 0 0 0>;
- };
-
- guts: global-utilities@e0000 {
- compatible = "fsl,qoriq-device-config-1.0";
- reg = <0xe0000 0xe00>;
- fsl,has-rstcr;
- #sleep-cells = <1>;
- fsl,liodn-bits = <12>;
- };
-
- pins: global-utilities@e0e00 {
- compatible = "fsl,qoriq-pin-control-1.0";
- reg = <0xe0e00 0x200>;
- #sleep-cells = <2>;
- };
-
- clockgen: global-utilities@e1000 {
- compatible = "fsl,p4080-clockgen", "fsl,qoriq-clockgen-1.0";
- reg = <0xe1000 0x1000>;
- clock-frequency = <0>;
- };
-
- rcpm: global-utilities@e2000 {
- compatible = "fsl,qoriq-rcpm-1.0";
- reg = <0xe2000 0x1000>;
- #sleep-cells = <1>;
- };
-
- sfp: sfp@e8000 {
- compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0";
- reg = <0xe8000 0x1000>;
- };
-
- serdes: serdes@ea000 {
- compatible = "fsl,p4080-serdes";
- reg = <0xea000 0x1000>;
- };
-
- dma0: dma@100300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
- reg = <0x100300 0x4>;
- ranges = <0x0 0x100100 0x200>;
- cell-index = <0>;
- dma-channel@0 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x0 0x80>;
- cell-index = <0>;
- interrupts = <28 2 0 0>;
- };
- dma-channel@80 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x80 0x80>;
- cell-index = <1>;
- interrupts = <29 2 0 0>;
- };
- dma-channel@100 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x100 0x80>;
- cell-index = <2>;
- interrupts = <30 2 0 0>;
- };
- dma-channel@180 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x180 0x80>;
- cell-index = <3>;
- interrupts = <31 2 0 0>;
- };
- };
-
- dma1: dma@101300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
- reg = <0x101300 0x4>;
- ranges = <0x0 0x101100 0x200>;
- cell-index = <1>;
- dma-channel@0 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x0 0x80>;
- cell-index = <0>;
- interrupts = <32 2 0 0>;
- };
- dma-channel@80 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x80 0x80>;
- cell-index = <1>;
- interrupts = <33 2 0 0>;
- };
- dma-channel@100 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x100 0x80>;
- cell-index = <2>;
- interrupts = <34 2 0 0>;
- };
- dma-channel@180 {
- compatible = "fsl,p4080-dma-channel",
- "fsl,eloplus-dma-channel";
- reg = <0x180 0x80>;
- cell-index = <3>;
- interrupts = <35 2 0 0>;
- };
- };
-
spi@110000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,p4080-espi", "fsl,mpc8536-espi";
- reg = <0x110000 0x1000>;
- interrupts = <53 0x2 0 0>;
- fsl,espi-num-chipselects = <4>;
-
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
@@ -404,33 +75,7 @@
};
};
- sdhc: sdhc@114000 {
- compatible = "fsl,p4080-esdhc", "fsl,esdhc";
- reg = <0x114000 0x1000>;
- interrupts = <48 2 0 0>;
- voltage-ranges = <3300 3300>;
- sdhci,auto-cmd12;
- clock-frequency = <0>;
- };
-
- i2c@118000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x118000 0x100>;
- interrupts = <38 2 0 0>;
- dfsrr;
- };
-
i2c@118100 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- compatible = "fsl-i2c";
- reg = <0x118100 0x100>;
- interrupts = <38 2 0 0>;
- dfsrr;
eeprom@51 {
compatible = "at24,24c256";
reg = <0x51>;
@@ -446,188 +91,23 @@
};
};
- i2c@119000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <2>;
- compatible = "fsl-i2c";
- reg = <0x119000 0x100>;
- interrupts = <39 2 0 0>;
- dfsrr;
- };
-
- i2c@119100 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <3>;
- compatible = "fsl-i2c";
- reg = <0x119100 0x100>;
- interrupts = <39 2 0 0>;
- dfsrr;
- };
-
- serial0: serial@11c500 {
- cell-index = <0>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x11c500 0x100>;
- clock-frequency = <0>;
- interrupts = <36 2 0 0>;
- };
-
- serial1: serial@11c600 {
- cell-index = <1>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x11c600 0x100>;
- clock-frequency = <0>;
- interrupts = <36 2 0 0>;
- };
-
- serial2: serial@11d500 {
- cell-index = <2>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x11d500 0x100>;
- clock-frequency = <0>;
- interrupts = <37 2 0 0>;
- };
-
- serial3: serial@11d600 {
- cell-index = <3>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x11d600 0x100>;
- clock-frequency = <0>;
- interrupts = <37 2 0 0>;
- };
-
- gpio0: gpio@130000 {
- compatible = "fsl,p4080-gpio", "fsl,qoriq-gpio";
- reg = <0x130000 0x1000>;
- interrupts = <55 2 0 0>;
- #gpio-cells = <2>;
- gpio-controller;
- };
-
usb0: usb@210000 {
- compatible = "fsl,p4080-usb2-mph",
- "fsl,mpc85xx-usb2-mph", "fsl-usb2-mph";
- reg = <0x210000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <44 0x2 0 0>;
phy_type = "ulpi";
};
usb1: usb@211000 {
- compatible = "fsl,p4080-usb2-dr",
- "fsl,mpc85xx-usb2-dr", "fsl-usb2-dr";
- reg = <0x211000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <45 0x2 0 0>;
dr_mode = "host";
phy_type = "ulpi";
};
-
- crypto: crypto@300000 {
- compatible = "fsl,sec-v4.0";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x300000 0x10000>;
- ranges = <0 0x300000 0x10000>;
- interrupt-parent = <&mpic>;
- interrupts = <92 2 0 0>;
-
- sec_jr0: jr@1000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x1000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <88 2 0 0>;
- };
-
- sec_jr1: jr@2000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x2000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <89 2 0 0>;
- };
-
- sec_jr2: jr@3000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x3000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <90 2 0 0>;
- };
-
- sec_jr3: jr@4000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x4000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <91 2 0 0>;
- };
-
- rtic@6000 {
- compatible = "fsl,sec-v4.0-rtic";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x6000 0x100>;
- ranges = <0x0 0x6100 0xe00>;
-
- rtic_a: rtic-a@0 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x00 0x20 0x100 0x80>;
- };
-
- rtic_b: rtic-b@20 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x20 0x20 0x200 0x80>;
- };
-
- rtic_c: rtic-c@40 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x40 0x20 0x300 0x80>;
- };
-
- rtic_d: rtic-d@60 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x60 0x20 0x500 0x80>;
- };
- };
- };
-
- sec_mon: sec_mon@314000 {
- compatible = "fsl,sec-v4.0-mon";
- reg = <0x314000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <93 2 0 0>;
- };
};
rapidio0: rapidio@ffe0c0000 {
- #address-cells = <2>;
- #size-cells = <2>;
- compatible = "fsl,rapidio-delta";
reg = <0xf 0xfe0c0000 0 0x20000>;
ranges = <0 0 0xc 0x20000000 0 0x01000000>;
- interrupts = <
- 16 2 1 11 /* err_irq */
- 56 2 0 0 /* bell_outb_irq */
- 57 2 0 0 /* bell_inb_irq */
- 60 2 0 0 /* msg1_tx_irq */
- 61 2 0 0 /* msg1_rx_irq */
- 62 2 0 0 /* msg2_tx_irq */
- 63 2 0 0>; /* msg2_rx_irq */
};
localbus@ffe124000 {
- compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
reg = <0xf 0xfe124000 0 0x1000>;
- interrupts = <25 2 0 0>;
- #address-cells = <2>;
- #size-cells = <1>;
-
ranges = <0 0 0xf 0xe8000000 0x08000000>;
flash@0,0 {
@@ -639,32 +119,10 @@
};
pci0: pcie@ffe200000 {
- compatible = "fsl,p4080-pcie";
- device_type = "pci";
- #size-cells = <2>;
- #address-cells = <3>;
reg = <0xf 0xfe200000 0 0x1000>;
- bus-range = <0x0 0xff>;
ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
- clock-frequency = <0x1fca055>;
- fsl,msi = <&msi0>;
- interrupts = <16 2 1 15>;
pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- interrupts = <16 2 1 15>;
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 40 1 0 0
- 0000 0 0 2 &mpic 1 1 0 0
- 0000 0 0 3 &mpic 2 1 0 0
- 0000 0 0 4 &mpic 3 1 0 0
- >;
ranges = <0x02000000 0 0xe0000000
0x02000000 0 0xe0000000
0 0x20000000
@@ -676,32 +134,10 @@
};
pci1: pcie@ffe201000 {
- compatible = "fsl,p4080-pcie";
- device_type = "pci";
- #size-cells = <2>;
- #address-cells = <3>;
reg = <0xf 0xfe201000 0 0x1000>;
- bus-range = <0 0xff>;
ranges = <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
- clock-frequency = <0x1fca055>;
- fsl,msi = <&msi1>;
- interrupts = <16 2 1 14>;
pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- interrupts = <16 2 1 14>;
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 41 1 0 0
- 0000 0 0 2 &mpic 5 1 0 0
- 0000 0 0 3 &mpic 6 1 0 0
- 0000 0 0 4 &mpic 7 1 0 0
- >;
ranges = <0x02000000 0 0xe0000000
0x02000000 0 0xe0000000
0 0x20000000
@@ -713,32 +149,10 @@
};
pci2: pcie@ffe202000 {
- compatible = "fsl,p4080-pcie";
- device_type = "pci";
- #size-cells = <2>;
- #address-cells = <3>;
reg = <0xf 0xfe202000 0 0x1000>;
- bus-range = <0x0 0xff>;
ranges = <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x20000000
0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
- clock-frequency = <0x1fca055>;
- fsl,msi = <&msi2>;
- interrupts = <16 2 1 13>;
pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- interrupts = <16 2 1 13>;
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 42 1 0 0
- 0000 0 0 2 &mpic 9 1 0 0
- 0000 0 0 3 &mpic 10 1 0 0
- 0000 0 0 4 &mpic 11 1 0 0
- >;
ranges = <0x02000000 0 0xe0000000
0x02000000 0 0xe0000000
0 0x20000000
diff --git a/arch/powerpc/boot/dts/p4080si.dtsi b/arch/powerpc/boot/dts/p4080si.dtsi
new file mode 100644
index 0000000..b71051f
--- /dev/null
+++ b/arch/powerpc/boot/dts/p4080si.dtsi
@@ -0,0 +1,661 @@
+/*
+ * P4080 Silicon Device Tree Source
+ *
+ * Copyright 2009-2011 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.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "fsl,P4080";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ ccsr = &soc;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ dma0 = &dma0;
+ dma1 = &dma1;
+ sdhc = &sdhc;
+ msi0 = &msi0;
+ msi1 = &msi1;
+ msi2 = &msi2;
+
+ crypto = &crypto;
+ sec_jr0 = &sec_jr0;
+ sec_jr1 = &sec_jr1;
+ sec_jr2 = &sec_jr2;
+ sec_jr3 = &sec_jr3;
+ rtic_a = &rtic_a;
+ rtic_b = &rtic_b;
+ rtic_c = &rtic_c;
+ rtic_d = &rtic_d;
+ sec_mon = &sec_mon;
+
+ rio0 = &rapidio0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,4080@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu1: PowerPC,4080@1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu2: PowerPC,4080@2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <&L2_2>;
+ L2_2: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu3: PowerPC,4080@3 {
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <&L2_3>;
+ L2_3: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu4: PowerPC,4080@4 {
+ device_type = "cpu";
+ reg = <4>;
+ next-level-cache = <&L2_4>;
+ L2_4: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu5: PowerPC,4080@5 {
+ device_type = "cpu";
+ reg = <5>;
+ next-level-cache = <&L2_5>;
+ L2_5: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu6: PowerPC,4080@6 {
+ device_type = "cpu";
+ reg = <6>;
+ next-level-cache = <&L2_6>;
+ L2_6: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu7: PowerPC,4080@7 {
+ device_type = "cpu";
+ reg = <7>;
+ next-level-cache = <&L2_7>;
+ L2_7: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ };
+
+ soc: soc@ffe000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ soc-sram-error {
+ compatible = "fsl,soc-sram-error";
+ interrupts = <16 2 1 29>;
+ };
+
+ corenet-law@0 {
+ compatible = "fsl,corenet-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <32>;
+ };
+
+ memory-controller@8000 {
+ compatible = "fsl,qoriq-memory-controller-v4.4", "fsl,qoriq-memory-controller";
+ reg = <0x8000 0x1000>;
+ interrupts = <16 2 1 23>;
+ };
+
+ memory-controller@9000 {
+ compatible = "fsl,qoriq-memory-controller-v4.4","fsl,qoriq-memory-controller";
+ reg = <0x9000 0x1000>;
+ interrupts = <16 2 1 22>;
+ };
+
+ cpc: l3-cache-controller@10000 {
+ compatible = "fsl,p4080-l3-cache-controller", "cache";
+ reg = <0x10000 0x1000
+ 0x11000 0x1000>;
+ interrupts = <16 2 1 27
+ 16 2 1 26>;
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet-cf";
+ reg = <0x18000 0x1000>;
+ interrupts = <16 2 1 31>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
+
+ iommu@20000 {
+ compatible = "fsl,pamu-v1.0", "fsl,pamu";
+ reg = <0x20000 0x5000>;
+ interrupts = <
+ 24 2 0 0
+ 16 2 1 30>;
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <4>;
+ reg = <0x40000 0x40000>;
+ compatible = "fsl,mpic", "chrp,open-pic";
+ device_type = "open-pic";
+ };
+
+ msi0: msi@41600 {
+ compatible = "fsl,mpic-msi";
+ reg = <0x41600 0x200>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0 0 0
+ 0xe1 0 0 0
+ 0xe2 0 0 0
+ 0xe3 0 0 0
+ 0xe4 0 0 0
+ 0xe5 0 0 0
+ 0xe6 0 0 0
+ 0xe7 0 0 0>;
+ };
+
+ msi1: msi@41800 {
+ compatible = "fsl,mpic-msi";
+ reg = <0x41800 0x200>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe8 0 0 0
+ 0xe9 0 0 0
+ 0xea 0 0 0
+ 0xeb 0 0 0
+ 0xec 0 0 0
+ 0xed 0 0 0
+ 0xee 0 0 0
+ 0xef 0 0 0>;
+ };
+
+ msi2: msi@41a00 {
+ compatible = "fsl,mpic-msi";
+ reg = <0x41a00 0x200>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xf0 0 0 0
+ 0xf1 0 0 0
+ 0xf2 0 0 0
+ 0xf3 0 0 0
+ 0xf4 0 0 0
+ 0xf5 0 0 0
+ 0xf6 0 0 0
+ 0xf7 0 0 0>;
+ };
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,qoriq-device-config-1.0";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ #sleep-cells = <1>;
+ fsl,liodn-bits = <12>;
+ };
+
+ pins: global-utilities@e0e00 {
+ compatible = "fsl,qoriq-pin-control-1.0";
+ reg = <0xe0e00 0x200>;
+ #sleep-cells = <2>;
+ };
+
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,p4080-clockgen", "fsl,qoriq-clockgen-1.0";
+ reg = <0xe1000 0x1000>;
+ clock-frequency = <0>;
+ };
+
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ #sleep-cells = <1>;
+ };
+
+ sfp: sfp@e8000 {
+ compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0";
+ reg = <0xe8000 0x1000>;
+ };
+
+ serdes: serdes@ea000 {
+ compatible = "fsl,p4080-serdes";
+ reg = <0xea000 0x1000>;
+ };
+
+ dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
+ reg = <0x100300 0x4>;
+ ranges = <0x0 0x100100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <31 2 0 0>;
+ };
+ };
+
+ dma1: dma@101300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
+ reg = <0x101300 0x4>;
+ ranges = <0x0 0x101100 0x200>;
+ cell-index = <1>;
+ dma-channel@0 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupts = <32 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <33 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <34 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <35 2 0 0>;
+ };
+ };
+
+ spi@110000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,p4080-espi", "fsl,mpc8536-espi";
+ reg = <0x110000 0x1000>;
+ interrupts = <53 0x2 0 0>;
+ fsl,espi-num-chipselects = <4>;
+ };
+
+ sdhc: sdhc@114000 {
+ compatible = "fsl,p4080-esdhc", "fsl,esdhc";
+ reg = <0x114000 0x1000>;
+ interrupts = <48 2 0 0>;
+ voltage-ranges = <3300 3300>;
+ sdhci,auto-cmd12;
+ clock-frequency = <0>;
+ };
+
+ i2c@118000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x118000 0x100>;
+ interrupts = <38 2 0 0>;
+ dfsrr;
+ };
+
+ i2c@118100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x118100 0x100>;
+ interrupts = <38 2 0 0>;
+ dfsrr;
+ };
+
+ i2c@119000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <2>;
+ compatible = "fsl-i2c";
+ reg = <0x119000 0x100>;
+ interrupts = <39 2 0 0>;
+ dfsrr;
+ };
+
+ i2c@119100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <3>;
+ compatible = "fsl-i2c";
+ reg = <0x119100 0x100>;
+ interrupts = <39 2 0 0>;
+ dfsrr;
+ };
+
+ serial0: serial@11c500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11c500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <36 2 0 0>;
+ };
+
+ serial1: serial@11c600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11c600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <36 2 0 0>;
+ };
+
+ serial2: serial@11d500 {
+ cell-index = <2>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11d500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <37 2 0 0>;
+ };
+
+ serial3: serial@11d600 {
+ cell-index = <3>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11d600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <37 2 0 0>;
+ };
+
+ gpio0: gpio@130000 {
+ compatible = "fsl,p4080-gpio", "fsl,qoriq-gpio";
+ reg = <0x130000 0x1000>;
+ interrupts = <55 2 0 0>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ usb0: usb@210000 {
+ compatible = "fsl,p4080-usb2-mph",
+ "fsl,mpc85xx-usb2-mph", "fsl-usb2-mph";
+ reg = <0x210000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <44 0x2 0 0>;
+ };
+
+ usb1: usb@211000 {
+ compatible = "fsl,p4080-usb2-dr",
+ "fsl,mpc85xx-usb2-dr", "fsl-usb2-dr";
+ reg = <0x211000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <45 0x2 0 0>;
+ };
+
+ crypto: crypto@300000 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x300000 0x10000>;
+ ranges = <0 0x300000 0x10000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <92 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <88 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <89 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <90 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <91 2 0 0>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x80>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x80>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20 0x300 0x80>;
+ };
+
+ rtic_d: rtic-d@60 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x60 0x20 0x500 0x80>;
+ };
+ };
+ };
+
+ sec_mon: sec_mon@314000 {
+ compatible = "fsl,sec-v4.0-mon";
+ reg = <0x314000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <93 2 0 0>;
+ };
+ };
+
+ rapidio0: rapidio@ffe0c0000 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "fsl,rapidio-delta";
+ interrupts = <
+ 16 2 1 11 /* err_irq */
+ 56 2 0 0 /* bell_outb_irq */
+ 57 2 0 0 /* bell_inb_irq */
+ 60 2 0 0 /* msg1_tx_irq */
+ 61 2 0 0 /* msg1_rx_irq */
+ 62 2 0 0 /* msg2_tx_irq */
+ 63 2 0 0>; /* msg2_rx_irq */
+ };
+
+ localbus@ffe124000 {
+ compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
+ interrupts = <25 2 0 0>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ };
+
+ pci0: pcie@ffe200000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ clock-frequency = <0x1fca055>;
+ fsl,msi = <&msi0>;
+ interrupts = <16 2 1 15>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 1 15>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 40 1 0 0
+ 0000 0 0 2 &mpic 1 1 0 0
+ 0000 0 0 3 &mpic 2 1 0 0
+ 0000 0 0 4 &mpic 3 1 0 0
+ >;
+ };
+ };
+
+ pci1: pcie@ffe201000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 0xff>;
+ clock-frequency = <0x1fca055>;
+ fsl,msi = <&msi1>;
+ interrupts = <16 2 1 14>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 1 14>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 41 1 0 0
+ 0000 0 0 2 &mpic 5 1 0 0
+ 0000 0 0 3 &mpic 6 1 0 0
+ 0000 0 0 4 &mpic 7 1 0 0
+ >;
+ };
+ };
+
+ pci2: pcie@ffe202000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ clock-frequency = <0x1fca055>;
+ fsl,msi = <&msi2>;
+ interrupts = <16 2 1 13>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 1 13>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 42 1 0 0
+ 0000 0 0 2 &mpic 9 1 0 0
+ 0000 0 0 3 &mpic 10 1 0 0
+ 0000 0 0 4 &mpic 11 1 0 0
+ >;
+ };
+ };
+};
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] fsl-diu-fb: remove the ioctl interface
From: Anatolij Gustschin @ 2011-06-23 11:39 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org
In-Reply-To: <4E0323A5.7080706@freescale.com>
On Thu, 23 Jun 2011 11:29:42 +0000
Tabi Timur-B04825 <B04825@freescale.com> wrote:
...
> > test-app:http://pastebin.com/J2RvKb6n
>
> What's the "VIU"?
Video-IN unit on mpc5121e (for capturing ITU656 video stream data).
^ permalink raw reply
* [PATCH v3 3/3] powerpc: Dont require a dma_ops struct to set dma mask
From: Kumar Gala @ 2011-06-23 11:33 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1308828839-27349-2-git-send-email-galak@kernel.crashing.org>
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask. If not we can fall back to setting the mask
directly.
This resolves an issue with how to sequence the setting of a DMA mask
for platform devices. Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).
So now we can do:
pdev = platform_device_alloc("foobar", 0);
dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
platform_device_add(pdev);
And expect the right thing to happen with the bus notifiers get called
via platform_device_add.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v3: Fixed commit comment to use platform_device_add()
arch/powerpc/kernel/dma.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index d238c08..4f0959f 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -161,9 +161,7 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
if (ppc_md.dma_set_mask)
return ppc_md.dma_set_mask(dev, dma_mask);
- if (unlikely(dma_ops == NULL))
- return -EIO;
- if (dma_ops->set_dma_mask != NULL)
+ if ((dma_ops != NULL) && (dma_ops->set_dma_mask != NULL))
return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
From: Kumar Gala @ 2011-06-23 11:33 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1308744176-24491-1-git-send-email-galak@kernel.crashing.org>
On some architectures we need to setup pdev_archdata before we add the
device. Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier. One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.
We add noop version of arch_setup_pdev_archdata() in
<asm-generic/platform_device.h> and allow the arch code to override with
access the full definitions of struct device, struct platform_device, and
struct pdev_archdata.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v3:
* Add more comments and add missing call to arch_setup_pdev_archdata in
platform_device_register
v2:
* Added license, and comments about arch_setup_pdev_archdata()
per Mike's comments
arch/alpha/include/asm/platform_device.h | 1 +
arch/arm/include/asm/platform_device.h | 1 +
arch/avr32/include/asm/platform_device.h | 1 +
arch/blackfin/include/asm/platform_device.h | 1 +
arch/cris/include/asm/platform_device.h | 1 +
arch/frv/include/asm/platform_device.h | 1 +
arch/h8300/include/asm/platform_device.h | 1 +
arch/ia64/include/asm/platform_device.h | 1 +
arch/m32r/include/asm/platform_device.h | 1 +
arch/m68k/include/asm/platform_device.h | 1 +
arch/microblaze/include/asm/platform_device.h | 1 +
arch/mips/include/asm/platform_device.h | 1 +
arch/mn10300/include/asm/platform_device.h | 1 +
arch/parisc/include/asm/platform_device.h | 1 +
arch/powerpc/include/asm/platform_device.h | 1 +
arch/s390/include/asm/platform_device.h | 1 +
arch/score/include/asm/platform_device.h | 1 +
arch/sh/include/asm/platform_device.h | 1 +
arch/sparc/include/asm/platform_device.h | 1 +
arch/tile/include/asm/platform_device.h | 1 +
arch/unicore32/include/asm/platform_device.h | 1 +
arch/x86/include/asm/platform_device.h | 1 +
arch/xtensa/include/asm/platform_device.h | 1 +
drivers/base/platform.c | 3 ++
include/asm-generic/platform_device.h | 41 +++++++++++++++++++++++++
25 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 arch/alpha/include/asm/platform_device.h
create mode 100644 arch/arm/include/asm/platform_device.h
create mode 100644 arch/avr32/include/asm/platform_device.h
create mode 100644 arch/blackfin/include/asm/platform_device.h
create mode 100644 arch/cris/include/asm/platform_device.h
create mode 100644 arch/frv/include/asm/platform_device.h
create mode 100644 arch/h8300/include/asm/platform_device.h
create mode 100644 arch/ia64/include/asm/platform_device.h
create mode 100644 arch/m32r/include/asm/platform_device.h
create mode 100644 arch/m68k/include/asm/platform_device.h
create mode 100644 arch/microblaze/include/asm/platform_device.h
create mode 100644 arch/mips/include/asm/platform_device.h
create mode 100644 arch/mn10300/include/asm/platform_device.h
create mode 100644 arch/parisc/include/asm/platform_device.h
create mode 100644 arch/powerpc/include/asm/platform_device.h
create mode 100644 arch/s390/include/asm/platform_device.h
create mode 100644 arch/score/include/asm/platform_device.h
create mode 100644 arch/sh/include/asm/platform_device.h
create mode 100644 arch/sparc/include/asm/platform_device.h
create mode 100644 arch/tile/include/asm/platform_device.h
create mode 100644 arch/unicore32/include/asm/platform_device.h
create mode 100644 arch/x86/include/asm/platform_device.h
create mode 100644 arch/xtensa/include/asm/platform_device.h
create mode 100644 include/asm-generic/platform_device.h
diff --git a/arch/alpha/include/asm/platform_device.h b/arch/alpha/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/alpha/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/arm/include/asm/platform_device.h b/arch/arm/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/arm/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/avr32/include/asm/platform_device.h b/arch/avr32/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/avr32/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/blackfin/include/asm/platform_device.h b/arch/blackfin/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/blackfin/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/cris/include/asm/platform_device.h b/arch/cris/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/cris/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/frv/include/asm/platform_device.h b/arch/frv/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/frv/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/h8300/include/asm/platform_device.h b/arch/h8300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/h8300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/ia64/include/asm/platform_device.h b/arch/ia64/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/ia64/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m32r/include/asm/platform_device.h b/arch/m32r/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m32r/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/m68k/include/asm/platform_device.h b/arch/m68k/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/m68k/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/microblaze/include/asm/platform_device.h b/arch/microblaze/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/microblaze/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mips/include/asm/platform_device.h b/arch/mips/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mips/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/mn10300/include/asm/platform_device.h b/arch/mn10300/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/mn10300/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/parisc/include/asm/platform_device.h b/arch/parisc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/parisc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/powerpc/include/asm/platform_device.h b/arch/powerpc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/powerpc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/s390/include/asm/platform_device.h b/arch/s390/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/s390/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/score/include/asm/platform_device.h b/arch/score/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/score/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sh/include/asm/platform_device.h b/arch/sh/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sh/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/sparc/include/asm/platform_device.h b/arch/sparc/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/sparc/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/tile/include/asm/platform_device.h b/arch/tile/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/tile/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/unicore32/include/asm/platform_device.h b/arch/unicore32/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/unicore32/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/x86/include/asm/platform_device.h b/arch/x86/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/x86/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/arch/xtensa/include/asm/platform_device.h b/arch/xtensa/include/asm/platform_device.h
new file mode 100644
index 0000000..01452c3
--- /dev/null
+++ b/arch/xtensa/include/asm/platform_device.h
@@ -0,0 +1 @@
+#include <asm-generic/platform_device.h>
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 1c291af..f554045 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/pm_runtime.h>
+#include <asm/platform_device.h>
#include "base.h"
@@ -173,6 +174,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
+ arch_setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
@@ -334,6 +336,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
int platform_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
+ arch_setup_pdev_archdata(pdev);
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
diff --git a/include/asm-generic/platform_device.h b/include/asm-generic/platform_device.h
new file mode 100644
index 0000000..c03570c
--- /dev/null
+++ b/include/asm-generic/platform_device.h
@@ -0,0 +1,41 @@
+/*
+ * include/asm-generic/platform_device.h
+ *
+ * Provides a callout when we allocate a platform device to architecture code
+ * to update archdata.
+ *
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * You should have received a copy of the GNU General Public License
+ * (for example /usr/src/linux/COPYING); if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#ifndef __ASM_GENERIC_PLATFORM_DEVICE_H_
+#define __ASM_GENERIC_PLATFORM_DEVICE_H_
+
+struct platform_device;
+
+/*
+ * an architecture can override to define arch_setup_pdev_archdata
+ *
+ * This is called before platform_device_add() such that any pdev_archdata may
+ * be setup before the platform_notifier is called. So if a user needs to
+ * manipulate any relevant information in the pdev_archdata they can do:
+ *
+ * platform_devic_alloc()
+ * ... manipulate ...
+ * platform_device_add()
+ *
+ * And if they don't care they can just call platform_device_register() and
+ * everything will just work out.
+ */
+#ifndef arch_setup_pdev_archdata
+static inline void arch_setup_pdev_archdata(struct platform_device *pdev) { }
+#endif
+
+#endif /* __ASM_GENERIC_PLATFORM_DEVICE_H_ */
--
1.7.3.4
^ permalink raw reply related
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