* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-23 10:02 UTC (permalink / raw)
To: LiuShuo
Cc: Scott Wood, linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
Li Yang-R58472, linux-mtd@lists.infradead.org
In-Reply-To: <4E5366AF.7040108@freescale.com>
LiuShuo a écrit :
> 于 2011年08月19日 00:25, Scott Wood 写道:
>> On 08/17/2011 09:33 PM, b35362@freescale.com wrote:
>>> From: Liu Shuo<b35362@freescale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>> we divide a page into multi-2K pages for MTD layer driver. In that case,
>>> we force to set the page size to 2K bytes. We convert the page address of
>>> MTD layer driver to a real page address in flash chips and a column index
>>> in fsl_elbc driver. We can issue any column address by UA instruction of
>>> elbc controller.
>>>
>>> NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
>>> the Same Page (NOP)', the flash chip which is supported by this workaround
>>> have to meet below conditions.
>>> 1. page size is not greater than 4KB
>>> 2. 1) if main area and spare area have independent NOPs:
>>> main area NOP :>=3
>>> spare area NOP :>=2?
>> How often are the NOPs split like this?
>>
>>> 2) if main area and spare area have a common NOP:
>>> NOP :>=4
>> This depends on how the flash is used. If you treat it as a NOP1 flash
>> (e.g. run ubifs rather than jffs2), then you need NOP2 for a 4K chip and
>> NOP4 for an 8K chip. OTOH, if you would be making full use of NOP4 on a
>> real 2K chip, you'll need NOP8 for a 4K chip.
>>
>> The NOP restrictions should be documented in the code itself, not just
>> in the git changelog. Maybe print it to the console when this hack is
>> used, along with the NOP value read from the ID.
>
> We can't read the NOP from the ID on any chip. Some chips don't
> give this infomation.(e.g. Micron MT29F4G08BAC)
Doesn't the micron chip provide it with onfi info ?
Matthieu
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-08-23 9:57 UTC (permalink / raw)
To: Matthieu CASTET
Cc: Li Yang-R58472, Artem Bityutskiy, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org, Scott Wood, Ivan Djelic,
dwmw2@infradead.org
In-Reply-To: <4E53614E.2070103@parrot.com>
=E4=BA=8E 2011=E5=B9=B408=E6=9C=8823=E6=97=A5 16:14, Matthieu CASTET =E5=86=
=99=E9=81=93:
> LiuShuo a =C3=A9crit :
>> =E4=BA=8E 2011=E5=B9=B408=E6=9C=8823=E6=97=A5 00:19, Scott Wood =E5=86=
=99=E9=81=93:
>>> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>>>> Scott Wood a =C3=A9crit :
>>>>> To eliminate it we'd need to do an extra data transfer without reis=
suing
>>>>> the command, which Shuo was unable to get to work.
>>>>>
>>>> That's weird because our controller seems quite flexible [1].
>>>>
>>>> Something like that should work ?
>>>>
>>>> out_be32(&lbc->fir,
>>>> (FIR_OP_CM2<< FIR_OP0_SHIFT) |
>>>> (FIR_OP_CA<< FIR_OP1_SHIFT) |
>>>> (FIR_OP_PA<< FIR_OP2_SHIFT) |
>>>> (FIR_OP_WB<< FIR_OP3_SHIFT));
>>>> refill FCM buffer with next 2k data
>>>>
>>>> out_be32(&lbc->fir,
>>>> (FIR_OP_WB<< FIR_OP3_SHIFT) |
>>>> (FIR_OP_CM3<< FIR_OP4_SHIFT) |
>>>> (FIR_OP_CW1<< FIR_OP5_SHIFT) |
>>>> (FIR_OP_RS<< FIR_OP6_SHIFT));
>>> Something like that is what I originally suggested, but Shuo said it
>>> didn't work (even in theory, it requires a CE-don't-care NAND chip,
>>> since bus atomicity is broken).
>>>
>>> Shuo, what specifically did you try, and what did you see happen?
>>>
>>> -Scott
>> First, if we want to read 4K data with once command issuing, we can't
>> use HW_ECC.
> Yes, but as ivan said doesn't the cost of 2 read isn't bigger than soft=
ware ecc ?
>
>> Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st
>> 2k and 2nd 2k data.
> Did you understand where those 0xff comes (what's the size of them. Doe=
sn't the
> controller try to insert spare aera ?)
I don't understand. I set FBCR to 2048, the controller will read the=20
main area without spare area.
But the size of them is nearly spare area size( more or less a few bytes)=
.
I can't guess the behavior of the controller then, so I select another wa=
y.
Could you try to do it and explain how those 0xff comes ?
> Could you detail the sequence you used ?
>
First half :
out_be32(&lbc->fbcr, 2048);
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
(FIR_OP_CA << FIR_OP1_SHIFT) |
(FIR_OP_PA << FIR_OP2_SHIFT) |
(FIR_OP_CM1 << FIR_OP3_SHIFT) |
(FIR_OP_RBW << FIR_OP4_SHIFT));
Sencond half :
out_be32(&lbc->fbcr, 2048);
out_be32(&lbc->fir,
(FIR_OP_RB << FIR_OP0_SHIFT) |
(FIR_OP_RBW << FIR_OP1_SHIFT));
-Liu Shuo
> Matthieu
>
>
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: K.Prasad @ 2011-08-23 9:27 UTC (permalink / raw)
To: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110823050931.GT30097@yookeroo.fritz.box>
On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote:
> On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote:
> >
> > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> > user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> > "features" member of "struct ppc_debug_info" to advertise support for the
> > same on Book3E PowerPC processors.
>
> I thought the idea was that the BP_EXACT mode was the default - if the
> new interface was supported at all, then BP_EXACT was always
> supported. So, why do you need a new flag?
>
Yes, BP_EXACT was always supported but not advertised through
PPC_PTRACE_GETHWDBGINFO. We're now doing that.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-08-23 9:25 UTC (permalink / raw)
To: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110823050850.GS30097@yookeroo.fritz.box>
On Tue, Aug 23, 2011 at 03:08:50PM +1000, David Gibson wrote:
> On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
> > PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> > PowerPC specific ptrace flags that use the watchpoint register. While they are
> > targeted primarily towards BookE users, user-space applications such as GDB
> > have started using them for BookS too.
> >
> > This patch enables the use of generic hardware breakpoint interfaces for these
> > new flags. The version number of the associated data structures
> > "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
>
> So, the structure itself doesn't seem to have been extended. I don't
> understand what the semantic difference is - your patch comment needs
> to explain this clearly.
>
We had a request to extend the structure but thought it was dangerous to
do so. For instance if the user-space used version1 of the structure,
while kernel did a copy_to_user() pertaining to version2, then we'd run
into problems. Unfortunately the ptrace flags weren't designed to accept
a version number as input from the user through the
PPC_PTRACE_GETHWDBGINFO flag (which would have solved this issue).
I'll add a comment w.r.t change in semantics - such as the ability to
accept 'range' breakpoints in BookS.
> > Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> > changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> > their watchpoint needs and allow more precise breakpoint specification (length
> > of the variable can be specified).
>
> What is the mechanism for implementing the range breakpoint on book3s?
>
The hw-breakpoint interface, accepts length as an argument in BookS (any
value <= 8 Bytes) and would filter out extraneous interrupts arising out
of accesses outside the range comprising <addr, addr + len> inside
hw_breakpoint_handler function.
We put that ability to use here.
> > [Edjunior: Identified an issue in the patch with the sanity check for version
> > numbers]
> >
> > Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> > ---
> > Documentation/powerpc/ptrace.txt | 16 ++++++
> > arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++---
> > 2 files changed, 112 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
> > index f4a5499..97301ae 100644
> > --- a/Documentation/powerpc/ptrace.txt
> > +++ b/Documentation/powerpc/ptrace.txt
> > @@ -127,6 +127,22 @@ Some examples of using the structure to:
> > p.addr2 = (uint64_t) end_range;
> > p.condition_value = 0;
> >
> > +- set a watchpoint in server processors (BookS) using version 2
> > +
> > + p.version = 2;
> > + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> > + or
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
> > +
> > + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> > + p.addr = (uint64_t) begin_range;
> > + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
> > + * addr2 - addr <= 8 Bytes.
> > + */
> > + p.addr2 = (uint64_t) end_range;
> > + p.condition_value = 0;
> > +
> > 3. PTRACE_DELHWDEBUG
> >
> > Takes an integer which identifies an existing breakpoint or watchpoint
> > diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> > index 05b7dd2..18d28b6 100644
> > --- a/arch/powerpc/kernel/ptrace.c
> > +++ b/arch/powerpc/kernel/ptrace.c
> > @@ -1339,11 +1339,17 @@ static int set_dac_range(struct task_struct *child,
> > static long ppc_set_hwdebug(struct task_struct *child,
> > struct ppc_hw_breakpoint *bp_info)
> > {
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + int ret, len = 0;
> > + struct thread_struct *thread = &(child->thread);
> > + struct perf_event *bp;
> > + struct perf_event_attr attr;
> > +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
>
> I'm confused. This compiled before on book3s, and I don't see any
> changes to Makefile or Kconfig in the patch that will result in this
> code compiling when it previously didn't Why are these new guards
> added?
>
The code is guarded using the CONFIG_ flags for two reasons.
a) We don't want the code to be included for BookE and other
architectures.
b) In BookS, we're now adding a new ability based on whether
CONFIG_HAVE_HW_BREAKPOINT is defined. Presently this config option is
kept on by default, however there are plans to make this a config-time
option.
> > #ifndef CONFIG_PPC_ADV_DEBUG_REGS
> > unsigned long dabr;
> > #endif
> >
> > - if (bp_info->version != 1)
> > + if ((bp_info->version != 1) && (bp_info->version != 2))
> > return -ENOTSUPP;
> > #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> > /*
> > @@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > */
> > if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
> > (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
> > - bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
> > bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
> > return -EINVAL;
> >
> > - if (child->thread.dabr)
> > - return -ENOSPC;
> > -
>
> You remove this test to see if the single watchpoint slot is already
> in use, but I don't see another test replacing it.
>
This test is retained for !CONFIG_HAVE_HW_BREAKPOINT case. In case of
using hw-breakpoint interfaces, we have a double check through
thread->ptrace_bps[0] and using register_user_hw_breakpoint function
(which would error out if not enough free slots are available).
> > if ((unsigned long)bp_info->addr >= TASK_SIZE)
> > return -EIO;
> >
> > @@ -1398,15 +1400,86 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > dabr |= DABR_DATA_READ;
> > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> > dabr |= DABR_DATA_WRITE;
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + if (bp_info->version == 1)
> > + goto version_one;
>
> There are several legitimate uses of goto in the kernel, but this is
> definitely not one of them. You're essentially using it to put the
> old and new versions of the same function in one block. Nasty.
>
Maybe it's the label that's causing bother here. It might look elegant
if it was called something like exit_* or error_* :-)
The goto here helps reduce code, is similar to the error exits we use
everywhere.
> > + if (ptrace_get_breakpoints(child) < 0)
> > + return -ESRCH;
> >
> > - child->thread.dabr = dabr;
> > + bp = thread->ptrace_bps[0];
> > + if (!bp_info->addr) {
> > + if (bp) {
> > + unregister_hw_breakpoint(bp);
> > + thread->ptrace_bps[0] = NULL;
> > + }
> > + ptrace_put_breakpoints(child);
> > + return 0;
>
> Why are you making setting a 0 watchpoint remove the existing one (I
> think that's what this does). I thought there was an explicit del
> breakpoint operation instead.
>
We had to define the semantics for what writing a 0 to DABR could mean,
and I think it is intuitive to consider it as deletion
request...couldn't think of a case where DABR with addr=0 and RW=1 would
be required.
> > + }
> > + /*
> > + * Check if the request is for 'range' breakpoints. We can
> > + * support it if range < 8 bytes.
> > + */
> > + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> > + len = bp_info->addr2 - bp_info->addr;
>
> So you compute the length here, but I don't see you ever test if it is
> < 8 and return an error.
>
The hw-breakpoint interfaces would fail if the length was > 8.
> > + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> > + ptrace_put_breakpoints(child);
> > + return -EINVAL;
> > + }
> > + if (bp) {
> > + attr = bp->attr;
> > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > + arch_bp_generic_fields(dabr &
> > + (DABR_DATA_WRITE | DABR_DATA_READ),
> > + &attr.bp_type);
> > + attr.bp_len = len;
> > + ret = modify_user_hw_breakpoint(bp, &attr);
> > + if (ret) {
> > + ptrace_put_breakpoints(child);
> > + return ret;
> > + }
> > + thread->ptrace_bps[0] = bp;
> > + ptrace_put_breakpoints(child);
> > + thread->dabr = dabr;
> > + return 0;
> > + }
> >
> > + /* Create a new breakpoint request if one doesn't exist already */
> > + hw_breakpoint_init(&attr);
> > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
>
> You seem to be silently masking the given address, which seems
> completely wrong.
>
We have two ways of looking at the input address.
a) Assume that the input address is not multiplexed with the read/write
bits and return -EINVAL (for not confirming to the 8-byte alignment
requirement).
b) Consider the input address to be encoded with the read/write
watchpoint type request and align the address by default. This is how
the code behaves presently for the !CONFIG_HAVE_HW_BREAKPOINT case.
I chose to go with b) and discard the last 3-bits from the address.
Thanks for the detailed review. Looking forward for your comments.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH] SPI: fix build with CONFIG_SPI_FSL_ESPI=m
From: Jiri Slaby @ 2011-08-23 8:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: spi-devel-general, linuxppc-dev, linux-kernel
In-Reply-To: <1314086345-2818-1-git-send-email-jslaby@suse.cz>
On 08/23/2011 09:59 AM, Jiri Slaby wrote:
> When spi_fsl_espi is chosen to be built as a module, there is a build
> error because we test only CONFIG_SPI_FSL_ESPI in declaration of
> struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h.
>
> We need to add a test for CONFIG_SPI_FSL_ESPI_MODULE too.
>
> The error looks like:
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_bufs':
> drivers/spi/spi_fsl_espi.c:232: error: 'struct mpc8xxx_spi' has no member named 'len'
> ...
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> ---
> drivers/spi/spi-fsl-lib.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-lib.h b/drivers/spi/spi-fsl-lib.h
> index cbe881b..97968de 100644
> --- a/drivers/spi/spi-fsl-lib.h
> +++ b/drivers/spi/spi-fsl-lib.h
> @@ -28,7 +28,7 @@ struct mpc8xxx_spi {
> /* rx & tx bufs from the spi_transfer */
> const void *tx;
> void *rx;
> -#ifdef CONFIG_SPI_FSL_ESPI
> +#if defined(CONFIG_SPI_FSL_ESPI) || defined(CONFIG_SPI_FSL_ESPI_MODULE)
> int len;
> #endif
Oh, and there are still link errors:
ERROR: "mpc8xxx_spi_tx_buf_u32" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_rx_buf_u32" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_tx_buf_u16" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_rx_buf_u16" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_tx_buf_u8" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_rx_buf_u8" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "of_mpc8xxx_spi_probe" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_strmode" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_probe" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_remove" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "to_of_pinfo" [drivers/spi/spi_fsl_spi.ko] undefined!
ERROR: "mpc8xxx_spi_tx_buf_u32" [drivers/spi/spi_fsl_espi.ko] undefined!
ERROR: "mpc8xxx_spi_rx_buf_u32" [drivers/spi/spi_fsl_espi.ko] undefined!
ERROR: "of_mpc8xxx_spi_probe" [drivers/spi/spi_fsl_espi.ko] undefined!
ERROR: "mpc8xxx_spi_probe" [drivers/spi/spi_fsl_espi.ko] undefined!
ERROR: "mpc8xxx_spi_remove" [drivers/spi/spi_fsl_espi.ko] undefined!
The functions are not exported...
Should I export all those or deny CONFIG_SPI_FSL_ESPI=m?
thanks,
--
js
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Jeff Kirsher @ 2011-08-23 8:29 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, mikey@neuling.org,
linux-kbuild@vger.kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-next@vger.kernel.org, paulus@samba.org, lacombar@gmail.com,
akpm@linux-foundation.org, torvalds@linux-foundation.org
In-Reply-To: <20110822.210255.1902105215409964106.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Mon, 2011-08-22 at 21:02 -0700, David Miller wrote:
> From: Arnaud Lacombe <lacombar@gmail.com>
> Date: Mon, 22 Aug 2011 23:50:02 -0400
>
> > Are you implying we need some kind of way to migrate config ?
>
> The issue is that the dependencies for every single ethernet driver
> have changed. Some dependencies have been dropped (f.e. NETDEV_10000
> and some have been added (f.e. ETHERNET, NET_VENDOR_****)
>
> So right now an automated (non-prompted, default to no on all new
> options) run on an existing config results in all ethernet drivers
> getting disabled because the new dependencies don't get enabled.
>
> This wouldn't be so bad if it was just one or two drivers, but in
> this case it's every single ethernet driver which will have and hit
> this problem.
>
Ok, I have patch which will resolve the issue. It is the last patch in
the series I am about to send out. What this patch does is set the
"new" Kconfig options to Y, so that current defconfig's can build
driver's that are currently set to build.
This will fix the issue, I have confirmed this with the x86_64
defconfig. It will be nice that eventually all configs get updated so
that not all the NET_VENDOR_* tags have to be enabled, but
understandably this is the best way to ensure that current defconfig's
will compile all expected drivers.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-08-23 8:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, Li Yang-R58472, linux-mtd
In-Reply-To: <4E4D3CE0.7020602@freescale.com>
=E4=BA=8E 2011=E5=B9=B408=E6=9C=8819=E6=97=A5 00:25, Scott Wood =E5=86=99=
=E9=81=93:
> On 08/17/2011 09:33 PM, b35362@freescale.com wrote:
>> From: Liu Shuo<b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> to support the Nand flash chip whose page size is larger than 2K bytes=
,
>> we divide a page into multi-2K pages for MTD layer driver. In that cas=
e,
>> we force to set the page size to 2K bytes. We convert the page address=
of
>> MTD layer driver to a real page address in flash chips and a column in=
dex
>> in fsl_elbc driver. We can issue any column address by UA instruction =
of
>> elbc controller.
>>
>> NOTE: Due to there is a limitation of 'Number of Partial Program Cycle=
s in
>> the Same Page (NOP)', the flash chip which is supported by this workar=
ound
>> have to meet below conditions.
>> 1. page size is not greater than 4KB
>> 2. 1) if main area and spare area have independent NOPs:
>> main area NOP :>=3D3
>> spare area NOP :>=3D2?
> How often are the NOPs split like this?
>
>> 2) if main area and spare area have a common NOP:
>> NOP :>=3D4
> This depends on how the flash is used. If you treat it as a NOP1 flash
> (e.g. run ubifs rather than jffs2), then you need NOP2 for a 4K chip an=
d
> NOP4 for an 8K chip. OTOH, if you would be making full use of NOP4 on =
a
> real 2K chip, you'll need NOP8 for a 4K chip.
>
> The NOP restrictions should be documented in the code itself, not just
> in the git changelog. Maybe print it to the console when this hack is
> used, along with the NOP value read from the ID.
We can't read the NOP from the ID on any chip. Some chips don't
give this infomation.(e.g. Micron MT29F4G08BAC)
So it is hard to determine whether the probe() should fail in the code.
Maybe we will always print the NOP restrictions when this hack is used,
let the customers select how to use the flash on their board.
-LiuShuo
> If it's less than 4
> for 4K or 8 for 8K, also print a message saying not to use jffs2 (does
> yaffs2 do similar things?). If it's less than 2 for 4K or 4 for 8K, th=
e
> probe should fail.
>
> -Scott
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-23 8:14 UTC (permalink / raw)
To: LiuShuo
Cc: Li Yang-R58472, Artem Bityutskiy, linuxppc-dev@ozlabs.org,
linux-mtd@lists.infradead.org, Scott Wood, Ivan Djelic,
dwmw2@infradead.org
In-Reply-To: <4E5319E8.50903@freescale.com>
LiuShuo a écrit :
> 于 2011年08月23日 00:19, Scott Wood 写道:
>> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>>> Scott Wood a écrit :
>>>> To eliminate it we'd need to do an extra data transfer without reissuing
>>>> the command, which Shuo was unable to get to work.
>>>>
>>> That's weird because our controller seems quite flexible [1].
>>>
>>> Something like that should work ?
>>>
>>> out_be32(&lbc->fir,
>>> (FIR_OP_CM2<< FIR_OP0_SHIFT) |
>>> (FIR_OP_CA<< FIR_OP1_SHIFT) |
>>> (FIR_OP_PA<< FIR_OP2_SHIFT) |
>>> (FIR_OP_WB<< FIR_OP3_SHIFT));
>>> refill FCM buffer with next 2k data
>>>
>>> out_be32(&lbc->fir,
>>> (FIR_OP_WB<< FIR_OP3_SHIFT) |
>>> (FIR_OP_CM3<< FIR_OP4_SHIFT) |
>>> (FIR_OP_CW1<< FIR_OP5_SHIFT) |
>>> (FIR_OP_RS<< FIR_OP6_SHIFT));
>> Something like that is what I originally suggested, but Shuo said it
>> didn't work (even in theory, it requires a CE-don't-care NAND chip,
>> since bus atomicity is broken).
>>
>> Shuo, what specifically did you try, and what did you see happen?
>>
>> -Scott
> First, if we want to read 4K data with once command issuing, we can't
> use HW_ECC.
Yes, but as ivan said doesn't the cost of 2 read isn't bigger than software ecc ?
> Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st
> 2k and 2nd 2k data.
Did you understand where those 0xff comes (what's the size of them. Doesn't the
controller try to insert spare aera ?)
Could you detail the sequence you used ?
Matthieu
^ permalink raw reply
* [PATCH] SPI: fix build with CONFIG_SPI_FSL_ESPI=m
From: Jiri Slaby @ 2011-08-23 7:59 UTC (permalink / raw)
To: grant.likely
Cc: spi-devel-general, Jiri Slaby, linuxppc-dev, linux-kernel,
jirislaby
When spi_fsl_espi is chosen to be built as a module, there is a build
error because we test only CONFIG_SPI_FSL_ESPI in declaration of
struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h.
We need to add a test for CONFIG_SPI_FSL_ESPI_MODULE too.
The error looks like:
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_bufs':
drivers/spi/spi_fsl_espi.c:232: error: 'struct mpc8xxx_spi' has no member named 'len'
...
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/spi/spi-fsl-lib.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-fsl-lib.h b/drivers/spi/spi-fsl-lib.h
index cbe881b..97968de 100644
--- a/drivers/spi/spi-fsl-lib.h
+++ b/drivers/spi/spi-fsl-lib.h
@@ -28,7 +28,7 @@ struct mpc8xxx_spi {
/* rx & tx bufs from the spi_transfer */
const void *tx;
void *rx;
-#ifdef CONFIG_SPI_FSL_ESPI
+#if defined(CONFIG_SPI_FSL_ESPI) || defined(CONFIG_SPI_FSL_ESPI_MODULE)
int len;
#endif
--
1.7.6
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: Benjamin Herrenschmidt @ 2011-08-23 6:54 UTC (permalink / raw)
To: aafabbri
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, iommu, chrisw,
Alex Williamson, Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <CA7847D2.FB3A%aafabbri@cisco.com>
On Mon, 2011-08-22 at 17:52 -0700, aafabbri wrote:
> I'm not following you.
>
> You have to enforce group/iommu domain assignment whether you have the
> existing uiommu API, or if you change it to your proposed
> ioctl(inherit_iommu) API.
>
> The only change needed to VFIO here should be to make uiommu fd assignment
> happen on the groups instead of on device fds. That operation fails or
> succeeds according to the group semantics (all-or-none assignment/same
> uiommu).
Ok, so I missed that part where you change uiommu to operate on group
fd's rather than device fd's, my apologies if you actually wrote that
down :-) It might be obvious ... bare with me I just flew back from the
US and I am badly jet lagged ...
So I see what you mean, however...
> I think the question is: do we force 1:1 iommu/group mapping, or do we allow
> arbitrary mapping (satisfying group constraints) as we do today.
>
> I'm saying I'm an existing user who wants the arbitrary iommu/group mapping
> ability and definitely think the uiommu approach is cleaner than the
> ioctl(inherit_iommu) approach. We considered that approach before but it
> seemed less clean so we went with the explicit uiommu context.
Possibly, the question that interest me the most is what interface will
KVM end up using. I'm also not terribly fan with the (perceived)
discrepancy between using uiommu to create groups but using the group fd
to actually do the mappings, at least if that is still the plan.
If the separate uiommu interface is kept, then anything that wants to be
able to benefit from the ability to put multiple devices (or existing
groups) into such a "meta group" would need to be explicitly modified to
deal with the uiommu APIs.
I tend to prefer such "meta groups" as being something you create
statically using a configuration interface, either via sysfs, netlink or
ioctl's to a "control" vfio device driven by a simple command line tool
(which can have the configuration stored in /etc and re-apply it at
boot).
That way, any program capable of exploiting VFIO "groups" will
automatically be able to exploit those "meta groups" (or groups of
groups) as well as long as they are supported on the system.
If we ever have system specific constraints as to how such groups can be
created, then it can all be handled at the level of that configuration
tool without impact on whatever programs know how to exploit them via
the VFIO interfaces.
> > .../...
> >
> >> If we in singleton-group land were building our own "groups" which were sets
> >> of devices sharing the IOMMU domains we wanted, I suppose we could do away
> >> with uiommu fds, but it sounds like the current proposal would create 20
> >> singleton groups (x86 iommu w/o PCI bridges => all devices are partitionable
> >> endpoints). Asking me to ioctl(inherit) them together into a blob sounds
> >> worse than the current explicit uiommu API.
> >
> > I'd rather have an API to create super-groups (groups of groups)
> > statically and then you can use such groups as normal groups using the
> > same interface. That create/management process could be done via a
> > simple command line utility or via sysfs banging, whatever...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: David Gibson @ 2011-08-23 5:09 UTC (permalink / raw)
To: K.Prasad; +Cc: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110819075338.GC21817@in.ibm.com>
On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote:
>
> While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> "features" member of "struct ppc_debug_info" to advertise support for the
> same on Book3E PowerPC processors.
I thought the idea was that the BP_EXACT mode was the default - if the
new interface was supported at all, then BP_EXACT was always
supported. So, why do you need a new flag?
>
> Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/ptrace.h | 1 +
> arch/powerpc/kernel/ptrace.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 48223f9..cf014f9 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -380,6 +380,7 @@ struct ppc_debug_info {
> #define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x0000000000000002
> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x0000000000000004
> #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0000000000000008
> +#define PPC_DEBUG_FEATURE_DATA_BP_EXACT 0x0000000000000010
>
> #ifndef __ASSEMBLY__
>
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 18d28b6..71db5a6 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -1636,6 +1636,7 @@ long arch_ptrace(struct task_struct *child, long request,
> #ifdef CONFIG_PPC_ADV_DEBUG_DAC_RANGE
> dbginfo.features |=
> PPC_DEBUG_FEATURE_DATA_BP_RANGE |
> + PPC_DEBUG_FEATURE_DATA_BP_EXACT |
> PPC_DEBUG_FEATURE_DATA_BP_MASK;
> #endif
> #else /* !CONFIG_PPC_ADV_DEBUG_REGS */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: David Gibson @ 2011-08-23 5:08 UTC (permalink / raw)
To: K.Prasad; +Cc: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110819075136.GB21817@in.ibm.com>
On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
> PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> PowerPC specific ptrace flags that use the watchpoint register. While they are
> targeted primarily towards BookE users, user-space applications such as GDB
> have started using them for BookS too.
>
> This patch enables the use of generic hardware breakpoint interfaces for these
> new flags. The version number of the associated data structures
> "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
So, the structure itself doesn't seem to have been extended. I don't
understand what the semantic difference is - your patch comment needs
to explain this clearly.
> Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> their watchpoint needs and allow more precise breakpoint specification (length
> of the variable can be specified).
What is the mechanism for implementing the range breakpoint on book3s?
> [Edjunior: Identified an issue in the patch with the sanity check for version
> numbers]
>
> Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> ---
> Documentation/powerpc/ptrace.txt | 16 ++++++
> arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++---
> 2 files changed, 112 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
> index f4a5499..97301ae 100644
> --- a/Documentation/powerpc/ptrace.txt
> +++ b/Documentation/powerpc/ptrace.txt
> @@ -127,6 +127,22 @@ Some examples of using the structure to:
> p.addr2 = (uint64_t) end_range;
> p.condition_value = 0;
>
> +- set a watchpoint in server processors (BookS) using version 2
> +
> + p.version = 2;
> + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
> + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> + or
> + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
> +
> + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> + p.addr = (uint64_t) begin_range;
> + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
> + * addr2 - addr <= 8 Bytes.
> + */
> + p.addr2 = (uint64_t) end_range;
> + p.condition_value = 0;
> +
> 3. PTRACE_DELHWDEBUG
>
> Takes an integer which identifies an existing breakpoint or watchpoint
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 05b7dd2..18d28b6 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -1339,11 +1339,17 @@ static int set_dac_range(struct task_struct *child,
> static long ppc_set_hwdebug(struct task_struct *child,
> struct ppc_hw_breakpoint *bp_info)
> {
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + int ret, len = 0;
> + struct thread_struct *thread = &(child->thread);
> + struct perf_event *bp;
> + struct perf_event_attr attr;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
I'm confused. This compiled before on book3s, and I don't see any
changes to Makefile or Kconfig in the patch that will result in this
code compiling when it previously didn't Why are these new guards
added?
> #ifndef CONFIG_PPC_ADV_DEBUG_REGS
> unsigned long dabr;
> #endif
>
> - if (bp_info->version != 1)
> + if ((bp_info->version != 1) && (bp_info->version != 2))
> return -ENOTSUPP;
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> /*
> @@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
> */
> if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
> (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
> - bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
> bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
> return -EINVAL;
>
> - if (child->thread.dabr)
> - return -ENOSPC;
> -
You remove this test to see if the single watchpoint slot is already
in use, but I don't see another test replacing it.
> if ((unsigned long)bp_info->addr >= TASK_SIZE)
> return -EIO;
>
> @@ -1398,15 +1400,86 @@ static long ppc_set_hwdebug(struct task_struct *child,
> dabr |= DABR_DATA_READ;
> if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> dabr |= DABR_DATA_WRITE;
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + if (bp_info->version == 1)
> + goto version_one;
There are several legitimate uses of goto in the kernel, but this is
definitely not one of them. You're essentially using it to put the
old and new versions of the same function in one block. Nasty.
> + if (ptrace_get_breakpoints(child) < 0)
> + return -ESRCH;
>
> - child->thread.dabr = dabr;
> + bp = thread->ptrace_bps[0];
> + if (!bp_info->addr) {
> + if (bp) {
> + unregister_hw_breakpoint(bp);
> + thread->ptrace_bps[0] = NULL;
> + }
> + ptrace_put_breakpoints(child);
> + return 0;
Why are you making setting a 0 watchpoint remove the existing one (I
think that's what this does). I thought there was an explicit del
breakpoint operation instead.
> + }
> + /*
> + * Check if the request is for 'range' breakpoints. We can
> + * support it if range < 8 bytes.
> + */
> + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> + len = bp_info->addr2 - bp_info->addr;
So you compute the length here, but I don't see you ever test if it is
< 8 and return an error.
> + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> + ptrace_put_breakpoints(child);
> + return -EINVAL;
> + }
> + if (bp) {
> + attr = bp->attr;
> + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> + arch_bp_generic_fields(dabr &
> + (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> + attr.bp_len = len;
> + ret = modify_user_hw_breakpoint(bp, &attr);
> + if (ret) {
> + ptrace_put_breakpoints(child);
> + return ret;
> + }
> + thread->ptrace_bps[0] = bp;
> + ptrace_put_breakpoints(child);
> + thread->dabr = dabr;
> + return 0;
> + }
>
> + /* Create a new breakpoint request if one doesn't exist already */
> + hw_breakpoint_init(&attr);
> + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
You seem to be silently masking the given address, which seems
completely wrong.
> + attr.bp_len = len;
> + arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> +
> + thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
> + ptrace_triggered, NULL, child);
> + if (IS_ERR(bp)) {
> + thread->ptrace_bps[0] = NULL;
> + ptrace_put_breakpoints(child);
> + return PTR_ERR(bp);
> + }
> +
> + ptrace_put_breakpoints(child);
> + return 1;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> +
> +version_one:
> + if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
> + return -EINVAL;
> +
> + if (child->thread.dabr)
> + return -ENOSPC;
> +
> + child->thread.dabr = dabr;
> return 1;
> #endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
> }
>
> static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
> {
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + struct thread_struct *thread = &(child->thread);
> + struct perf_event *bp;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> int rc;
>
> @@ -1426,10 +1499,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
> #else
> if (data != 1)
> return -EINVAL;
> +
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + if (ptrace_get_breakpoints(child) < 0)
> + return -ESRCH;
> +
> + bp = thread->ptrace_bps[0];
> + if (bp) {
> + unregister_hw_breakpoint(bp);
> + thread->ptrace_bps[0] = NULL;
> + }
> + ptrace_put_breakpoints(child);
> + return 0;
> +#else /* CONFIG_HAVE_HW_BREAKPOINT */
> if (child->thread.dabr == 0)
> return -ENOENT;
>
> child->thread.dabr = 0;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
>
> return 0;
> #endif
> @@ -1536,7 +1623,8 @@ long arch_ptrace(struct task_struct *child, long request,
> case PPC_PTRACE_GETHWDBGINFO: {
> struct ppc_debug_info dbginfo;
>
> - dbginfo.version = 1;
> + /* We return the highest version number supported */
> + dbginfo.version = 2;
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> dbginfo.num_instruction_bps = CONFIG_PPC_ADV_DEBUG_IACS;
> dbginfo.num_data_bps = CONFIG_PPC_ADV_DEBUG_DACS;
> @@ -1560,7 +1648,7 @@ long arch_ptrace(struct task_struct *child, long request,
> dbginfo.data_bp_alignment = 4;
> #endif
> dbginfo.sizeof_condition = 0;
> - dbginfo.features = 0;
> + dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
> #endif /* CONFIG_PPC_ADV_DEBUG_REGS */
>
> if (!access_ok(VERIFY_WRITE, datavp,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 4:02 UTC (permalink / raw)
To: lacombar
Cc: sfr, mikey, linux-kbuild, netdev, linuxppc-dev, linux-kernel,
linux-next, paulus, jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <CACqU3MW4BnucRt3gxPrKPDvWEjaVuxRF1VOPWk5hTRfneyANkg@mail.gmail.com>
From: Arnaud Lacombe <lacombar@gmail.com>
Date: Mon, 22 Aug 2011 23:50:02 -0400
> Are you implying we need some kind of way to migrate config ?
The issue is that the dependencies for every single ethernet driver
have changed. Some dependencies have been dropped (f.e. NETDEV_10000
and some have been added (f.e. ETHERNET, NET_VENDOR_****)
So right now an automated (non-prompted, default to no on all new
options) run on an existing config results in all ethernet drivers
getting disabled because the new dependencies don't get enabled.
This wouldn't be so bad if it was just one or two drivers, but in
this case it's every single ethernet driver which will have and hit
this problem.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Arnaud Lacombe @ 2011-08-23 3:50 UTC (permalink / raw)
To: David Miller
Cc: sfr, mikey, linux-kbuild, netdev, linuxppc-dev, linux-kernel,
linux-next, paulus, jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
Hi,
[Added linux-kbuild@ to the Cc: list.]
On Mon, Aug 22, 2011 at 10:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
>> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.a=
u> wrote:
>>>
>>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.=
au> wrote:
>>> >
>>> > Here's what I am applying as a merge fixup to the net tree today so t=
hat
>>> > my ppc64_defconfig builds actually build more or less the same set of
>>> > drivers as before this rearrangement.
>>>
>>> And this today:
>>
>> And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig chan=
ges
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. =A0Could you prepare a patch which does tha=
t?
>
Are you implying we need some kind of way to migrate config ?
- Arnaud
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-08-23 3:09 UTC (permalink / raw)
To: Scott Wood
Cc: Li Yang-R58472, Artem Bityutskiy, Matthieu CASTET,
linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Ivan Djelic, dwmw2@infradead.org
In-Reply-To: <4E52819C.8080204@freescale.com>
=E4=BA=8E 2011=E5=B9=B408=E6=9C=8823=E6=97=A5 00:19, Scott Wood =E5=86=99=
=E9=81=93:
> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>> Scott Wood a =C3=A9crit :
>>> To eliminate it we'd need to do an extra data transfer without reissu=
ing
>>> the command, which Shuo was unable to get to work.
>>>
>> That's weird because our controller seems quite flexible [1].
>>
>> Something like that should work ?
>>
>> out_be32(&lbc->fir,
>> (FIR_OP_CM2<< FIR_OP0_SHIFT) |
>> (FIR_OP_CA<< FIR_OP1_SHIFT) |
>> (FIR_OP_PA<< FIR_OP2_SHIFT) |
>> (FIR_OP_WB<< FIR_OP3_SHIFT));
>> refill FCM buffer with next 2k data
>>
>> out_be32(&lbc->fir,
>> (FIR_OP_WB<< FIR_OP3_SHIFT) |
>> (FIR_OP_CM3<< FIR_OP4_SHIFT) |
>> (FIR_OP_CW1<< FIR_OP5_SHIFT) |
>> (FIR_OP_RS<< FIR_OP6_SHIFT));
> Something like that is what I originally suggested, but Shuo said it
> didn't work (even in theory, it requires a CE-don't-care NAND chip,
> since bus atomicity is broken).
>
> Shuo, what specifically did you try, and what did you see happen?
>
> -Scott
First, if we want to read 4K data with once command issuing, we can't=20
use HW_ECC.
Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st=20
2k and 2nd 2k data.
They will cover the data in the head of 2nd 2K.
-----------------------------------------------------------------------=
--------------
| xxxxxx ... 1st 2k xxxxxxx ... | ff ff ff ... ff xxxxxx 2nd 2k xxxxxxx |
-----------------------------------------------------------------------=
--------------
It is worse to write 4k data with once command issuing. It can't write=20
the 2nd data correctly.
-Liu Shuo
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-23 2:38 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1314027950.6866.242.camel@x201.home>
On Mon, Aug 22, 2011 at 09:45:48AM -0600, Alex Williamson wrote:
> On Mon, 2011-08-22 at 15:55 +1000, David Gibson wrote:
> > On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> > > We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> > > capture the plan that I think we agreed to:
> > >
> > > We need to address both the description and enforcement of device
> > > groups. Groups are formed any time the iommu does not have resolution
> > > between a set of devices. On x86, this typically happens when a
> > > PCI-to-PCI bridge exists between the set of devices and the iommu. For
> > > Power, partitionable endpoints define a group. Grouping information
> > > needs to be exposed for both userspace and kernel internal usage. This
> > > will be a sysfs attribute setup by the iommu drivers. Perhaps:
> > >
> > > # cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> > > 42
> > >
> > > (I use a PCI example here, but attribute should not be PCI specific)
> >
> > Ok. Am I correct in thinking these group IDs are representing the
> > minimum granularity, and are therefore always static, defined only by
> > the connected hardware, not by configuration?
>
> Yes, that's the idea. An open question I have towards the configuration
> side is whether we might add iommu driver specific options to the
> groups. For instance on x86 where we typically have B:D.F granularity,
> should we have an option not to trust multi-function devices and use a
> B:D granularity for grouping?
Right. And likewise I can see a place for configuration parameters
like the present 'allow_unsafe_irqs'. But these would be more-or-less
global options which affected the overall granularity, rather than
detailed configuration such as explicitly binding some devices into a
group, yes?
> > > >From there we have a few options. In the BoF we discussed a model where
> > > binding a device to vfio creates a /dev/vfio$GROUP character device
> > > file. This "group" fd provides provides dma mapping ioctls as well as
> > > ioctls to enumerate and return a "device" fd for each attached member of
> > > the group (similar to KVM_CREATE_VCPU). We enforce grouping by
> > > returning an error on open() of the group fd if there are members of the
> > > group not bound to the vfio driver. Each device fd would then support a
> > > similar set of ioctls and mapping (mmio/pio/config) interface as current
> > > vfio, except for the obvious domain and dma ioctls superseded by the
> > > group fd.
> >
> > It seems a slightly strange distinction that the group device appears
> > when any device in the group is bound to vfio, but only becomes usable
> > when all devices are bound.
> >
> > > Another valid model might be that /dev/vfio/$GROUP is created for all
> > > groups when the vfio module is loaded. The group fd would allow open()
> > > and some set of iommu querying and device enumeration ioctls, but would
> > > error on dma mapping and retrieving device fds until all of the group
> > > devices are bound to the vfio driver.
> >
> > Which is why I marginally prefer this model, although it's not a big
> > deal.
>
> Right, we can also combine models. Binding a device to vfio
> creates /dev/vfio$GROUP, which only allows a subset of ioctls and no
> device access until all the group devices are also bound. I think
> the /dev/vfio/$GROUP might help provide an enumeration interface as well
> though, which could be useful.
I'm not entirely sure what you mean here. But, that's now several
weak votes in favour of the always-present group devices, and none in
favour of the created-when-first-device-bound model, so I suggest we
take the /dev/vfio/$GROUP as our tentative approach.
> > > In either case, the uiommu interface is removed entirely since dma
> > > mapping is done via the group fd. As necessary in the future, we can
> > > define a more high performance dma mapping interface for streaming dma
> > > via the group fd. I expect we'll also include architecture specific
> > > group ioctls to describe features and capabilities of the iommu. The
> > > group fd will need to prevent concurrent open()s to maintain a 1:1 group
> > > to userspace process ownership model.
> >
> > A 1:1 group<->process correspondance seems wrong to me. But there are
> > many ways you could legitimately write the userspace side of the code,
> > many of them involving some sort of concurrency. Implementing that
> > concurrency as multiple processes (using explicit shared memory and/or
> > other IPC mechanisms to co-ordinate) seems a valid choice that we
> > shouldn't arbitrarily prohibit.
> >
> > Obviously, only one UID may be permitted to have the group open at a
> > time, and I think that's enough to prevent them doing any worse than
> > shooting themselves in the foot.
>
> 1:1 group<->process is probably too strong. Not allowing concurrent
> open()s on the group file enforces a single userspace entity is
> responsible for that group. Device fds can be passed to other
> processes, but only retrieved via the group fd. I suppose we could even
> branch off the dma interface into a different fd, but it seems like we
> would logically want to serialize dma mappings at each iommu group
> anyway. I'm open to alternatives, this just seemed an easy way to do
> it. Restricting on UID implies that we require isolated qemu instances
> to run as different UIDs.
Well.. yes and know. It means guests which need to be isolated from
malicious interference with each other need different UIDs, but given
that if they have the same UID one qemu can kill() or ptrace() the
other, they're not isolated in that sense anyway.
It seems to me that running as the same UIDs with different device
groups assigned, the guests are still pretty well isolated from
accidental interference with each other.
> I know that's a goal, but I don't know if we
> want to make it an assumption in the group security model.
>
> > > Also on the table is supporting non-PCI devices with vfio. To do this,
> > > we need to generalize the read/write/mmap and irq eventfd interfaces.
> > > We could keep the same model of segmenting the device fd address space,
> > > perhaps adding ioctls to define the segment offset bit position or we
> > > could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
> > > VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
> > > suffering some degree of fd bloat (group fd, device fd(s), interrupt
> > > event fd(s), per resource fd, etc). For interrupts we can overload
> > > VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq
> >
> > Sounds reasonable.
> >
> > > (do non-PCI
> > > devices support MSI?).
> >
> > They can. Obviously they might not have exactly the same semantics as
> > PCI MSIs, but I know we have SoC systems with (non-PCI) on-die devices
> > whose interrupts are treated by the (also on-die) root interrupt
> > controller in the same way as PCI MSIs.
>
> Ok, I suppose we can define ioctls to enable these as we go. We also
> need to figure out how non-PCI resources, interrupts, and iommu mapping
> restrictions are described via vfio.
Yeah. On device tree platforms we'd want it to be bound to the device
tree representation in some way.
For platform devices, at least, could we have the index into the array
of resources take the place of BAR number for PCI?
>
> > > For qemu, these changes imply we'd only support a model where we have a
> > > 1:1 group to iommu domain. The current vfio driver could probably
> > > become vfio-pci as we might end up with more target specific vfio
> > > drivers for non-pci. PCI should be able to maintain a simple -device
> > > vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll
> > > need to come up with extra options when we need to expose groups to
> > > guest for pvdma.
> >
> > Are you saying that you'd no longer support the current x86 usage of
> > putting all of one guest's devices into a single domain?
>
> Yes. I'm not sure there's a good ROI to prioritize that model. We have
> to assume >1 device per guest is a typical model and that the iotlb is
> large enough that we might improve thrashing to see both a resource and
> performance benefit from it. I'm open to suggestions for how we could
> include it though.
Creating supergroups of some sort seems to be what we need, but I'm
not sure what's the best interface for doing that.
> > If that's
> > not what you're saying, how would the domains - now made up of a
> > user's selection of groups, rather than individual devices - be
> > configured?
> >
> > > Hope that captures it, feel free to jump in with corrections and
> > > suggestions. Thanks,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Jeff Kirsher @ 2011-08-23 2:26 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, mikey@neuling.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-next@vger.kernel.org, paulus@samba.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Mon, 2011-08-22 at 19:13 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
> > On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> >
> >> > Here's what I am applying as a merge fixup to the net tree today so that
> >> > my ppc64_defconfig builds actually build more or less the same set of
> >> > drivers as before this rearrangement.
> >>
> >> And this today:
> >
> > And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig changes
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. Could you prepare a patch which does that?
>
I was just finishing up those patches (not including any defconfig
changes) and started looking at a patch to fix/resolve the issues that
Stephen is seeing.
Let me see what I can come up with tonight to resolve this.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 2:13 UTC (permalink / raw)
To: sfr
Cc: mikey, netdev, linuxppc-dev, linux-kernel, linux-next, paulus,
jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <20110823114129.ceb18da164bf7df3c145941b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:41:29 +1000
> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > Here's what I am applying as a merge fixup to the net tree today so that
>> > my ppc64_defconfig builds actually build more or less the same set of
>> > drivers as before this rearrangement.
>>
>> And this today:
>
> And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig changes
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. Could you prepare a patch which does that?
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-23 1:41 UTC (permalink / raw)
To: David Miller
Cc: mikey, netdev, ppc-dev, linux-kernel, linux-next, Paul Mackerras,
jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <20110823114011.a059aea0138b75bfa7eed1ce@canb.auug.org.au>
Hi Dave,
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Here's what I am applying as a merge fixup to the net tree today so that
> > my ppc64_defconfig builds actually build more or less the same set of
> > drivers as before this rearrangement.
>
> And this today:
And this:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:35:18 +1000
Subject: [PATCH] sparc: update sparc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/configs/sparc64_defconfig | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 3c1e858..5732728 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -37,8 +37,6 @@ CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
@@ -95,17 +93,19 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
CONFIG_MII=m
+CONFIG_NET_VENDOR_AMD=y
CONFIG_SUNLANCE=m
+CONFIG_NET_VENDOR_BROADCOM=y
+CONFIG_BNX2=m
+CONFIG_TIGON3=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E1000=m
+CONFIG_E1000E=m
+CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_SUNVNET=m
-CONFIG_NET_PCI=y
-CONFIG_E1000=m
-CONFIG_E1000E=m
-CONFIG_TIGON3=m
-CONFIG_BNX2=m
CONFIG_NIU=m
# CONFIG_WLAN is not set
CONFIG_PPP=m
@@ -126,13 +126,13 @@ CONFIG_INPUT_SPARCSPKR=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_RAW=m
+# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_SUNSU=y
CONFIG_SERIAL_SUNSU_CONSOLE=y
CONFIG_SERIAL_SUNSAB=y
CONFIG_SERIAL_SUNSAB_CONSOLE=y
CONFIG_SERIAL_SUNHV=y
-# CONFIG_LEGACY_PTYS is not set
CONFIG_FB=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_SBUS=y
@@ -206,10 +206,8 @@ CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KEYS=y
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-23 1:40 UTC (permalink / raw)
To: David Miller
Cc: mikey, netdev, ppc-dev, linux-kernel, linux-next, Paul Mackerras,
jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <20110822113032.15087c2e190e2b0c3ee7dfb8@canb.auug.org.au>
Hi Dave,
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Here's what I am applying as a merge fixup to the net tree today so that
> my ppc64_defconfig builds actually build more or less the same set of
> drivers as before this rearrangement.
And this today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:23:40 +1000
Subject: [PATCH] sparc: update sparc32_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/configs/sparc32_defconfig | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/configs/sparc32_defconfig b/arch/sparc/configs/sparc32_defconfig
index fb23fd6..9bc241a 100644
--- a/arch/sparc/configs/sparc32_defconfig
+++ b/arch/sparc/configs/sparc32_defconfig
@@ -2,9 +2,7 @@ CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
@@ -42,9 +40,10 @@ CONFIG_SCSI_QLOGICPTI=m
CONFIG_SCSI_SUNESP=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
-CONFIG_NET_ETHERNET=y
CONFIG_MII=m
+CONFIG_NET_VENDOR_AMD=y
CONFIG_SUNLANCE=y
+CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNBMAC=m
CONFIG_SUNQE=m
@@ -64,26 +63,22 @@ CONFIG_SERIAL_SUNSU=y
CONFIG_SERIAL_SUNSU_CONSOLE=y
CONFIG_SPI=y
CONFIG_SPI_XILINX=m
-CONFIG_SPI_XILINX_PLTFM=m
CONFIG_SUN_OPENPROMIO=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
-CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_ISO9660_FS=m
CONFIG_PROC_KCORE=y
CONFIG_ROMFS_FS=m
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
-CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_NLS=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_KGDB=y
CONFIG_KGDB_TESTS=y
CONFIG_CRYPTO_NULL=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: aafabbri @ 2011-08-23 0:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, iommu, chrisw,
Alex Williamson, Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1314049785.7662.44.camel@pasglop>
On 8/22/11 2:49 PM, "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
wrote:
>
>>> I wouldn't use uiommu for that.
>>
>> Any particular reason besides saving a file descriptor?
>>
>> We use it today, and it seems like a cleaner API than what you propose
>> changing it to.
>
> Well for one, we are back to square one vs. grouping constraints.
I'm not following you.
You have to enforce group/iommu domain assignment whether you have the
existing uiommu API, or if you change it to your proposed
ioctl(inherit_iommu) API.
The only change needed to VFIO here should be to make uiommu fd assignment
happen on the groups instead of on device fds. That operation fails or
succeeds according to the group semantics (all-or-none assignment/same
uiommu).
I think the question is: do we force 1:1 iommu/group mapping, or do we allow
arbitrary mapping (satisfying group constraints) as we do today.
I'm saying I'm an existing user who wants the arbitrary iommu/group mapping
ability and definitely think the uiommu approach is cleaner than the
ioctl(inherit_iommu) approach. We considered that approach before but it
seemed less clean so we went with the explicit uiommu context.
> .../...
>
>> If we in singleton-group land were building our own "groups" which were sets
>> of devices sharing the IOMMU domains we wanted, I suppose we could do away
>> with uiommu fds, but it sounds like the current proposal would create 20
>> singleton groups (x86 iommu w/o PCI bridges => all devices are partitionable
>> endpoints). Asking me to ioctl(inherit) them together into a blob sounds
>> worse than the current explicit uiommu API.
>
> I'd rather have an API to create super-groups (groups of groups)
> statically and then you can use such groups as normal groups using the
> same interface. That create/management process could be done via a
> simple command line utility or via sysfs banging, whatever...
^ permalink raw reply
* Re: [PATCH 2/2] sound/soc/fsl/mpc8610_hpcd.c: add missing of_node_put
From: Mark Brown @ 2011-08-22 22:30 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel, Liam Girdwood, Takashi Iwai, devicetree-discuss,
kernel-janitors, linux-kernel, Jaroslav Kysela, linuxppc-dev,
Timur Tabi
In-Reply-To: <1313823721-16930-2-git-send-email-julia@diku.dk>
On Sat, Aug 20, 2011 at 09:02:01AM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> The first change is to add an of_node_put, since codec_np has previously
> been allocated. The rest of the patch reorganizes the error handling code
> so the only code executed is that which is needed.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] [v2] sound/soc/fsl/fsl_dma.c: add missing of_node_put
From: Mark Brown @ 2011-08-22 22:30 UTC (permalink / raw)
To: Timur Tabi
Cc: alsa-devel, tiwai, devicetree-discuss, kernel-janitors,
linux-kernel, perex, julia, linuxppc-dev, lrg
In-Reply-To: <1314022961-27513-1-git-send-email-timur@freescale.com>
On Mon, Aug 22, 2011 at 09:22:41AM -0500, Timur Tabi wrote:
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> Since we don't actually use np, we can decrement the reference count
> immediately.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] [v2] sound/soc/fsl/fsl_dma.c: add missing of_node_put
From: Mark Brown @ 2011-08-22 22:27 UTC (permalink / raw)
To: Timur Tabi
Cc: alsa-devel, tiwai, devicetree-discuss, kernel-janitors,
linux-kernel, perex, julia, linuxppc-dev, lrg
In-Reply-To: <1314022961-27513-1-git-send-email-timur@freescale.com>
On Mon, Aug 22, 2011 at 09:22:41AM -0500, Timur Tabi wrote:
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> Since we don't actually use np, we can decrement the reference count
> immediately.
Applied, thanks.
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Benjamin Herrenschmidt @ 2011-08-22 21:49 UTC (permalink / raw)
To: aafabbri
Cc: Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, iommu, chrisw,
Alex Williamson, Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <CA781A61.FB15%aafabbri@cisco.com>
> > I wouldn't use uiommu for that.
>
> Any particular reason besides saving a file descriptor?
>
> We use it today, and it seems like a cleaner API than what you propose
> changing it to.
Well for one, we are back to square one vs. grouping constraints.
.../...
> If we in singleton-group land were building our own "groups" which were sets
> of devices sharing the IOMMU domains we wanted, I suppose we could do away
> with uiommu fds, but it sounds like the current proposal would create 20
> singleton groups (x86 iommu w/o PCI bridges => all devices are partitionable
> endpoints). Asking me to ioctl(inherit) them together into a blob sounds
> worse than the current explicit uiommu API.
I'd rather have an API to create super-groups (groups of groups)
statically and then you can use such groups as normal groups using the
same interface. That create/management process could be done via a
simple command line utility or via sysfs banging, whatever...
Cheers,
Ben.
> Thanks,
> Aaron
>
> >
> > Another option is to make that static configuration APIs via special
> > ioctls (or even netlink if you really like it), to change the grouping
> > on architectures that allow it.
> >
> > Cheers.
> > Ben.
> >
> >>
> >> -Aaron
> >>
> >>> As necessary in the future, we can
> >>> define a more high performance dma mapping interface for streaming dma
> >>> via the group fd. I expect we'll also include architecture specific
> >>> group ioctls to describe features and capabilities of the iommu. The
> >>> group fd will need to prevent concurrent open()s to maintain a 1:1 group
> >>> to userspace process ownership model.
> >>>
> >>> Also on the table is supporting non-PCI devices with vfio. To do this,
> >>> we need to generalize the read/write/mmap and irq eventfd interfaces.
> >>> We could keep the same model of segmenting the device fd address space,
> >>> perhaps adding ioctls to define the segment offset bit position or we
> >>> could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
> >>> VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
> >>> suffering some degree of fd bloat (group fd, device fd(s), interrupt
> >>> event fd(s), per resource fd, etc). For interrupts we can overload
> >>> VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq (do non-PCI
> >>> devices support MSI?).
> >>>
> >>> For qemu, these changes imply we'd only support a model where we have a
> >>> 1:1 group to iommu domain. The current vfio driver could probably
> >>> become vfio-pci as we might end up with more target specific vfio
> >>> drivers for non-pci. PCI should be able to maintain a simple -device
> >>> vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll
> >>> need to come up with extra options when we need to expose groups to
> >>> guest for pvdma.
> >>>
> >>> Hope that captures it, feel free to jump in with corrections and
> >>> suggestions. Thanks,
> >>>
> >>> Alex
> >>>
> >
> >
^ 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