* linux-next: scsi tree build failure
From: Stephen Rothwell @ 2008-07-07 12:25 UTC (permalink / raw)
To: James Bottomley; +Cc: linuxppc-dev, linux-next, Paul Mackerras
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
Hi James,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'map_sg_data':
drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: (Each undeclared identifier is reported only once
drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: for each function it appears in.)
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_queuecommand':
drivers/scsi/ibmvscsi/ibmvscsi.c:750: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'send_mad_adapter_info':
drivers/scsi/ibmvscsi/ibmvscsi.c:864: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_do_host_config':
drivers/scsi/ibmvscsi/ibmvscsi.c:1412: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
drivers/scsi/ibmvscsi/ibmvscsi.c: At top level:
drivers/scsi/ibmvscsi/ibmvscsi.c:1769: error: unknown field 'get_io_entitlement' specified in initializer
drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: missing braces around initializer
drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: (near initialization for 'ibmvscsi_driver.driver')
drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: initialization from incompatible pointer type
Caused because commit 341b56db6804040aa9559e913865108424e3b18b ("[SCSI]
ibmvscsi: driver enablement for CMO"), which was 15/16 in a series, has
been merged before any of the other patches in the series. I have
reverted that commit.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: MPC52xx generic DMA using bestcomm
From: Matt Sealey @ 2008-07-07 12:47 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <4871E487.2020008@matrix-vision.de>
Andre Schwarz wrote:
> Grant,
I know I'm not Grant, but..
> do you know if someone's working on a more generic DMA solution using
> BestComm engine on 5200B ?
> Maybe somthing that accepts a sg-list with callback ops or completion ?
It was suggested once or twice, not least by me.
> Is it possible right now to accelerate simple memcpy ops ?
From my discussions on the subject with Sylvain, it's possible, you just
need to use the GenBD and initiate it manually, however it's probably more
overhead than work if the data size is small, and BestComm would do better
to copy full 32-bit words at a time, and stay aligned, if you have an odd-sized
transfer from a non-32-bit aligned address, then you may have to do some
incredible amount of work which makes the actual transfer not worth doing
(by the time you set it up, the CPU could have copied it on it's own
already, I guess what you DO gain is a kernel preemption point.. the CPU
can do other things that are important)
I for one, though, whether it speeds stuff up or not, love to see this in
action and am very willing to test and benchmark it. I would love to see
more users, too, as the network stack is not the only system that can
benefit..
On a related note does anyone know of the status or what is going on with
Clifford Wolf's dmatransfer API?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Sam Ravnborg @ 2008-07-07 12:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next, Paul Mackerras
In-Reply-To: <20080707184038.aaeb8d40.sfr@canb.auug.org.au>
On Mon, Jul 07, 2008 at 06:40:38PM +1000, Stephen Rothwell wrote:
> Hi Sam,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
>
> This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
> (line 194).
>
> From include/asm-powerpc/pgtable-ppc64.h:
>
> #define REGION_SHIFT 60UL
> #define REGION_MASK (0xfUL << REGION_SHIFT)
> #define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT)
>
> #define VMALLOC_REGION_ID (REGION_ID(VMALLOC_START))
> #define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET))
> #define VMEMMAP_REGION_ID (0xfUL)
> #define USER_REGION_ID (0UL)
>
> From include/asm-powerpc/page.h:
>
> #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
>
> From .config:
>
> CONFIG_PAGE_OFFSET=0xffffffff
>
> Not good.
>
> From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):
>
> config PAGE_OFFSET_BOOL
> bool "Set custom page offset address"
> depends on ADVANCED_OPTIONS
>
> config PAGE_OFFSET
> hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
> default "0xc0000000"
>
> if PPC64
> config PAGE_OFFSET
> hex
> default "0xc000000000000000"
> endif
>
> Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
> normalize int/hex values") seems to have fixed it.
>
> From .config:
>
> CONFIG_PAGE_OFFSET=0xc000000000000000
I see what is wrong - we use a int to hold the value above
and it does not fit.
Will fix tonight or tomorrow.
Sam
^ permalink raw reply
* linux-next: manual merge of the powerpc tree
From: Stephen Rothwell @ 2008-07-07 13:07 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: Daniel Walker, Morton, linux-next, Andrew,
Bartlomiej Zolnierkiewicz
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in
drivers/macintosh/mediabay.c between commit
7ad963b103d3863b1161c59f3e65a435979804ed ("ide-pmac: media-bay support
fixes (take 4)") from the ide tree and commit
9a24729d8aeef967eac7af71c6a69edc83d06558 ("macintosh/media bay: Convert
semaphore to mutex") from the powerpc tree.
I just applied the up/down -> mutex_unlock/mutex_lock change to the ide
tree version.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Stephen Rothwell @ 2008-07-07 13:08 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Paul, linux-next, Mackerras
In-Reply-To: <20080707125138.GA16569@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Hi Sam,
On Mon, 7 Jul 2008 14:51:38 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I see what is wrong - we use a int to hold the value above
> and it does not fit.
>
> Will fix tonight or tomorrow.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Josh Boyer @ 2008-07-07 13:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40807032351l631febe2h8d38a9eed1053b6b@mail.gmail.com>
On Fri, 4 Jul 2008 00:51:44 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> Anyone had a chance to look at this? I think this could be used to
> eliminate a lot of the platform specific default targets in
> arch/powerpc/boot/Makefile by moving them into the defconfigs. Josh,
> Kumar, what are your thoughts?
So for cases like Kilauea/Haleakala or Bamboo/Yosemite, you would
specify Yosemite in the bamboo defconfig? Or?
I actually sort of prefer having a separate defconfig/CONFIG_YOSEMITE
(as an example) because it's much easier for an end user to figure out
if the board is supported or not.
I could be totally misunderstanding the intention of this patch though,
so I'll stop rambling and wait to see what the use case is.
josh
^ permalink raw reply
* Re: [alsa-devel] [PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Jon Smirl @ 2008-07-07 13:23 UTC (permalink / raw)
To: Grant Likely, liam.girdwood, alsa-devel, linuxppc-dev, timur
In-Reply-To: <20080707105905.GA19240@rakim.wolfsonmicro.main>
On 7/7/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Jul 06, 2008 at 01:56:48PM -0400, Jon Smirl wrote:
>
> > The driver is assuming a capture stream exists. My codec is output only.
>
>
> While the driver declares a capture stream the core doesn't require that
> both capture and playback be available - it will cope with a capture
> only or a playback only DAI (this is fairly common due to DAC only and
> ADC only parts). Unless there's some other issue specific to this
> driver?
Yes, it GPFs allocating a a DMA buffer on the null capture stream pointer.
>
> > I'm using external clocking, but the driver should support using the
> > mpc5200 for clocking. That's a little complicated since you have to
> > compute the divisors. For example the Phytec pcm030 board has a
> > 33.3333Mhz xtal and runs at 400Mhz.
>
>
> This is desirable, though it shouldn't be an obstacle for merging if the
> driver only supports running in slave mode.
>
>
> > In order to reduce options, can the psc-i2s driver always try to use
> > mpc5200 clocking, then let the codec or fabric driver override it?
>
>
> The clocking should always be under the control of the machine driver
> with the codec and platform drivers exporting the required dividers and
> PLLs/FLLs. Neither the platform driver nor the codec driver are really
> in a position to know how a given board is wired up and what
> interdependencies or external requirements there are.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Grant Likely @ 2008-07-07 13:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707091818.72d584fe@zod.rchland.ibm.com>
On Mon, Jul 7, 2008 at 7:18 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 4 Jul 2008 00:51:44 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> Anyone had a chance to look at this? I think this could be used to
>> eliminate a lot of the platform specific default targets in
>> arch/powerpc/boot/Makefile by moving them into the defconfigs. Josh,
>> Kumar, what are your thoughts?
>
> So for cases like Kilauea/Haleakala or Bamboo/Yosemite, you would
> specify Yosemite in the bamboo defconfig? Or?
If they share a defconfig, then yes, that is what I'm thinking about...
> I actually sort of prefer having a separate defconfig/CONFIG_YOSEMITE
> (as an example) because it's much easier for an end user to figure out
> if the board is supported or not.
...however, these don't have to disappear if you prefer them.
> I could be totally misunderstanding the intention of this patch though,
> so I'll stop rambling and wait to see what the use case is.
Specifically the case I'm thinking of is when a user of a Xilinx FPGA
drops a new .dts file into arch/powerpc/boot/dts (say
'super-sexy-platform.dts'). However, instead of modifying the
Makefile or always typing 'make simpleImage.super-sexy-platform', then
can add 'simpleImage.super-sexy-platform' to their defconfig which I
can see being easier for someone to get their head around.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: MPC52xx generic DMA using bestcomm
From: Grant Likely @ 2008-07-07 13:36 UTC (permalink / raw)
To: Matt Sealey; +Cc: Andre Schwarz, linux-ppc list
In-Reply-To: <4872104E.6050109@genesi-usa.com>
On Mon, Jul 7, 2008 at 6:47 AM, Matt Sealey <matt@genesi-usa.com> wrote:
>
>
> Andre Schwarz wrote:
>>
>> Grant,
>
> I know I'm not Grant, but..
... I agree 100% with your reply and have nothing additional to add. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: MPC52xx generic DMA using bestcomm
From: Jon Smirl @ 2008-07-07 13:39 UTC (permalink / raw)
To: Matt Sealey; +Cc: Andre Schwarz, linux-ppc list
In-Reply-To: <4872104E.6050109@genesi-usa.com>
On 7/7/08, Matt Sealey <matt@genesi-usa.com> wrote:
>
>
> Andre Schwarz wrote:
>
> > Grant,
> >
>
> I know I'm not Grant, but..
>
>
> > do you know if someone's working on a more generic DMA solution using
> > BestComm engine on 5200B ?
> > Maybe somthing that accepts a sg-list with callback ops or completion ?
> >
>
> It was suggested once or twice, not least by me.
>
>
> > Is it possible right now to accelerate simple memcpy ops ?
> >
>
> From my discussions on the subject with Sylvain, it's possible, you just
> need to use the GenBD and initiate it manually, however it's probably more
> overhead than work if the data size is small, and BestComm would do better
> to copy full 32-bit words at a time, and stay aligned, if you have an
> odd-sized
> transfer from a non-32-bit aligned address, then you may have to do some
> incredible amount of work which makes the actual transfer not worth doing
> (by the time you set it up, the CPU could have copied it on it's own
> already, I guess what you DO gain is a kernel preemption point.. the CPU
> can do other things that are important)
If you want an Efika specific problem, the audio hardware is capable
of simultaneously playing music on the S/PDIF and analog outputs. But
to do that the samples have to be alternated as they are fed into the
AC97 stream. I think the codec can capture that way too but you
didn't put a transceiver on the S/PDIF line.
In my test driver you only get AC97 or S/PDIF. Grant and I are both
working on i2s drivers, when we get those sorted out it shouldn't be
too hard to add ac97 back in. That codec driver I sent you was about
95% complete.
>
> I for one, though, whether it speeds stuff up or not, love to see this in
> action and am very willing to test and benchmark it. I would love to see
> more users, too, as the network stack is not the only system that can
> benefit..
>
> On a related note does anyone know of the status or what is going on with
> Clifford Wolf's dmatransfer API?
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: patches for 2.6.27...
From: John Rigby @ 2008-07-07 13:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <068935A1-11BE-4AEB-9C0E-E1AB53F1618E@kernel.crashing.org>
Two pci patches that are prereq's for 5121 pci:
http://patchwork.ozlabs.org/linuxppc/patch?person=518&id=19299
http://patchwork.ozlabs.org/linuxppc/patch?person=518&id=19300
On Wed, Jul 2, 2008 at 1:56 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Please point out any patches that have been posted but havent made it into a
> git tree related to Freescale chips.
>
> I know there are probably a slew of CPM patches that need to get into the
> tree.
>
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v5] ibm_newemac: Parameterize EMAC Multicast Match Handling
From: Jeff Garzik @ 2008-07-07 13:59 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, sr, Grant Erickson
In-Reply-To: <1215411537.8970.87.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Hi Jeff !
>
> If you are ok with this patch, I'll take it through the powerpc tree
> since it changes all those device tree files.
ACK
^ permalink raw reply
* Re: [patch 0/6] Strong Access Ordering page attributes for POWER7
From: Dave Kleikamp @ 2008-07-07 14:05 UTC (permalink / raw)
To: benh, Joel Schopp; +Cc: linux-mm, Andrew Morton, Paul Mackerras, Linuxppc-dev
In-Reply-To: <1215128392.7960.7.camel@pasglop>
On Fri, 2008-07-04 at 09:39 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2008-06-18 at 17:32 -0500, shaggy@linux.vnet.ibm.com wrote:
> > Andrew,
> >
> > The first patch in this series hits architecture independent code, but the
> > rest is contained in the powerpc subtree. Could you pick up the first
> > patch into -mm? I can send the rest of them through the powerpc git tree.
> > The first patch and the rest of the set are independent and can be merged
> > in either order.
>
> ../..
>
> I was wondering... how do we inform userspace that this is available ?
> Same question with adding the endian bit on 4xx which I plan to do using
> your infrastructure...
I hadn't really given it much thought. Is there a simple way to
determine if the cpu is power 7 or newer?
It's not elegant, but a program could call mmap() with PROT_SAO set and
check for errno == EINVAL. Then call again without PROT_SAO, if it
needs to.
> We haven't defined a user-visible feature bit (and besides, we're really
> getting short on these...). This is becoming a bit of concern btw (the
> running out of bits). Maybe we should start defining an AT_HWCAP2 for
> powerpc and get libc updated to pick it up ?
Joel,
Any thoughts?
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Josh Boyer @ 2008-07-07 14:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080701043607.07484DDED7@ozlabs.org>
On Tue, 01 Jul 2008 14:35:42 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This is some preliminary work to improve TLB management on SW loaded
> TLB powerpc platforms. This introduce support for non-atomic PTE
> operations in pgtable-ppc32.h and removes write back to the PTE from
> the TLB miss handlers. In addition, the DSI interrupt code no longer
> tries to fixup write permission, this is left to generic code, and
> _PAGE_HWWRITE is gone.
I tried testing this on a Sequoia board this morning. Kernel boots,
but then it hangs when starting the init process. The last message
seen is:
INIT: version 2.86
booting
The setup is an tftp'd kernel via U-Boot using cuImage, nfsroot
filesystem. Sequoia has an FPU, and CONFIG_PPC_FPU is set.
I reverted this patch and used the latest powerpc-next branch and it
boots fine.
Seems something is wrong here still. I suspect the DSI handler
changes, but I have no proof and haven't debugged it yet. Until we
get it fixed, I don't feel overly comfortable putting it in the next
branch. Which board and setup did you test with?
josh
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Josh Boyer @ 2008-07-07 14:07 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40807070634t6e9047d1k7d8ca2b443d1ae68@mail.gmail.com>
On Mon, 7 Jul 2008 07:34:23 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 7, 2008 at 7:18 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > On Fri, 4 Jul 2008 00:51:44 -0600
> > "Grant Likely" <grant.likely@secretlab.ca> wrote:
> >
> >> Anyone had a chance to look at this? I think this could be used to
> >> eliminate a lot of the platform specific default targets in
> >> arch/powerpc/boot/Makefile by moving them into the defconfigs. Josh,
> >> Kumar, what are your thoughts?
> >
> > So for cases like Kilauea/Haleakala or Bamboo/Yosemite, you would
> > specify Yosemite in the bamboo defconfig? Or?
>
> If they share a defconfig, then yes, that is what I'm thinking about...
>
> > I actually sort of prefer having a separate defconfig/CONFIG_YOSEMITE
> > (as an example) because it's much easier for an end user to figure out
> > if the board is supported or not.
>
> ...however, these don't have to disappear if you prefer them.
Right.
> > I could be totally misunderstanding the intention of this patch though,
> > so I'll stop rambling and wait to see what the use case is.
>
> Specifically the case I'm thinking of is when a user of a Xilinx FPGA
> drops a new .dts file into arch/powerpc/boot/dts (say
> 'super-sexy-platform.dts'). However, instead of modifying the
> Makefile or always typing 'make simpleImage.super-sexy-platform', then
> can add 'simpleImage.super-sexy-platform' to their defconfig which I
> can see being easier for someone to get their head around.
Yeah, I thought about the Virtex case with the differing bitstreams
after I sent out my original question. For purposes like that, this
seems like a great fit. For truly discrete boards, I prefer discrete
defconfigs.
So overall I see value in the patch. If nobody else has objections,
then it's fine with me.
josh
^ permalink raw reply
* Re: [PATCH] Add MPC5200B base board mvBC-P
From: Grant Likely @ 2008-07-07 14:12 UTC (permalink / raw)
To: Andre Schwarz, David Gibson, Segher Boessenkool,
Benjamin Herrenschmidt
Cc: linux-ppc list
In-Reply-To: <4871CA6E.9080805@matrix-vision.de>
On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
> David,
>
> thanks - removed "device_type" from the DMA controller.
>
> Which nodes actually require "device_type" and which don't ?
>
> Is there some general rule ?
Segher, David;
In OF, what is the purpose of device_type? From what I understand
right now, each value of device_type claims a software interface that
the device supports. So for example, device_type = "serial" means
that firmware supports using the device as a serial port, correct?
So, similarly, if OF did not have a driver for the device, then the
presence a device_type property would be a bug, right?
Does device_type indicated any other information other than firmware
driver interface?
I had an epiphany about device_type this weekend (and by epiphany, I
mean realizing my own stupidity). If I'm correct about the above
questions, then that would mean it is *always* a bug to have a
device_type property in .dts file because there is no firmware
interface. So, it seems to me that we shouldn't just be eliminating
undefined device_type values, but also eliminate the ones that are
defined in OF because .dts users do not support the firmware driver
interface.
Am I correct?
The only situation where I can see it being appropriate to specify
device_type is to work around older bindings that are ambiguous with
their other properties.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Please pull linux-2.6-virtex.git
From: John Linn @ 2008-07-07 14:13 UTC (permalink / raw)
To: Josh Boyer, grant.likely; +Cc: linuxppc-dev
In-Reply-To: <1215433036.20774.39.camel@weaponx>
I'll look at the dts file and converting it to v1 format, hopefully
soon.
Thanks,
John
> -----Original Message-----
> From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Josh Boyer
> Sent: Monday, July 07, 2008 6:17 AM
> To: grant.likely@secretlab.ca
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Please pull linux-2.6-virtex.git
> =
> On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote:
> > Hi Josh,
> >
> > Here are the bulk of the Xilinx 440 support patches. Please pull
> > into your next branch.
> >
> > Thanks,
> > g.
> >
> > The following changes since commit
f3e909c2750eb20536bacacc867dc9047b70546a:
> > Michael Neuling (1):
> > powerpc: Update for VSX core file and ptrace
> >
> > are available in the git repository at:
> >
> > git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
> >
> =
> <snip>
> =
> > John Linn (5):
> > powerpc/virtex: add dts file for ML507 reference design
> =
> This one still isn't a dts-v1 file. Any chance of that getting fixed
in
> the next day or two?
> =
> josh
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: MPC52xx generic DMA using bestcomm
From: Matt Sealey @ 2008-07-07 14:18 UTC (permalink / raw)
To: Jon Smirl; +Cc: Andre Schwarz, linux-ppc list
In-Reply-To: <9e4733910807070639k283b1267q34a4c9bbff827b22@mail.gmail.com>
Jon Smirl wrote:
> On 7/7/08, Matt Sealey <matt@genesi-usa.com> wrote:
>>
> to do that the samples have to be alternated as they are fed into the
> AC97 stream. I think the codec can capture that way too but you
> didn't put a transceiver on the S/PDIF line.
OT, but the IDT STAC9766 doesn't support S/PDIF input, only output.
> In my test driver you only get AC97 or S/PDIF. Grant and I are both
> working on i2s drivers, when we get those sorted out it shouldn't be
> too hard to add ac97 back in. That codec driver I sent you was about
> 95% complete.
Indeed and to be honest I only gave it a short glance before having to
do about a thousand other things, but I will take another peek some
time this week :)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] [V2] powerpc: legacy_serial: reg-offset & shift aren't used
From: Grant Likely @ 2008-07-07 14:24 UTC (permalink / raw)
To: benh; +Cc: dwg, linuxppc-dev, paulus, John Linn
In-Reply-To: <1215413228.8970.106.camel@pasglop>
On Mon, Jul 7, 2008 at 12:47 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2008-07-01 at 10:52 -0700, John Linn wrote:
>> The legacy serial driver does not work with an 8250
>> type UART that uses reg-offset and reg-shift. This
>> change updates the driver so it doesn't find the UART
>> when those properties are present on the UART in the
>> device tree for soc devices.
>
> I have some problems with this patch:
>
> - First if the properties are present but their value match the
> register layout of a standard UART, we will bail out... not nice.
Okay, that can be fixed.
> - Why don't we just implement support for the reg-shift and
> offset instead ?
We can do this, but this patch was simpler for solving the immediate
problem in .26
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [RFC] [PATCH] task_pt_regs for powerpc systems
From: Srinivasa D S @ 2008-07-07 14:22 UTC (permalink / raw)
To: linuxppc-dev, Ananth Mavinakayanahalli, benh, paulus
Hi
task_pt_regs() macro defines pt_regs for the given task, this macro is
currently not defined for powerpc arch. We need this macro for
upcoming utrace features.
Below attached patch defines this macro for powerpc arch. Please let
me know your comments on this.
Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
---
include/asm-powerpc/processor.h | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.26-rc9/include/asm-powerpc/processor.h
===================================================================
--- linux-2.6.26-rc9.orig/include/asm-powerpc/processor.h
+++ linux-2.6.26-rc9/include/asm-powerpc/processor.h
@@ -214,6 +214,8 @@ struct thread_struct {
#define thread_saved_pc(tsk) \
((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
+#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.regs)
+
unsigned long get_wchan(struct task_struct *p);
#define KSTK_EIP(tsk) ((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
^ permalink raw reply
* RE: Please pull linux-2.6-virtex.git
From: John Linn @ 2008-07-07 14:26 UTC (permalink / raw)
To: John Linn, Josh Boyer, grant.likely; +Cc: linuxppc-dev
In-Reply-To: <20080707141332.6CDD313E8050@mail111-sin.bigfish.com>
Where should I be looking to understand what's needed for dts-v1 format?
I did a quick review of Doc*/powerpc/booting-wihtout-of.txt and didn't
see it, but maybe I overlooked it.
Thanks,
John =
> -----Original Message-----
> From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of John Linn
> Sent: Monday, July 07, 2008 8:14 AM
> To: Josh Boyer; grant.likely@secretlab.ca
> Cc: linuxppc-dev@ozlabs.org
> Subject: RE: Please pull linux-2.6-virtex.git
> =
> I'll look at the dts file and converting it to v1 format, hopefully
> soon.
> =
> Thanks,
> John
> =
> > -----Original Message-----
> > From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
> [mailto:linuxppc-dev-
> > bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Josh Boyer
> > Sent: Monday, July 07, 2008 6:17 AM
> > To: grant.likely@secretlab.ca
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: Please pull linux-2.6-virtex.git
> >
> > On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote:
> > > Hi Josh,
> > >
> > > Here are the bulk of the Xilinx 440 support patches. Please pull
> > > into your next branch.
> > >
> > > Thanks,
> > > g.
> > >
> > > The following changes since commit
> f3e909c2750eb20536bacacc867dc9047b70546a:
> > > Michael Neuling (1):
> > > powerpc: Update for VSX core file and ptrace
> > >
> > > are available in the git repository at:
> > >
> > > git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
> > >
> >
> > <snip>
> >
> > > John Linn (5):
> > > powerpc/virtex: add dts file for ML507 reference design
> >
> > This one still isn't a dts-v1 file. Any chance of that getting
fixed
> in
> > the next day or two?
> >
> > josh
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> =
> =
> This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s)
> confidential information that may be proprietary, privileged or
copyrighted under applicable law. If
> you are not the intended recipient, do not read, copy, or forward this
email message or any
> attachments. Delete this email message and any attachments
immediately.
> =
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [patch 0/5] Strong Access Ordering
From: Dave Kleikamp @ 2008-07-07 14:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Ben,
Please include these patches in powerpc-next.
Changelog since posting to linuxppc-dev on June 18th:
- rebased on top of powerpc-next branch
- Added arch_validate_prot define as suggested by Andrew
- Added #ifdef CONFIG_PPC64 in include/powerpc/mman.h to fix 32-bit build
Thanks,
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [patch 1/5] mm: Allow architectures to define additional protection bits
From: Dave Kleikamp @ 2008-07-07 14:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Andrew Morton, Hugh Dickins
In-Reply-To: <20080707142850.034542257@linux.vnet.ibm.com>
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
Note: vm_get_page_prot() is now pretty ugly, but the generated code
should be identical for architectures that don't define additional
protection bits.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hugh@veritas.com>
---
include/linux/mman.h | 29 ++++++++++++++++++++++++++++-
mm/mmap.c | 5 +++--
mm/mprotect.c | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
Index: b/include/linux/mman.h
===================================================================
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -34,6 +34,32 @@
}
/*
+ * Allow architectures to handle additional protection bits
+ */
+
+#ifndef arch_calc_vm_prot_bits
+#define arch_calc_vm_prot_bits(prot) 0
+#endif
+
+#ifndef arch_vm_get_page_prot
+#define arch_vm_get_page_prot(vm_flags) __pgprot(0)
+#endif
+
+#ifndef arch_validate_prot
+/*
+ * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have
+ * already been masked out.
+ *
+ * Returns true if the prot flags are valid
+ */
+static inline int arch_validate_prot(unsigned long prot)
+{
+ return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
+}
+#define arch_validate_prot arch_validate_prot
+#endif
+
+/*
* Optimisation macro. It is equivalent to:
* (x & bit1) ? bit2 : 0
* but this version is faster.
@@ -51,7 +77,8 @@
{
return _calc_vm_trans(prot, PROT_READ, VM_READ ) |
_calc_vm_trans(prot, PROT_WRITE, VM_WRITE) |
- _calc_vm_trans(prot, PROT_EXEC, VM_EXEC );
+ _calc_vm_trans(prot, PROT_EXEC, VM_EXEC) |
+ arch_calc_vm_prot_bits(prot);
}
/*
Index: b/mm/mmap.c
===================================================================
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -72,8 +72,9 @@
pgprot_t vm_get_page_prot(unsigned long vm_flags)
{
- return protection_map[vm_flags &
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ return __pgprot(pgprot_val(protection_map[vm_flags &
+ (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
+ pgprot_val(arch_vm_get_page_prot(vm_flags)));
}
EXPORT_SYMBOL(vm_get_page_prot);
Index: b/mm/mprotect.c
===================================================================
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -239,7 +239,7 @@
end = start + len;
if (end <= start)
return -ENOMEM;
- if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
+ if (!arch_validate_prot(prot))
return -EINVAL;
reqprot = prot;
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [patch 2/5] powerpc: Define flags for Strong Access Ordering
From: Dave Kleikamp @ 2008-07-07 14:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <20080707142850.034542257@linux.vnet.ibm.com>
This patch defines:
- PROT_SAO, which is passed into mmap() and mprotect() in the prot field
- VM_SAO in vma->vm_flags, and
- _PAGE_SAO, the combination of WIMG bits in the pte that enables strong
access ordering for the page.
NOTE: There doesn't seem to be a precedent for architecture-dependent vm_flags.
It may be better to define VM_SAO somewhere in include/asm-powerpc/. Since
vm_flags is a long, defining it in the high-order word would help prevent a
collision with any newly added values in architecture-independent code.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
---
include/asm-powerpc/mman.h | 2 ++
include/asm-powerpc/pgtable-ppc64.h | 3 +++
include/linux/mm.h | 1 +
3 files changed, 6 insertions(+)
Index: b/include/asm-powerpc/mman.h
===================================================================
--- a/include/asm-powerpc/mman.h
+++ b/include/asm-powerpc/mman.h
@@ -10,6 +10,8 @@
* 2 of the License, or (at your option) any later version.
*/
+#define PROT_SAO 0x10 /* Strong Access Ordering */
+
#define MAP_RENAME MAP_ANONYMOUS /* In SunOS terminology */
#define MAP_NORESERVE 0x40 /* don't reserve swap pages */
#define MAP_LOCKED 0x80
Index: b/include/asm-powerpc/pgtable-ppc64.h
===================================================================
--- a/include/asm-powerpc/pgtable-ppc64.h
+++ b/include/asm-powerpc/pgtable-ppc64.h
@@ -93,6 +93,9 @@
#define _PAGE_RW 0x0200 /* software: user write access allowed */
#define _PAGE_BUSY 0x0800 /* software: PTE & hash are busy */
+/* Strong Access Ordering */
+#define _PAGE_SAO (_PAGE_WRITETHRU | _PAGE_NO_CACHE | _PAGE_COHERENT)
+
#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
#define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY)
Index: b/include/linux/mm.h
===================================================================
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -108,6 +108,7 @@
#define VM_CAN_NONLINEAR 0x08000000 /* Has ->fault & does nonlinear pages */
#define VM_MIXEDMAP 0x10000000 /* Can contain "struct page" and pure PFN pages */
+#define VM_SAO 0x20000000 /* Strong Access Ordering (powerpc) */
#ifndef VM_STACK_DEFAULT_FLAGS /* arch can override this */
#define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [patch 3/5] powerpc: Add SAO Feature bit to the cputable
From: Dave Kleikamp @ 2008-07-07 14:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <20080707142850.034542257@linux.vnet.ibm.com>
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
---
include/asm-powerpc/cputable.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/include/asm-powerpc/cputable.h
===================================================================
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -185,6 +185,7 @@
#define CPU_FTR_1T_SEGMENT LONG_ASM_CONST(0x0004000000000000)
#define CPU_FTR_NO_SLBIE_B LONG_ASM_CONST(0x0008000000000000)
#define CPU_FTR_VSX LONG_ASM_CONST(0x0010000000000000)
+#define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
#ifndef __ASSEMBLY__
@@ -400,7 +401,7 @@
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR)
+ CPU_FTR_DSCR | CPU_FTR_SAO)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox