Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI and increase build testing coverage.
Don't enable COMPILE_TEST support
On Wed, Oct 30, 2013 at 12:20:43PM +0100, Laurent Pinchart wrote:
> Renesas ARM platforms are transitioning from single-platform to
> multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
> driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
> and ARCH_SHMOBILE_MUL
Hi Russell,
[CC'ing Mark Brown]
On Wednesday 30 October 2013 11:26:25 Russell King - ARM Linux wrote:
> On Wed, Oct 30, 2013 at 12:20:43PM +0100, Laurent Pinchart wrote:
> > Renesas ARM platforms are transitioning from single-platform to
> > multi-platform kernels using the new ARCH_SHMOBILE_MULT
Hiroshi Doyu wrote @ Fri, 18 Oct 2013 12:26:41 +0200:
> Hi,
>
> This series provides:
>
> (1) Unified SMMU driver among Tegra SoCs
> (2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
> (3) Tegra IOMMU'able devices, most of platform devices are IOMMU'able.
>
> There's some discussion[1]
On 10/30/2013 10:34 AM, Hiroshi Doyu wrote:
> Hiroshi Doyu wrote @ Fri, 18 Oct 2013 12:26:41 +0200:
>
>> Hi,
>>
>> This series provides:
>>
>> (1) Unified SMMU driver among Tegra SoCs
>> (2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
>> (3) Tegra IOMMU'able devices, most of platform de
On Wed, Oct 30, 2013 at 12:40:12PM +0100, Laurent Pinchart wrote:
> > For similar reasons as x86, can we please think about using:
> > depends on ARM
> > depends on ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI || COMPILE_TEST
> I'm fine with your proposed option. As I don't want to respin the se
On 10/25/2013 07:20 AM, Will Deacon wrote:
> On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote:
>> Thierry Reding wrote @ Fri, 25 Oct 2013 09:56:55
>> +0200:
>>
>>> I suspect that there will be enough differences between the various
>>> IOMMU implementations that we won't be able to ha
On 10/25/2013 03:11 AM, Thierry Reding wrote:
...
> So my proposed solution for the IOMMU case is to treat it the same
> as any other resources. Perhaps resource isn't the right word, but
> at the core the issue is the same. A device requires the services
> of an IOMMU so that it can be put into th
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Populate AHB/IOMMU earlier than others. IOMMU depends on AHB. IOMMU
> needs to be instanciated earlier than others so that IOMMU can
> register other platform devices as IOMMU'able. Once IOMMU is
> populated, IOMMU/AHB nodes are detached to prevent anot
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Fix IOMMU register address.
That's quite unfortunate. Why do we always have trouble getting the
IOMMU register address correct in DT; I think we had a similar issue
with the Tegra30 DT.
Anyway, I guess I should take this for 3.13 and stable since it's
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> SMMU expects ARM_DMA_USE_IOMMU to be enabled to use DMA mapping API by
> default.
Is the select required for the driver to be useful at all (in which case
it's fine), or simply for things to work "better" (define "better"), in
which case perhaps leavin
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Create default IOVA maps at boot-up which can be attached to devices.
What's the content of those default maps? I assume no RAM is mapped,
judging by the code. If so, perhaps s/default/default empty/ in the
patch description?
> @@ -1236,7 +1261,7 @@ s
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> v3:
> Updated based on Stephen Warren's feedback
Updated how? The last series was posted a long time ago, and I have no
idea what feedback I gave...
___
iommu mailing list
iommu@lists.linux-foundation.org
ht
On 10/24/2013 02:58 AM, Grant Likely wrote:
> On Fri, 18 Oct 2013 13:26:51 +0300, Hiroshi Doyu wrote:
>> This provides the info about which H/W Accelerators are supported on
>> Tegra SoC. This info is passed from DT. This is necessary to have the
>> unified SMMU driver among Tegra SoCs. Instead of
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This provides the info about which H/W Accelerators are supported on
> Tegra SoC. This info is passed from DT. This is necessary to have the
> unified SMMU driver among Tegra SoCs. Instead of using platform data,
> DT passes "nvidia,swgroups" now. DT is
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra30 SoC.
Feel free to squash patches 11 and 12 into one. They're doing the same
logical thing.
Also, can you please separate the series into separate series for th
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Make PCIe work as it is. IOMMU support can be implemented later. We
> need the same kind of registration framework for PCIe as platform_bus
> does currently.
Some more explanation is needed here re: exactly why PCIe doesn't work,
and how this patch mak
On Wed, Oct 30, 2013 at 03:58:58PM -0600, Stephen Warren wrote:
> On 10/25/2013 03:11 AM, Thierry Reding wrote:
> ...
> > So my proposed solution for the IOMMU case is to treat it the same
> > as any other resources. Perhaps resource isn't the right word, but
> > at the core the issue is the same.
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> This provides the info about which swgroups a device belongs to. This
> info is passed from DT. This is necessary for the unified SMMU driver
> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> b/Documentation/devicetree/b
On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> binding. "swgroups" is a group of H/W clients which Tegra SoCs
> support. This unique ID can be used to calculate MC_SMMU_ name>_ASID_0 register offset and MC__HOTRESET_*_0
> regis
On Fri, Oct 18, 2013 at 09:13:11PM +0100, Andreas Herrmann wrote:
> At the moment just handle BUS_NOTIFY_BIND_DRIVER to conditionally
> isolate all master devices for an SMMU.
>
> Depending on DT information each device is put into its own protection
> domain (if possible). For configuration with
On Fri, Oct 18, 2013 at 09:13:12PM +0100, Andreas Herrmann wrote:
> In such a case we have to use secure aliases of some non-secure
> registers.
>
> This handling is switched on by DT property
> "arm,smmu-secure-config-access" for an SMMU node.
This looks fine, but won't apply without the device
On Wed, Oct 09, 2013 at 06:02:38PM +0100, Will Deacon wrote:
> Hi Joerg,
>
> Please pull these ARM SMMU updates for 3.13. The bulk of the changes are
> from Andreas, who has been having fun running the driver on real hardware. I
> expect some additional patches from him in the future to add suppor
On Fri, Oct 18, 2013 at 09:13:14PM +0100, Andreas Herrmann wrote:
> Signed-off-by: Andreas Herrmann
> ---
> arch/arm/boot/dts/ecx-2000.dts| 44
> +++--
> arch/arm/boot/dts/ecx-common.dtsi |9 +---
> drivers/iommu/arm-smmu.c |2 +-
> incl
On Fri, Oct 18, 2013 at 09:13:15PM +0100, Andreas Herrmann wrote:
> This patch adds descriptions fore new properties of device tree
> binding for the ARM SMMU architecture. These properties control
> arm-smmu driver options.
>
> Cc: Rob Herring
> Cc: Grant Likely
> Cc: Will Deacon
> Signed-off-
On Wed, Oct 30, 2013 at 8:17 PM, Will Deacon wrote:
> On Fri, Oct 18, 2013 at 09:13:15PM +0100, Andreas Herrmann wrote:
>> This patch adds descriptions fore new properties of device tree
>> binding for the ARM SMMU architecture. These properties control
>> arm-smmu driver options.
>>
>> Cc: Rob He
26 matches
Mail list logo
