On Thu, 25 Aug 2011 18:23:35 +0800, Kyungmin Park
wrote:
On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan
wrote:
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable C
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Friday, August 12, 2011 18:05 PM
> To: Zang Roy-R61911
> Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; akpm@linux-
> foundation.org; Xu Lei-B33228; Kumar Gala; Wood Scott-B07421
> Subject:
Move mmc_delay() from drivers/mmc/core/core.h to
include/linux/mmc/core.h. So when other functions
call it with include syntax using
of absolute path rather than "../core/core.h" of
relative path.
Signed-off-by: Chunhe Lan
Cc: Chris Ball
---
drivers/mmc/core/core.h | 12
includ
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
W
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
W
On Fri, Aug 26, 2011 at 12:24:23AM -0400, David Gibson wrote:
> On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
> > On 25.08.2011, at 07:31, Roedel, Joerg wrote:
> > > For mmio we could stop the guest and replace the mmio region with a
> > > region that is filled with 0xff, no?
> >
On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote:
> On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> > On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
> >
> > > > I don't see a reason to
On Wed, Aug 24, 2011 at 01:59:39PM +1000, David Gibson wrote:
> On Tue, Aug 23, 2011 at 02:55:13PM +0530, K.Prasad wrote:
> > 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_SET
On 26.08.2011, at 04:33, Roedel, Joerg wrote:
> On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote:
>> On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
>>> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel,
On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
> On 26.08.2011, at 04:33, Roedel, Joerg wrote:
> >
> > The reason is that you mean the usability for the programmer and I mean
> > it for the actual user of qemu :)
>
> No, we mean the actual user of qemu. The reason being that maki
On 26.08.2011, at 10:24, Joerg Roedel wrote:
> On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
>> On 26.08.2011, at 04:33, Roedel, Joerg wrote:
>>>
>>> The reason is that you mean the usability for the programmer and I mean
>>> it for the actual user of qemu :)
>>
>> No, we mean
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections that I missed.
VFIO v2 will rely on the platform iommu driver reporting grouping
information. Again, a group is a set of devices for
On 8/26/11 7:07 AM, "Alexander Graf" wrote:
>
>
> Forget the KVM case for a moment and think of a user space device driver. I as
> a user am not root. But I as a user when having access to /dev/vfioX want to
> be able to access the device and manage it - and only it. The admin of that
> box
On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
>
> > > We need to solve this differently. ARM is starting to use the iommu-api
> > > too and this definitly does no
On 08/26/2011 01:00 AM, smitha.va...@wipro.com wrote:
>
> Thanks scott.
>
> There was an issue with the file system. Now my board is up with the
> linux boot prompt .
> But ping is not working.
You still haven't set your MAC address. U-Boot should be fixing this up
in the device tree.
> The
On 8/26/11 12:35 PM, "Chris Wright" wrote:
> * Aaron Fabbri (aafab...@cisco.com) wrote:
>> On 8/26/11 7:07 AM, "Alexander Graf" wrote:
>>> Forget the KVM case for a moment and think of a user space device driver. I
>>> as
>>> a user am not root. But I as a user when having access to /dev/vfio
* Aaron Fabbri (aafab...@cisco.com) wrote:
> On 8/26/11 7:07 AM, "Alexander Graf" wrote:
> > Forget the KVM case for a moment and think of a user space device driver. I
> > as
> > a user am not root. But I as a user when having access to /dev/vfioX want to
> > be able to access the device and man
Since commit 188917e183cf9ad0374b571006d0fc6d48a7f447, /proc/ppc64 is a
symlink to /proc/powerpc/. That means that creating /proc/ppc64/eeh will
end up with a unaccessible file, that is not listed under /proc/powerpc/
and, then, not listed under /proc/ppc64/.
Creating /proc/powerpc/eeh fixes that
* Aaron Fabbri (aafab...@cisco.com) wrote:
> On 8/26/11 12:35 PM, "Chris Wright" wrote:
> > * Aaron Fabbri (aafab...@cisco.com) wrote:
> >> Each process will open vfio devices on the fly, and they need to be able to
> >> share IOMMU resources.
> >
> > How do you share IOMMU resources w/ multiple
Commit 3da34aae (powerpc/fsl: Support unique MSI addresses per PCIe Root
Complex) redefined the meanings of msi->msi_addr_hi and msi->msi_addr_lo to be
an offset rather than an address. To help clarify the code, we make the
following changes:
1) Get rid of msi_addr_hi, which is always zero anyway
20 matches
Mail list logo
