* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-10 14:02 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, linuxppc-dev,
joerg.roedel, mingo
In-Reply-To: <20090710143408A.fujita.tomonori@lab.ntt.co.jp>
On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> I don't think that we need to take account of dom0 support; we don't
> have a clear idea about an acceptable dom0 design (it needs to use
> swiotlb code? I don't know yet), we don't even know we will have dom0
> support in mainline. That's why I didn't CC this patchset to Xen
> camp.
The core domain 0 patches which were the subject of the discussions a
few week back are completely orthogonal to the swiotlb side of things
and whatever form they eventually take I do not think it will have any
impact on the shape of the solution which we arrive at for swiotlb. I
don't think that assuming that domain 0 can never be done in a way which
everyone finds acceptable and therefore discounting all consideration of
it is a useful way to make progress with these issues.
The DMA use case is much more tightly tied to the paravirtualized MMU
(which is already in the kernel for domU purposes) than it is to "the
domain 0" patches anyway. Although domain 0 is probably the main use
case, at least today, swiotlb support is also used in a Xen domU as part
of the support for direct assignment of PCI devices to paravirtualised
guests (pci passthrough).
The pci frontend driver depends on some bits of the domain 0 physical
interrupt patches as well as swiotlb which is why I/we haven't tried to
upstream that particular series yet.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-10 14:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeremy Fitzhardinge, tony.luck@intel.com,
linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, FUJITA Tomonori,
linuxppc-dev@ozlabs.org, Joerg Roedel
In-Reply-To: <20090710051236.GA22218@elte.hu>
On Fri, 2009-07-10 at 06:12 +0100, Ingo Molnar wrote:
> Hm, the functions and facilities you remove here were added as part
> of preparatory patches for Xen guest support. You were aware of
> them, you were involved in discussions about those aspects with Ian
> and Jeremy but still you chose not to Cc: either of them and you
> failed to address that aspect in the changelogs.
Thanks for adding me Ingo.
> Alas, on the technical level the cleanups themselves look mostly
> fine to me. Ian, Jeremy, the changes will alter Xen's use of
> swiotlb, but can the Xen side still live with these new methods - in
> particular is dma_capable() sufficient as a mechanism and can the
> Xen side filter out DMA allocations to make them physically
> continuous?
I've not examined the series in detail it looks OK but I don't think it
is quite sufficient. The Xen determination of whether a buffer is
dma_capable or not is based on the physical address while dma_capable
takes only the dma address.
I'm not sure we can "invert" our conditions to work back from dma
address to physical since given a start dma address and a length we
would need to check that dma_to_phys(dma+PAGE_SIZE) ==
dma_to_phys(dma)+PAGE_SIZE etc. However dma+PAGE_SIZE might belong to a
different domain so translating it to a physical address in isolation
tells us nothing especially useful since it would give us the physical
address in that other guest which is useless to us. If we could pass
both physical and dma address to dma_capable I think that would probably
be sufficient for our purposes.
As well as that Xen needs some way to influence the allocation of the
actual bounce buffer itself since we need to arrange for it to be
machine address contiguous as well as physical address contiguous. This
series explicitly removes those hooks without replacement. My most
recent proposal was to have a new swiotlb_init variant which was given a
preallocated buffer which this series doesn't necessarily preclude.
The phys_to_dma and dma_to_phys translation points are the last piece
Xen needs and seem to be preserved in this series.
However Fujita's objection to all of the previous swiotlb-for-xen
proposals was around the addition of the Xen hooks in whichever
location. Originally these hooks were via __weak functions and later
proposals implemented them via function pointer hooks in the x86
implementations of the arch-abstract interfaces (phys<->dma and
dma_capable etc). I don't think this series addresses those objections
(fair enough -- it wasn't intended to) or leads to any new approach to
solving the issue, although I also don't think it makes the issue any
harder to address. I don't think it will be possible to make progress on
Xen usage of swiotlb until a solution can be found to this conflict of
opinion.
Fujita suggested that we export the core sync_single() functionality and
reimplemented the surrounding infrastructure in terms of that (and
incorporating our additional requirements). I prototyped this (it is
currently unworking, in fact it seems to have developed rather a taste
for filesystems :-() but the diffstat of my WIP patch is:
arch/x86/kernel/pci-swiotlb.c | 6
arch/x86/xen/pci-swiotlb.c | 2
drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
include/linux/swiotlb.h | 12 +
lib/swiotlb.c | 10 -
5 files changed, 385 insertions(+), 30 deletions(-)
where a fair number of the lines in xen-iommu.c are copies of functions
from swiotlb.c with minor modifications. As I say it doesn't work yet
but I think it's roughly indicative of what such an approach would look
like. I don't like it much but am happy to run with it if it looks to be
the most acceptable approach. To be honest at the moment I've
deliberately been taking some time away from this stuff to try and gain
a bit of perspective so I haven't looked at it in a while.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ingo Molnar @ 2009-07-10 14:12 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, tony.luck@intel.com,
linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, FUJITA Tomonori,
linuxppc-dev@ozlabs.org, Joerg Roedel
In-Reply-To: <1247234512.4002.417.camel@zakaz.uk.xensource.com>
* Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> I've not examined the series in detail it looks OK but I don't
> think it is quite sufficient. The Xen determination of whether a
> buffer is dma_capable or not is based on the physical address
> while dma_capable takes only the dma address.
>
> I'm not sure we can "invert" our conditions to work back from dma
> address to physical since given a start dma address and a length
> we would need to check that dma_to_phys(dma+PAGE_SIZE) ==
> dma_to_phys(dma)+PAGE_SIZE etc. However dma+PAGE_SIZE might belong
> to a different domain so translating it to a physical address in
> isolation tells us nothing especially useful since it would give
> us the physical address in that other guest which is useless to
> us. If we could pass both physical and dma address to dma_capable
> I think that would probably be sufficient for our purposes.
>
> As well as that Xen needs some way to influence the allocation of
> the actual bounce buffer itself since we need to arrange for it to
> be machine address contiguous as well as physical address
> contiguous. This series explicitly removes those hooks without
> replacement. My most recent proposal was to have a new
> swiotlb_init variant which was given a preallocated buffer which
> this series doesn't necessarily preclude.
>
> The phys_to_dma and dma_to_phys translation points are the last
> piece Xen needs and seem to be preserved in this series.
>
> However Fujita's objection to all of the previous swiotlb-for-xen
> proposals was around the addition of the Xen hooks in whichever
> location. Originally these hooks were via __weak functions and
> later proposals implemented them via function pointer hooks in the
> x86 implementations of the arch-abstract interfaces (phys<->dma
> and dma_capable etc). I don't think this series addresses those
> objections (fair enough -- it wasn't intended to) or leads to any
> new approach to solving the issue, although I also don't think it
> makes the issue any harder to address. I don't think it will be
> possible to make progress on Xen usage of swiotlb until a solution
> can be found to this conflict of opinion.
>
> Fujita suggested that we export the core sync_single()
> functionality and reimplemented the surrounding infrastructure in
> terms of that (and incorporating our additional requirements). I
> prototyped this (it is currently unworking, in fact it seems to
> have developed rather a taste for filesystems :-() but the
> diffstat of my WIP patch is:
>
> arch/x86/kernel/pci-swiotlb.c | 6
> arch/x86/xen/pci-swiotlb.c | 2
> drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> include/linux/swiotlb.h | 12 +
> lib/swiotlb.c | 10 -
> 5 files changed, 385 insertions(+), 30 deletions(-)
>
> where a fair number of the lines in xen-iommu.c are copies of
> functions from swiotlb.c with minor modifications. As I say it
> doesn't work yet but I think it's roughly indicative of what such
> an approach would look like. I don't like it much but am happy to
> run with it if it looks to be the most acceptable approach. [...]
+400 lines of code to avoid much fewer lines of generic code impact
on the lib/swiotlb.c side sounds like a bad technical choice to me.
It makes the swiotlb code less useful and basically forks a random
implementation of it in drivers/pci/xen-iommu.c.
Fujita-san, can you think of a solution that avoids the whole-sale
copying of hundreds of lines of code?
Ingo
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 14:37 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090710041536.GE3181@bubble.grove.modra.org>
On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
> wrote:
>> I understand your arguments, but there is something inconsistent
>> about this.
>> If I change the script to be:
>> _end3 = . ;
>> . = _end3;
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>> }
>> The result is corrected:
>> c067f678 A _end3
>> c0680000 A _end
>>
>> Why the apuinfo section with zero VMA sometimes interfere with "."
>> and
>> sometimes not ?
>
> I said it was weird in my last email. Not so. The orphan gets placed
> between
>
> _end3 = . ;
> . = _end3;
>
> So dot is restored after the orphan section sets it.
This seems to be a bit of a chick and egg scenario. Older kernel
linker scripts aren't going to cover all sections and thus may have
orphan sections. How do we ensure _end can be set properly under such
conditions?
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-10 15:04 UTC (permalink / raw)
To: Doug Thompson; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <2576.44687.qm@web50111.mail.re2.yahoo.com>
On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>
> Ok, is this the one you want me to push upstream?
>
Yep, this is the finished version.
Thanks,
Ira
> doug t
>
>
> --- On Thu, 7/9/09, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
>
> From: Ira W. Snyder <iws@ovro.caltech.edu>
> Subject: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
> To: bluesmoke-devel@lists.sourceforge.net, "Dave Jiang" <djiang@mvista.com>, "Kumar Gala" <galak@kernel.crashing.org>, linuxppc-dev@ozlabs.org
> Date: Thursday, July 9, 2009, 1:40 PM
>
> Add support for the Freescale MPC83xx memory controller to the existing
> driver for the Freescale MPC85xx memory controller. The only difference
> between the two processors are in the CS_BNDS register parsing code, which
> has been changed so it will work on both processors.
>
> The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
> will not use the driver if the device is not present in the OF device tree.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
>
> Kumar, I had to change the nr_pages calculation to make the math work
> out. I checked it on my board and did the math by hand for a 64GB 85xx
> using 64K pages. In both cases, nr_pages * PAGE_SIZE comes out to the
> correct value. Thanks for the help.
>
> v1 -> v2:
> * Use PAGE_SHIFT to parse cs_bnds regardless of board type
> * Remove special-casing for the 83xx processor
>
> drivers/edac/Kconfig | 6 +++---
> drivers/edac/mpc85xx_edac.c | 28 +++++++++++++++++++---------
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 4339b1a..78303f9 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -176,11 +176,11 @@ config EDAC_I5100
> San Clemente MCH.
>
> config EDAC_MPC85XX
> - tristate "Freescale MPC85xx"
> - depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
> + tristate "Freescale MPC83xx / MPC85xx"
> + depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
> help
> Support for error detection and correction on the Freescale
> - MPC8560, MPC8540, MPC8548
> + MPC8349, MPC8560, MPC8540, MPC8548
>
> config EDAC_MV64X60
> tristate "Marvell MV64x60"
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index b4f5c63..ba2a264 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
> #endif
>
> static u32 orig_l2_err_disable;
> +#ifdef CONFIG_MPC85xx
> static u32 orig_hid1[2];
> +#endif
>
> /************************ MC SYSFS parts ***********************************/
>
> @@ -790,19 +792,20 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
> csrow = &mci->csrows[index];
> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
> (index * MPC85XX_MC_CS_BNDS_OFS));
> - start = (cs_bnds & 0xfff0000) << 4;
> - end = ((cs_bnds & 0xfff) << 20);
> - if (start)
> - start |= 0xfffff;
> - if (end)
> - end |= 0xfffff;
> +
> + start = (cs_bnds & 0xffff0000) >> 16;
> + end = (cs_bnds & 0x0000ffff);
>
> if (start == end)
> continue; /* not populated */
>
> + start <<= (24 - PAGE_SHIFT);
> + end <<= (24 - PAGE_SHIFT);
> + end |= (1 << (24 - PAGE_SHIFT)) - 1;
> +
> csrow->first_page = start >> PAGE_SHIFT;
> csrow->last_page = end >> PAGE_SHIFT;
> - csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
> + csrow->nr_pages = end + 1 - start;
> csrow->grain = 8;
> csrow->mtype = mtype;
> csrow->dtype = DEV_UNKNOWN;
> @@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> { .compatible = "fsl,mpc8560-memory-controller", },
> { .compatible = "fsl,mpc8568-memory-controller", },
> { .compatible = "fsl,mpc8572-memory-controller", },
> + { .compatible = "fsl,mpc8349-memory-controller", },
> {},
> };
>
> @@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
> },
> };
>
> -
> +#ifdef CONFIG_MPC85xx
> static void __init mpc85xx_mc_clear_rfxe(void *data)
> {
> orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
> mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
> }
> -
> +#endif
>
> static int __init mpc85xx_mc_init(void)
> {
> @@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
> printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
> #endif
>
> +#ifdef CONFIG_MPC85xx
> /*
> * need to clear HID1[RFXE] to disable machine check int
> * so we can catch it
> */
> if (edac_op_state == EDAC_OPSTATE_INT)
> on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
> +#endif
>
> return 0;
> }
>
> module_init(mpc85xx_mc_init);
>
> +#ifdef CONFIG_MPC85xx
> static void __exit mpc85xx_mc_restore_hid1(void *data)
> {
> mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
> }
> +#endif
>
> static void __exit mpc85xx_mc_exit(void)
> {
> +#ifdef CONFIG_MPC85xx
> on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
> +#endif
> #ifdef CONFIG_PCI
> of_unregister_platform_driver(&mpc85xx_pci_err_driver);
> #endif
> --
> 1.5.4.3
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> bluesmoke-devel mailing list
> bluesmoke-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluesmoke-devel
>
>
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Edmar Wienskoski-RA8797,
Alan Modra, bug-binutils
In-Reply-To: <D4C31507-B4F9-4979-A6E1-7971242D644B@kernel.crashing.org>
On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:
>
> On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
>
>> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
>> wrote:
>>> I understand your arguments, but there is something inconsistent
>>> about this.
>>> If I change the script to be:
>>> _end3 = . ;
>>> . = _end3;
>>> . = ALIGN(PAGE_SIZE);
>>> _end = . ;
>>> PROVIDE32 (end = .);
>>> }
>>> The result is corrected:
>>> c067f678 A _end3
>>> c0680000 A _end
>>>
>>> Why the apuinfo section with zero VMA sometimes interfere with "."
>>> and
>>> sometimes not ?
>>
>> I said it was weird in my last email. Not so. The orphan gets
>> placed
>> between
>>
>> _end3 = . ;
>> . = _end3;
>>
>> So dot is restored after the orphan section sets it.
>
> This seems to be a bit of a chick and egg scenario. Older kernel
> linker scripts aren't going to cover all sections and thus may have
> orphan sections. How do we ensure _end can be set properly under
> such conditions?
Not sure if this helps, but I've isolated down the version of binutils
that changes to:
binutils-2.19 _end is what we expect
binutils-2.19.1 _end is what we expect
binutils-2.19.50.0.1 _end is what we expect
binutils-2.19.51.0.1 _end is 00001000
From the release notes:
binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:34 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090710041123.GD3181@bubble.grove.modra.org>
On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:
> Hmm, having said all that, the following linker patch seems reasonable
> to me and probably won't break anything else (always some risk).
> Please test it for me.
>
> Index: ld/ldlang.c
> ===================================================================
> RCS file: /cvs/src/src/ld/ldlang.c,v
> retrieving revision 1.311
> diff -u -p -r1.311 ldlang.c
> --- ld/ldlang.c 25 Jun 2009 13:18:46 -0000 1.311
> +++ ld/ldlang.c 10 Jul 2009 04:04:57 -0000
> @@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
> idea is to skip over anything that might be inside a SECTIONS {}
> statement in a script, before we find another output section
> statement. Assignments to "dot" before an output section statement
> - are assumed to belong to it. An exception to this rule is made
> for
> - the first assignment to dot, otherwise we might put an orphan
> - before . = . + SIZEOF_HEADERS or similar assignments that set the
> - initial address. */
> + are assumed to belong to it, except in two cases; The first
> + assignment to dot, and assignments before non-alloc sections.
> + Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
> + similar assignments that set the initial address, or we might
> + insert non-alloc note sections among assignments setting end of
> + image symbols. */
>
> static lang_statement_union_type **
> insert_os_after (lang_output_section_statement_type *after)
> @@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
> continue;
> case lang_output_section_statement_enum:
> if (assign != NULL)
> - where = assign;
> + {
> + asection *s = (*where)->output_section_statement.bfd_section;
> +
> + if (s == NULL || (s->flags & SEC_ALLOC) != 0)
> + where = assign;
> + }
> break;
> case lang_input_statement_enum:
> case lang_address_statement_enum:
>
> --
This patch seems to "fix" things.
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-10 15:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090710150420.GA11719@ovro.caltech.edu>
On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>
>> Ok, is this the one you want me to push upstream?
>>
>
> Yep, this is the finished version.
>
> Thanks,
> Ira
>
>> doug t
>
is that for .31 or .32? If .31 I'm fine. If for .32 I still have
some things I like to deal with. (like the other 85xx specific bits)
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-10 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <D2ADC85F-2986-42EA-B8AD-03F30E871A55@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:36:20AM -0500, Kumar Gala wrote:
>
> On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>>
>>> Ok, is this the one you want me to push upstream?
>>>
>>
>> Yep, this is the finished version.
>>
>> Thanks,
>> Ira
>>
>>> doug t
>>
>
> is that for .31 or .32? If .31 I'm fine. If for .32 I still have some
> things I like to deal with. (like the other 85xx specific bits)
>
.32 is fine for me. This is a new feature, not really a bugfix. I can
maintain it in my (growing) set of patches against mainline until it
gets merged.
Ira
^ permalink raw reply
* [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Andreas Schwab @ 2009-07-10 21:17 UTC (permalink / raw)
To: linuxppc-dev
When moving load_up_altivec to vector.S a typo in a comment caused a
thinko setting the wrong variable.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index ef36cbb..ea4d646 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
mtvscr vr0
REST_32VRS(0,r4,r5)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_altivec to 'current' */
subi r4,r5,THREAD /* Back to 'current' */
fromreal(r4)
- PPC_STL r4,ADDROFF(last_task_used_math)(r3)
+ PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
#endif /* CONFIG_SMP */
/* restore registers and return */
blr
@@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
oris r12,r12,MSR_VSX@h
std r12,_MSR(r1)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_vsx to 'current' */
ld r4,PACACURRENT(r13)
std r4,0(r3)
#endif /* CONFIG_SMP */
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Benjamin Herrenschmidt @ 2009-07-10 23:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2iqi0w83z.fsf@igel.home>
On Fri, 2009-07-10 at 23:17 +0200, Andreas Schwab wrote:
> When moving load_up_altivec to vector.S a typo in a comment caused a
> thinko setting the wrong variable.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Good catch, thanks.
Cheers,
Ben.
> ---
> diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
> index ef36cbb..ea4d646 100644
> --- a/arch/powerpc/kernel/vector.S
> +++ b/arch/powerpc/kernel/vector.S
> @@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
> mtvscr vr0
> REST_32VRS(0,r4,r5)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_altivec to 'current' */
> subi r4,r5,THREAD /* Back to 'current' */
> fromreal(r4)
> - PPC_STL r4,ADDROFF(last_task_used_math)(r3)
> + PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
> #endif /* CONFIG_SMP */
> /* restore registers and return */
> blr
> @@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
> oris r12,r12,MSR_VSX@h
> std r12,_MSR(r1)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_vsx to 'current' */
> ld r4,PACACURRENT(r13)
> std r4,0(r3)
> #endif /* CONFIG_SMP */
>
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:05 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <4F69F333-8BCA-4BB8-A5C1-4B25EA5D1287@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
> binutils-2.19 _end is what we expect
> binutils-2.19.1 _end is what we expect
> binutils-2.19.50.0.1 _end is what we expect
> binutils-2.19.51.0.1 _end is 00001000
>
> From the release notes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
Yes, I already have good reason to suspect this patch
2008-10-22 Alan Modra <amodra@bigpond.net.au>
* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
sections.
* emultempl/elf32.em (enum orphan_save_index): Add orphan_nonalloc.
(hold): Likewise.
(gld${EMULATION_NAME}_place_orphan): Handle non-alloc orphans.
causes the change in linker behaviour. Did you try the patch I posted?
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:08 UTC (permalink / raw)
To: Kumar Gala, Scott Wood, linuxppc-dev@ozlabs.org list,
bug-binutils, Edmar Wienskoski-RA8797
In-Reply-To: <20090711000503.GO3181@bubble.grove.modra.org>
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?
/me reads other email. I see you did. Applying.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: Memory usage of a process
From: Nicholas Mc Guire @ 2009-07-11 10:05 UTC (permalink / raw)
To: G?nter Leonhardt; +Cc: linuxppc-dev
In-Reply-To: <D0B748CCD5DF144CA5C56A9D860A31341DE613@men-exch1.intra.men.de>
On Fri, 10 Jul 2009, G?nter Leonhardt wrote:
>
> Hello,
> analysing the memory usage of a process, I found some questions.
> I'am using a system with 128 MB physical RAM, no disk, 2.6.27 kernel.
>
> Running top, I see 38 MB in use, 90 MB free, but a VSZ for my process of 158 MB.
> Looking at /proc/<pid>/maps, I see that the process uses 140 MB without shared libs.
>
> So how it is possible that the process can allocate more memory than there is, without posibility of swapping?
>
> Why said top that 90 MB free? Does the kernel serve the allocation only if ist really used?
>
an allocation does not actually set aside any physical ram (unless you do an mlock and actually touch the memory) - it only reserves virtual memory areas (vma's) and when your process accesses the respective address the OS page-faults and prvides the physical RAM as needed (and possible) - if you have no swap and you allow overcommitting of memory then you are potentially going to see this application failing as soon as it tries to utilize the memory.
This can be set in the system via /proc/sys/vm/overcommit_memory (see
linux/Documentation/vm/overcommit-accounting for details).
hofrat
^ permalink raw reply
* [PATCH 1/5] drivers/char/hvc_console.c: Drop unnecessary NULL test
From: Julia Lawall @ 2009-07-12 20:03 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The result of container_of should not be NULL. In particular, in this case
the argument to the enclosing function has passed though INIT_WORK, which
dereferences it, implying that its container cannot be NULL.
A simplified version of the semantic patch that makes this change is as
follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
identifier fn,work,x,fld;
type T;
expression E1,E2;
statement S;
@@
static fn(struct work_struct *work) {
... when != work = E1
x = container_of(work,T,fld)
... when != x = E2
- if (x == NULL) S
...
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/char/hvc_console.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 94e7e3c..e367630 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -516,8 +516,6 @@ static void hvc_set_winsz(struct work_struct *work)
struct winsize ws;
hp = container_of(work, struct hvc_struct, tty_resize);
- if (!hp)
- return;
spin_lock_irqsave(&hp->lock, hvc_flags);
if (!hp->tty) {
^ permalink raw reply related
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: mingo
Cc: fujita.tomonori, jeremy, tony.luck, linux-ia64, x86, linux-kernel,
Ian.Campbell, linuxppc-dev, joerg.roedel
In-Reply-To: <20090710141248.GE26264@elte.hu>
On Fri, 10 Jul 2009 16:12:48 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> > functionality and reimplemented the surrounding infrastructure in
> > terms of that (and incorporating our additional requirements). I
> > prototyped this (it is currently unworking, in fact it seems to
> > have developed rather a taste for filesystems :-() but the
> > diffstat of my WIP patch is:
> >
> > arch/x86/kernel/pci-swiotlb.c | 6
> > arch/x86/xen/pci-swiotlb.c | 2
> > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > include/linux/swiotlb.h | 12 +
> > lib/swiotlb.c | 10 -
> > 5 files changed, 385 insertions(+), 30 deletions(-)
> >
> > where a fair number of the lines in xen-iommu.c are copies of
> > functions from swiotlb.c with minor modifications. As I say it
> > doesn't work yet but I think it's roughly indicative of what such
> > an approach would look like. I don't like it much but am happy to
> > run with it if it looks to be the most acceptable approach. [...]
>
> +400 lines of code to avoid much fewer lines of generic code impact
> on the lib/swiotlb.c side sounds like a bad technical choice to me.
The amount of code is not the point. The way to impact on the
lib/swiotlb.c is totally wrong from the perspective of the kernel
design; it uses architecture code in the very original (xen) way.
> It makes the swiotlb code less useful and basically forks a random
> implementation of it in drivers/pci/xen-iommu.c.
I don't think so. We always have the reasonable amount of duplication
rather than integration in a dirty way (at least about IOMMU
code).
> Fujita-san, can you think of a solution that avoids the whole-sale
> copying of hundreds of lines of code?
Ian didn't give a pointer to his code in a public place so I'm not
sure his claim is valid. But if his code does the right thing and
the duplication is less than 400 lines, it doesn't sound that bad to
me.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, fujita.tomonori,
linuxppc-dev, joerg.roedel, mingo
In-Reply-To: <1247234520.4002.418.camel@zakaz.uk.xensource.com>
On Fri, 10 Jul 2009 15:02:00 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > I don't think that we need to take account of dom0 support; we don't
> > have a clear idea about an acceptable dom0 design (it needs to use
> > swiotlb code? I don't know yet), we don't even know we will have dom0
> > support in mainline. That's why I didn't CC this patchset to Xen
> > camp.
>
> The core domain 0 patches which were the subject of the discussions a
> few week back are completely orthogonal to the swiotlb side of things
? If we don't merge dom0 patch, we don't need dom0 changes to
swiotlb. We don't know we would have dom0 support in mainline. Or I
overlooked something?
> and whatever form they eventually take I do not think it will have any
> impact on the shape of the solution which we arrive at for swiotlb. I
> don't think that assuming that domain 0 can never be done in a way which
> everyone finds acceptable and therefore discounting all consideration of
> it is a useful way to make progress with these issues.
>
> The DMA use case is much more tightly tied to the paravirtualized MMU
> (which is already in the kernel for domU purposes) than it is to "the
> domain 0" patches anyway. Although domain 0 is probably the main use
> case, at least today, swiotlb support is also used in a Xen domU as part
> of the support for direct assignment of PCI devices to paravirtualised
> guests (pci passthrough).
>
> The pci frontend driver depends on some bits of the domain 0 physical
> interrupt patches as well as swiotlb which is why I/we haven't tried to
> upstream that particular series yet.
As far as I know, you have not posted anything about changes to
swiotlb for domU. I can't discuss it. If you want, please send
patches.
^ permalink raw reply
* mmap() problem in own driver
From: Sauce.Cheng @ 2009-07-13 7:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everyone
there is a problem of my own driver
I want to get data from kernel space to user space indirectly using mmap()
but i dont know how I can do , anyone can give me some advices ?
firstly, fetch data by DMA to a memory allocated by "kmalloc"
then i want to mmap it to user space and save the data as a file
Cheers everyone~
Martin
--
View this message in context: http://www.nabble.com/mmap%28%29-problem-in-own-driver-tp24457031p24457031.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Soft Reset for PPC44x Virtex 5 hangs saying Restarting System
From: srikanth krishnakar @ 2009-07-13 7:16 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
Hi all,
Kernel : Linux-2.6.29
Arch: Powerpc (ppc44x)
Target: Xilinx ML507 Virtex5
I have an issue in "Reset System" of Xilinx ML507 target board. I am using
Compact Flash to boot the target ( using system ACE file to boot the
target), during the process reset or reboot command on the target, I am not
able to reboot the target completely, here is the snapshot:
---------------------------------------------------------------------------------------------------
root@ml507:~# reboot
INIT: Sending processes the TERM signalWed Jul
INIT: Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid
1052)
.
Stopping Vixie-cron.
Stopping network benchmark server: netserverstopped /usr/sbin/netserver (pid
1058)
.
Stopping syslogd/klogd: stopped syslogd (pid 1061)
stopped klogd (pid 1063)
done
NOT deconfiguring network interfaces: / is an NFS mount
Sending all processes the TERM signal...
Sending all processes the KILL signal...
hwclock: can't open '/dev/misc/rtc': No such file or directory
Unmounting remote filesystems...
Deactivating swap...
/etc/rc6.d/S40umountfs: line 9: swapoff: not found
Unmounting local filesystems...
umount2: Device or resource busy
umount: none busy - remounted read-only
Rebooting... Restarting system. <--------------- Target
hangs here..
-----------------------------------------------------------------------------------------------------
The target again doesn't provide me the boot options as obtained when done
hard reset :
Welcome to the Xilinx Virtex-5 ML507 Evaluation Platform Bootloader
Menu!
Please choose a demo by typing in the number of the demo you want to
use
Or select a demo using the directional buttons (C,W,S,E,N)
(Then press the center (C) button to start the selected demo)
1. Virtex-5 Slide Show
2. Web Server Demo
3. Simon Game
4. Board Diagnostics (XROM)
5. USB Demo
6. My own ACE file
7. Ring Tone Player
Rebooting to System ACE Configuration Address 6...
zImage starting: loaded at 0x00800000 (sp: 0x00a44fb0)
Allocating 0x4e9138 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080e000:0x00a437cc)...done 0x4a1bcc bytes
Any comments or suggestions are appreciated !!
Thanks
-Sriknt
[-- Attachment #2: Type: text/html, Size: 2616 bytes --]
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 9:16 UTC (permalink / raw)
To: mingo
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, Ian.Campbell,
linuxppc-dev, joerg.roedel
In-Reply-To: <20090713131157V.fujita.tomonori@lab.ntt.co.jp>
On Mon, 13 Jul 2009 13:20:22 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> On Fri, 10 Jul 2009 16:12:48 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > > functionality and reimplemented the surrounding infrastructure in
> > > terms of that (and incorporating our additional requirements). I
> > > prototyped this (it is currently unworking, in fact it seems to
> > > have developed rather a taste for filesystems :-() but the
> > > diffstat of my WIP patch is:
> > >
> > > arch/x86/kernel/pci-swiotlb.c | 6
> > > arch/x86/xen/pci-swiotlb.c | 2
> > > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > > include/linux/swiotlb.h | 12 +
> > > lib/swiotlb.c | 10 -
> > > 5 files changed, 385 insertions(+), 30 deletions(-)
> > >
> > > where a fair number of the lines in xen-iommu.c are copies of
> > > functions from swiotlb.c with minor modifications. As I say it
> > > doesn't work yet but I think it's roughly indicative of what such
> > > an approach would look like. I don't like it much but am happy to
> > > run with it if it looks to be the most acceptable approach. [...]
> >
> > +400 lines of code to avoid much fewer lines of generic code impact
> > on the lib/swiotlb.c side sounds like a bad technical choice to me.
>
> The amount of code is not the point. The way to impact on the
> lib/swiotlb.c is totally wrong from the perspective of the kernel
> design; it uses architecture code in the very original (xen) way.
btw, '+400 lines of code to avoid much fewer lines of generic code
impact on the lib/swiotlb.c' doesn't sound true to me.
Here is a patch in the way that Xen people want to do:
http://patchwork.kernel.org/patch/26343/
---
arch/x86/Kconfig | 4 +
arch/x86/include/asm/io.h | 2 +
arch/x86/include/asm/pci_x86.h | 1 +
arch/x86/include/asm/xen/iommu.h | 12 ++
arch/x86/kernel/pci-dma.c | 3 +
arch/x86/pci/Makefile | 1 +
arch/x86/pci/init.c | 6 +
arch/x86/pci/xen.c | 51 +++++++
drivers/pci/Makefile | 2 +
drivers/pci/xen-iommu.c | 271 ++++++++++++++++++++++++++++++++++++++
Even with the way that Xen people want to do, drivers/pci/xen-iommu.c
is about 300 lines. And my patchset removes the nice amount of lines
for dom0 support. I don't see much difference wrt lines.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-13 9:40 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy@goop.org, tony.luck@intel.com, linux-ia64@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, joerg.roedel@amd.com, mingo@elte.hu
In-Reply-To: <20090713131859N.fujita.tomonori@lab.ntt.co.jp>
On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> On Fri, 10 Jul 2009 15:02:00 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > I don't think that we need to take account of dom0 support; we don't
> > > have a clear idea about an acceptable dom0 design (it needs to use
> > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > support in mainline. That's why I didn't CC this patchset to Xen
> > > camp.
> >
> > The core domain 0 patches which were the subject of the discussions a
> > few week back are completely orthogonal to the swiotlb side of things
>
> ? If we don't merge dom0 patch, we don't need dom0 changes to
> swiotlb. We don't know we would have dom0 support in mainline. Or I
> overlooked something?
[...]
> As far as I know, you have not posted anything about changes to
> swiotlb for domU. I can't discuss it. If you want, please send
> patches.
There are no separate domU swiotlb patches -- the exact the same patches
as we have already been discussing are useful and necessary for both
domU and dom0.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 9:53 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, fujita.tomonori,
linuxppc-dev, joerg.roedel, mingo
In-Reply-To: <1247478029.11668.10.camel@zakaz.uk.xensource.com>
On Mon, 13 Jul 2009 10:40:29 +0100
Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> > On Fri, 10 Jul 2009 15:02:00 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > > I don't think that we need to take account of dom0 support; we don't
> > > > have a clear idea about an acceptable dom0 design (it needs to use
> > > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > > support in mainline. That's why I didn't CC this patchset to Xen
> > > > camp.
> > >
> > > The core domain 0 patches which were the subject of the discussions a
> > > few week back are completely orthogonal to the swiotlb side of things
> >
> > ? If we don't merge dom0 patch, we don't need dom0 changes to
> > swiotlb. We don't know we would have dom0 support in mainline. Or I
> > overlooked something?
> [...]
> > As far as I know, you have not posted anything about changes to
> > swiotlb for domU. I can't discuss it. If you want, please send
> > patches.
>
> There are no separate domU swiotlb patches -- the exact the same patches
> as we have already been discussing are useful and necessary for both
> domU and dom0.
Hmm, you guys introduced the swiotlb hooks by saying that it's for
only dom0.
=
http://lkml.org/lkml/2008/12/16/351
Hi Ingo,
Here's some patches to clean up swiotlb to prepare for some Xen dom0
patches. These have been posted before, but undergone a round of
cleanups to address various comments.
=
I don't see any comments like 'this is useful to dom0 too'. I'm still
not sure what exactly part is useful to domU.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-13 10:05 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, linuxppc-dev,
joerg.roedel, mingo
In-Reply-To: <20090713185247W.fujita.tomonori@lab.ntt.co.jp>
On Mon, 2009-07-13 at 18:53 +0900, FUJITA Tomonori wrote:
> On Mon, 13 Jul 2009 10:40:29 +0100
> Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
>
> > On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> > > On Fri, 10 Jul 2009 15:02:00 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >
> > > > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > > > I don't think that we need to take account of dom0 support; we don't
> > > > > have a clear idea about an acceptable dom0 design (it needs to use
> > > > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > > > support in mainline. That's why I didn't CC this patchset to Xen
> > > > > camp.
> > > >
> > > > The core domain 0 patches which were the subject of the discussions a
> > > > few week back are completely orthogonal to the swiotlb side of things
> > >
> > > ? If we don't merge dom0 patch, we don't need dom0 changes to
> > > swiotlb. We don't know we would have dom0 support in mainline. Or I
> > > overlooked something?
> > [...]
> > > As far as I know, you have not posted anything about changes to
> > > swiotlb for domU. I can't discuss it. If you want, please send
> > > patches.
> >
> > There are no separate domU swiotlb patches -- the exact the same patches
> > as we have already been discussing are useful and necessary for both
> > domU and dom0.
>
> Hmm, you guys introduced the swiotlb hooks by saying that it's for
> only dom0.
That was just sloppy wording on our part. domain 0 is the major usecase
today so there is a tendency to think in those terms but the changes are
actually relevant to any domain with access to a physical device that
can do DMA, this includes domU via PCI passthrough.
> I don't see any comments like 'this is useful to dom0 too'. I'm still
^U?
> not sure what exactly part is useful to domU.
All of it...
Ian.
^ permalink raw reply
* Re: mmap() problem in own driver
From: Arnd Bergmann @ 2009-07-13 14:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sauce.Cheng
In-Reply-To: <24457031.post@talk.nabble.com>
On Monday 13 July 2009, Sauce.Cheng wrote:
> I want to get data from kernel space to user space indirectly using mmap()
> but i dont know how I can do , anyone can give me some advices ?
>
> firstly, fetch data by DMA to a memory allocated by "kmalloc"
> then i want to mmap it to user space and save the data as a file
You first need to allocate full pages, e.g. using alloc_pages() instead
of kmalloc, which may not be aligned. To get a streaming mapping on
that memory, use dma_map_single(), which returns a DMA address you
can pass to the device.
For user space access, the easiest is to have a character device,
which uses an mmap() file operation that calls remap_pfn_range()
on the page_to_pfn(pages).
Arnd <><
^ permalink raw reply
* SPI driver on mpc5121
From: Canella Matteo @ 2009-07-13 14:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I'm on a mpc5121 platform, kernel 2.6.24.6, and I'm using the mpc512x_psc_s=
pi driver to communicate =A0with a touch screen controller.
I'm sending commands and reading data from the controller using 24-bit pack=
et (3 bytes).
The speed of the SPI is set to 640 KHz.
I thought that I would need 8/640K =3D 12,5 us each byte I send, but this i=
s not true.
I'm verifying the time needed by mpc512x_psc_spi_transfer_rxtx function in =
order to send one byte toggling a digital output when it sets the TX/RX fla=
gs (after it copies data in the transmission buffer) and toggling the outpu=
t again when the empty buffer interrupt is triggered.
I see that the actual 12,5us data transfer is preceded by a 20us delay and =
followed by another 15,6us delay. So the transfer is done in almost 50 us.
Is this a normal behavior? Does the PSC controller need this overhead in th=
e transfer time?
DSCKI and DTL delays are set to zero.
Another doubt I have:
In mpc512x_psc_spi_transfer_rxtx, Mode Register 2 of the PSC is set to zero=
. This is done (as manual says) by access to MR1 (by a read) and then write=
a zero on the same address.:
in_8(&psc->mode);
mdelay(1);
out_8(&psc->mode, 0x0);
mdelay(1);
I don't understand why a 1ms delay is needed. The manual doesn't say anythi=
ng about this.
I tried to comment out these delays and anyway it seems to work correctly.
Best regards,
Matteo Canella
^ 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