On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> > On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > > On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> > >> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote
Fix build failure in fsl_pamu_domain.o caused as follows
drivers/iommu/fsl_pamu_domain.c: In function 'pamu_domain_init':
drivers/iommu/fsl_pamu_domain.c:1103:17: error: 'pci_bus_type' undeclared
(first use in this function)
drivers/iommu/fsl_pamu_domain.c:1103:17: note: each undeclared identifier
On Tuesday 19 August 2014, Will Deacon wrote:
> > +static int arm_smmu_parse_iommus_properties(struct arm_smmu_device *smmu,
> > + int *num_masters)
> > +{
> > + struct of_phandle_args iommuspec;
> > + struct device_node *dn;
> > +
> > + for_each_node
> This RFC's intention is to show what an interface to access device node
> properties for VFIO_PLATFORM can look like.
>
> If a device tree node corresponding to a platform device bound by
> VFIO_PLATFORM
> is available, this patch series will allow the user to query the properties
> associated
Hi Marek and Inki,
Am 19.08.2014 08:07, schrieb Marek Szyprowski:
> On 2014-08-19 01:32, Joerg Roedel wrote:
>> On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote:
[...]
>>> 33 files changed, 1016 insertions(+), 356 deletions(-)
>> This touches a lot of non-iommu stuff. What is you
Hi,
Am 19.08.2014 14:01, schrieb Marek Szyprowski:
> On 2014-08-19 13:39, Andreas Färber wrote:
>> I'm working on 5250 based Spring Chromebook and noticed that v3.17-rc1
>> got some more iommu support. With the new CONFIG_DRM_EXYNOS_IOMMU=y my
>> machine stops booting. So I'm wondering, is any of
On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
> On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> > On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> >> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> >>> If the alignment is not correct then iommu_map() will return error
On Tue, Aug 19 2014 at 05:58:34 AM, Will Deacon wrote:
> I also assume that the clk API ignores calls to clk_enable_prepare
> for a clk that's already enabled? I couldn't find that code...
That's clk_prepare_enable, not clk_enable_prepare. It's in
.
-Mitch
--
The Qualcomm Innovation Center, I
On Tue, Aug 19 2014 at 05:48:07 AM, Will Deacon wrote:
> On Wed, Aug 13, 2014 at 01:51:39AM +0100, Mitchel Humpherys wrote:
>> Under certain conditions coherent hardware translation table walks can
>> result in degraded performance. Add a new domain attribute to
>> disable/enable this feature in g
Hi Will,
On 8/19/2014 5:58 AM, Will Deacon wrote:
> On Wed, Aug 13, 2014 at 01:51:34AM +0100, Mitchel Humpherys wrote:
>> On some platforms with tight power constraints it is polite to only
>> leave your clocks on for as long as you absolutely need them. Currently
>> we assume that all clocks nece
On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
> On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
>> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
>>> If the alignment is not correct then iommu_map() will return error. Not
>>> sure what other option we have here (and why make it
On 8/19/2014 4:59 AM, Joerg Roedel wrote:
> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
>> If the alignment is not correct then iommu_map() will return error. Not
>> sure what other option we have here (and why make it different behavior
>> than iommu_map which just return error wh
On Tue, Aug 19 2014 at 05:44:32 AM, Will Deacon wrote:
> On Wed, Aug 13, 2014 at 01:51:36AM +0100, Mitchel Humpherys wrote:
>> Currently, we provide the iommu_ops.iova_to_phys service by doing a
>> table walk in software to translate IO virtual addresses to physical
>> addresses. On SMMUs that sup
On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
> On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> > If the alignment is not correct then iommu_map() will return error. Not
> > sure what other option we have here (and why make it different behavior
> > than iommu_map which just
Will Deacon writes:
> [adding Rob, Mark, Arnd, Thierry and Hiroshi]
>
> On Wed, Aug 13, 2014 at 01:51:37AM +0100, Mitchel Humpherys wrote:
>> Generic IOMMU device tree bindings were recently added in
>> ["devicetree: Add generic IOMMU device tree bindings"]. Implement the
>> bindings in the ARM
On Wed, Aug 13, 2014 at 01:51:35AM +0100, Mitchel Humpherys wrote:
> On some power-constrained platforms it's useful to disable power when a
> device is not in use. Add support for specifying regulators for SMMUs
> and only leave power on as long as the SMMU is in use (attached).
... and for bypas
On Wed, Aug 13, 2014 at 01:51:34AM +0100, Mitchel Humpherys wrote:
> On some platforms with tight power constraints it is polite to only
> leave your clocks on for as long as you absolutely need them. Currently
> we assume that all clocks necessary for SMMU register access are always
> on.
>
> Add
[adding Rob, Mark, Arnd, Thierry and Hiroshi]
On Wed, Aug 13, 2014 at 01:51:37AM +0100, Mitchel Humpherys wrote:
> Generic IOMMU device tree bindings were recently added in
> ["devicetree: Add generic IOMMU device tree bindings"]. Implement the
> bindings in the ARM SMMU driver.
>
> See Documenta
On Wed, Aug 13, 2014 at 01:51:39AM +0100, Mitchel Humpherys wrote:
> Under certain conditions coherent hardware translation table walks can
> result in degraded performance. Add a new domain attribute to
> disable/enable this feature in generic code along with the domain
> attribute setter and gett
On Wed, Aug 13, 2014 at 01:51:36AM +0100, Mitchel Humpherys wrote:
> Currently, we provide the iommu_ops.iova_to_phys service by doing a
> table walk in software to translate IO virtual addresses to physical
> addresses. On SMMUs that support it, it can be useful to ask the SMMU
> itself to do the
Hi Will,
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Will Deacon
> Sent: Friday, August 15, 2014 5:21 PM
> To: Hiroshi Doyu
> Cc: Mark Rutland; devicet...@vger.kernel.org; Stephen Warren; Arnd
> Ber
> -Original Message-
> From: Hiroshi Doyu [mailto:hd...@nvidia.com]
> Sent: Tuesday, August 19, 2014 4:33 PM
> To: Sethi Varun-B16395; Will Deacon
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Mark
> Rutland; devicet...@vger.kernel.org; Olof Johansson; iommu@lists.lin
Hello,
On 2014-08-19 13:39, Andreas Färber wrote:
Hi Marek and Inki,
Am 19.08.2014 08:07, schrieb Marek Szyprowski:
On 2014-08-19 01:32, Joerg Roedel wrote:
On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote:
[...]
33 files changed, 1016 insertions(+), 356 deletions(-)
Thi
On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
> If the alignment is not correct then iommu_map() will return error. Not
> sure what other option we have here (and why make it different behavior
> than iommu_map which just return error when it is not aligned properly).
> I don't think
On Mon, Aug 18, 2014 at 03:20:56PM +0300, Andreea-Cristina Bernat wrote:
> The use of "rcu_assign_pointer()" is NULLing out the pointer.
> According to RCU_INIT_POINTER()'s block comment:
> "1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
> it is better to use it instead of rcu_assi
On Fri, Aug 15, 2014 at 09:55:51AM +0800, Li, Zhen-Hua wrote:
> According to intel's spec
> Intel® Virtualization Technology for Directed I/O,
> Revision: 1.3 , February 2011,
> Chaper 10.4.25 to 10.4.28
>
> There are four registers
>
> IECTL_REG 0xa0Invalida
On Mon, Aug 11, 2014 at 01:13:25PM +0200, Jan Kiszka wrote:
> Don't store the SIRTP request bit in the register state. It will
> otherwise become sticky and could request an Interrupt Remap Table
> Pointer update on each command register write.
>
> Found while starting to emulate IR in QEMU, not b
On Mon, Aug 04, 2014 at 10:06:28AM +0530, Sachin Kamat wrote:
> Fixed trivial typos and grammar to improve readability.
> Changed w/a to workaround.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/iommu/exynos-iommu.c | 51
> ++--
> 1 file changed, 26 ins
Varun Sethi writes:
>> >> > Also, for dynamic stream ID allocation we would need to represent
>> >> > the specific master register (to store the stream ID) in the device
>> >> > tree.
>> >>
>> >> I assmue that the above means that iMX has such configuration
>> >> register to map steramID and a
On Mon, Aug 18, 2014 at 11:27:01PM +, Li, Zhen-Hua wrote:
> : [fault reason 01] Present bit in root entry is clear
> It appears when iommu initializing in the kdump kernel.
Hmm, do you have an explanation how this can happen? From how I read the
code, the kdump kernel disables translation on t
> -Original Message-
> From: Hiroshi Doyu [mailto:hd...@nvidia.com]
> Sent: Tuesday, August 19, 2014 3:34 PM
> To: Sethi Varun-B16395; Will Deacon
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Mark
> Rutland; devicet...@vger.kernel.org; Olof Johansson; iommu@lists.lin
Varun Sethi writes:
> Hi Hiroshi,
>
>> -Original Message-
>> From: Hiroshi Doyu [mailto:hd...@nvidia.com]
>> Sent: Thursday, August 14, 2014 9:35 PM
>> To: Sethi Varun-B16395
>> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Will
>> Deacon; Mark Rutland; devicet...@vger
Hi Hiroshi,
> -Original Message-
> From: Hiroshi Doyu [mailto:hd...@nvidia.com]
> Sent: Thursday, August 14, 2014 9:35 PM
> To: Sethi Varun-B16395
> Cc: Hiroshi Doyu; Thierry Reding; Stephen Warren; Arnd Bergmann; Will
> Deacon; Mark Rutland; devicet...@vger.kernel.org; Olof Johansson;
> i
33 matches
Mail list logo
