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
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_F
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
> h
From: Arnaud Lacombe
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_1
and some have been added (f.e. ETHE
Hi,
[Added linux-kbuild@ to the Cc: list.]
On Mon, Aug 22, 2011 at 10:13 PM, David Miller wrote:
> From: Stephen Rothwell
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
>> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell
>> wrote:
>>>
>>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell
>>
于 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].
So
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
On Mon, 2011-08-22 at 19:13 -0700, David Miller wrote:
> From: Stephen Rothwell
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
> > On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell
> > wrote:
> >>
> >> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell
> >> wrote:
> >> >
> >> > Here's what I am
From: Stephen Rothwell
Date: Tue, 23 Aug 2011 11:41:29 +1000
> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell
> wrote:
>>
>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell
>> wrote:
>> >
>> > Here's what I am applying as a merge fixup to the net tree today so that
>> > my ppc64_defc
Hi Dave,
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell
wrote:
>
> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell
> 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
> > dr
Hi Dave,
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell
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 Rothwel
On 8/22/11 2:49 PM, "Benjamin Herrenschmidt"
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 on
On 8/22/11 1:49 PM, "Benjamin Herrenschmidt"
wrote:
> On Mon, 2011-08-22 at 13:29 -0700, aafabbri wrote:
>
>>> 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
On 8/20/11 9:51 AM, "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
On Sat, Aug 20, 2011 at 09:02:01AM +0200, Julia Lawall wrote:
> From: Julia Lawall
>
> 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.
Applie
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.
___
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.
___
> > 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 la
> I am in favour of /dev/vfio/$GROUP. If multiple devices should be
> assigned to a guest, there can also be an ioctl to bind a group to an
> address-space of another group (certainly needs some care to not allow
> that both groups belong to different processes).
>
> Btw, a problem we havn't talk
On Mon, 2011-08-22 at 09:45 -0600, Alex Williamson wrote:
> 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 opt
On Mon, 2011-08-22 at 09:30 +0300, Avi Kivity wrote:
> On 08/20/2011 07:51 PM, Alex Williamson wrote:
> > 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 typicall
On Mon, 2011-08-22 at 13:29 -0700, aafabbri wrote:
> > 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.
> >
> > Another valid model might be that
On 22/08/11 15:22, 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.
>
> Reported-by: Julia Lawall
> Signed-off-by:
On Tue, 26 Jul 2011 14:07:26 -0400
Alexandre Bounine wrote:
> Replace/remove use of RIO v.1.2 registers/bits that are not forward-compatible
> with newer versions of RapidIO specification.
>
> RapidIO specification v. 1.3 removed Write Port CSR, Doorbell CSR,
> Mailbox CSR and Mailbox and Doorbe
On Mon, 2011-08-22 at 19:25 +0200, Joerg Roedel wrote:
> On Sat, Aug 20, 2011 at 12:51:39PM -0400, 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
On Sat, Aug 20, 2011 at 12:51:39PM -0400, 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
Scott Wood a écrit :
> 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].
>>
>
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
Scott Wood a écrit :
> On 08/22/2011 10:25 AM, Ivan Djelic wrote:
>> Did you take into account the fact that because MTD thinks this a 2K chip,
>> you will have to wait twice for the nand busy read time (typically 25 us) per
>> each 4K read. In other words, to read 4 kBytes you will do:
>>
>> 1. se
On 08/22/2011 10:25 AM, Ivan Djelic wrote:
> Did you take into account the fact that because MTD thinks this a 2K chip,
> you will have to wait twice for the nand busy read time (typically 25 us) per
> each 4K read. In other words, to read 4 kBytes you will do:
>
> 1. send read0 (00), send address
On 08/22/2011 05:58 AM, Artem Bityutskiy wrote:
> On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
>> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
>>> How the bad block marker are handled with this remapping ?
>>
>> It has to be migrated prior to first use (this needs to be documented,
>> and
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
On Mon, Aug 22, 2011 at 11:58:33AM +0100, Artem Bityutskiy wrote:
> On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> > On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> > > LiuShuo a écrit :
> > >> ??? 2011???08???19??? 01:00, Matthieu CASTET ??:
> > >>> b35...@freescale.com a écrit :
> >
On Mon, Aug 22, 2011 at 09:17:41AM -0400, Avi Kivity wrote:
> On 08/22/2011 04:15 PM, Roedel, Joerg wrote:
> > On Mon, Aug 22, 2011 at 09:06:07AM -0400, Avi Kivity wrote:
> > > On 08/22/2011 03:55 PM, Roedel, Joerg wrote:
> >
> > > > Well, I don't think its really meaningless, but we need some w
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.
Reported-by: Julia Lawall
Signed-off-by: Timur Tabi
---
sound/soc/fsl/fsl_dma.c |2 ++
On Mon, 22 Aug 2011, Timur Tabi wrote:
> Julia Lawall wrote:
> > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> > index 0efc04a..b33271b 100644
> > --- a/sound/soc/fsl/fsl_dma.c
> > +++ b/sound/soc/fsl/fsl_dma.c
> > @@ -880,10 +880,12 @@ static struct device_node *find_ssi_node(s
Julia Lawall wrote:
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0efc04a..b33271b 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -880,10 +880,12 @@ static struct device_node *find_ssi_node(struct
> device_node *dma_channel_np)
>
On 08/22/2011 04:15 PM, Roedel, Joerg wrote:
On Mon, Aug 22, 2011 at 09:06:07AM -0400, Avi Kivity wrote:
> On 08/22/2011 03:55 PM, Roedel, Joerg wrote:
> > Well, I don't think its really meaningless, but we need some way to
> > communicate the information about device groups to userspace.
>
On Mon, Aug 22, 2011 at 09:06:07AM -0400, Avi Kivity wrote:
> On 08/22/2011 03:55 PM, Roedel, Joerg wrote:
> > Well, I don't think its really meaningless, but we need some way to
> > communicate the information about device groups to userspace.
>
> I mean the contents of the group descriptor. Th
On 08/22/2011 03:55 PM, Roedel, Joerg wrote:
On Mon, Aug 22, 2011 at 08:42:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
> > On the AMD IOMMU side this information is stored in the IVRS ACPI table.
> > Not sure about the VT-d side, though.
>
> I see. There is
On Mon, Aug 22, 2011 at 08:42:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
> > On the AMD IOMMU side this information is stored in the IVRS ACPI table.
> > Not sure about the VT-d side, though.
>
> I see. There is no sysfs node representing it?
No. It also doesn't
On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
On Mon, Aug 22, 2011 at 06:51:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> > That does not work. The bridge in question may not even be visible as a
> > PCI device, so you can't link to it. This is the case on a fe
On Mon, Aug 22, 2011 at 06:51:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> > That does not work. The bridge in question may not even be visible as a
> > PCI device, so you can't link to it. This is the case on a few PCIe
> > cards which only have a PCIx chip and a P
On Mon, 22 Aug 2011, walter harms wrote:
>
>
> Am 21.08.2011 18:10, schrieb Julia Lawall:
> > From: Julia Lawall
> >
> > np is initialized to the result of calling a function that calls
> > of_node_get, so of_node_put should be called before the pointer is dropped.
> >
> > The semantic match
On 20/08/11 08:23, Julia Lawall wrote:
> From: Julia Lawall
>
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
>
On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> > LiuShuo a écrit :
> >> 于 2011年08月19日 01:00, Matthieu CASTET 写道:
> >>> b35...@freescale.com a écrit :
> From: Liu Shuo
>
> Freescale FCM controller has a 2K size limitation of buf
On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> $ readlink /sys/devices/pci:00/:00:19.0/iommu_group
> ../../../path/to/device/which/represents/the/resource/constraint
>
> (the pci-to-pci bridge on x86, or whatever node represents partitionable
> endpoints on power)
That does not work.
On Thu, 2011-08-18 at 10:33 +0800, b35...@freescale.com wrote:
> From: Liu Shuo
>
> 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 t
On Mon, Aug 22, 2011 at 02:30:26AM -0400, Avi Kivity wrote:
> On 08/20/2011 07:51 PM, Alex Williamson wrote:
> > 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 t
Am 21.08.2011 18:10, schrieb Julia Lawall:
> From: Julia Lawall
>
> np is initialized to the result of calling a function that calls
> of_node_get, so of_node_put should be called before the pointer is dropped.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.
On Mon, 22 Aug 2011, walter harms wrote:
>
>
> Am 21.08.2011 18:10, schrieb Julia Lawall:
> > From: Julia Lawall
> >
> > np is initialized to the result of calling a function that calls
> > of_node_get, so of_node_put should be called before the pointer is dropped.
> >
> > The semantic match
On Wed, 17 Aug 2011 05:46:29 +0800, Scott Wood
wrote:
On 08/16/2011 04:27 AM, Chunhe Lan wrote:
Nand flash nodes with the property status="disabled" are not
usable and so avoid adding "disabled" nand flash devices with
the system.
Signed-off-by: Chunhe Lan
---
drivers/mtd/nand/fsl_elbc_na
On Wed, 17 Aug 2011 05:44:56 +0800, Scott Wood
wrote:
On 08/16/2011 04:25 AM, Chunhe Lan wrote:
Flash(cfi-flash, jedec-flash, and so on) nodes with the
property status="disabled" are not usable and so avoid
adding "disabled" flash devices with the system.
Signed-off-by: Chunhe Lan
---
dri
53 matches
Mail list logo
