changes:
Acked-by: Will Deacon will.dea...@arm.com
Hopefully this doesn't conflict too badly with my outstanding arm-smmu
pull requests to you, but do shout if you have any trouble.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message
On Mon, Jan 26, 2015 at 11:00:59AM +, Joerg Roedel wrote:
On Sun, Jan 25, 2015 at 05:38:22PM +0200, Laurent Pinchart wrote:
IOMMU groups still seem a bit unclear to me. Will Deacon has nicely
explained
what they represent in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014
On Mon, Jan 19, 2015 at 01:11:07AM +, Laurent Pinchart wrote:
On Friday 16 January 2015 10:13:11 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each
On Mon, Dec 15, 2014 at 03:35:29PM +, Mark Brown wrote:
On Mon, Dec 15, 2014 at 02:10:37PM +0100, Krzysztof Kozłowski wrote:
Few days ago I posted similar patch:
https://lkml.org/lkml/2014/12/5/268
but no one have picked it up.
Anyway the fix of yours seems fine to me.
I don't
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
+static int __init
On Mon, Dec 15, 2014 at 05:53:48PM +, Laurent Pinchart wrote:
Hi Will,
Hello again :)
On Monday 15 December 2014 17:43:02 Will Deacon wrote:
On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
On Monday 15 December 2014 17:17:00 Will Deacon wrote:
Creating
On Thu, Sep 25, 2014 at 11:43:35AM +0100, Marek Szyprowski wrote:
On 2014-09-24 19:06, Will Deacon wrote:
On Tue, Sep 16, 2014 at 12:54:28PM +0100, Marek Szyprowski wrote:
If device has no max_seg_size set, we assume that there is no limit and
force it to DMA_BIT_MASK(32) to always use
Hi Marek,
On Tue, Sep 16, 2014 at 12:54:28PM +0100, Marek Szyprowski wrote:
If device has no max_seg_size set, we assume that there is no limit and
force it to DMA_BIT_MASK(32) to always use contiguous mappings in DMA
address space.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
On Mon, Sep 08, 2014 at 03:05:40PM +0100, Javier Martinez Canillas wrote:
Hello Will,
Hi Javier,
Since many folks don't agree that hacking different subsystems is the way
forward I'll hold the patches and don't post them. The sunxi thread [0]
already shows how different people have strong
On Wed, Sep 10, 2014 at 05:03:52PM +0100, Doug Anderson wrote:
On Wed, Sep 10, 2014 at 4:17 AM, Will Deacon will.dea...@arm.com wrote:
On Mon, Sep 08, 2014 at 03:05:40PM +0100, Javier Martinez Canillas wrote:
Since many folks don't agree that hacking different subsystems is the way
forward
Hi all,
Sorry for the radio silence, the weekend happened :)
On Fri, Sep 05, 2014 at 02:56:42PM +0100, Vivek Gautam wrote:
On Fri, Sep 5, 2014 at 7:16 PM, Ajay kumar ajayn...@gmail.com wrote:
I'd usually try to debug this a bit further, but without a console it's
really painful to get
On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote:
At least for next 3.17-rc I'd suggest fixing this up in respective clock
driver and dropping the hack only after Exynos DRM patches are merged
and confirmed working.
Whilst I'm sympathetic to people working to enable DRM, I think
On Mon, Sep 08, 2014 at 12:55:29PM +0100, Javier Martinez Canillas wrote:
On 09/08/2014 01:21 PM, Will Deacon wrote:
On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote:
At least for next 3.17-rc I'd suggest fixing this up in respective clock
driver and dropping the hack only after
On Mon, Sep 08, 2014 at 04:55:31PM +0100, Doug Anderson wrote:
So simple-framebuffer is added to the device tree here:
https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c
That's one of the two patches to build your own U-Boot for enabling
simplefb.
Hi all,
I'm one of the few, foolish people to try running mainline on my 5250-based
Samsung Chromebook (snow). I can live without wireless, usb3 and video
acceleration, so actually it makes a reasonable development platform for
doing A15-based (micro)-architectural work.
However, since 3.15 I've
[Looks like it's not just Rutland that can't spell the address of the
mailing list today. Fixed here, so please use this post in any replies].
On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote:
Hi all,
I'm one of the few, foolish people to try running mainline on my 5250-based
On Thu, Jul 10, 2014 at 11:32:16PM +0100, Olav Haugan wrote:
On 7/9/2014 3:54 AM, Will Deacon wrote:
On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
So how does an algorithm figure this out in both my examples? The
algorithm would have to know about both (all) bus masters
On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
On 6/30/2014 2:52 AM, Will Deacon wrote:
On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote:
Lets say I have an IOMMU with 2 masters and 2 SMRn slots with the
following stream IDs coming from the masters:
Master 1
out there that
don't predict mov pc, lr at all (let alone do anything with the return
stack).
discussing this with Will Deacon over the last couple of days, who has
also been talking to the hardware people in ARM, and Will is happy with
this patch as in its current form.) This is why I've
Hi Olav,
On Fri, Jun 27, 2014 at 11:23:27PM +0100, Olav Haugan wrote:
On 6/25/2014 2:18 AM, Will Deacon wrote:
Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
hardware (from the SMMU architecture perspective), the SMRs are completely
programmable. Why doesn't
On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply
On Tue, Jun 24, 2014 at 10:35:54PM +0100, Olav Haugan wrote:
On 6/24/2014 11:11 AM, Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master
On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote:
On Wednesday 25 June 2014 10:17:02 Will Deacon wrote:
On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan
On Wed, Jun 25, 2014 at 10:48:31AM +0100, Arnd Bergmann wrote:
On Wednesday 25 June 2014 10:38:25 Will Deacon wrote:
On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote:
I think the situation is a bit different here: It's less about the corner
cases for the SMMU, but about
On Wed, Jun 25, 2014 at 11:12:13AM +0100, Arnd Bergmann wrote:
On Wednesday 25 June 2014 10:57:36 Will Deacon wrote:
So far, I've been avoiding the hardcoding. However, you could potentially
build a system with a small number of SMRs (compared to the number of
StreamIDs) and allocate
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
On 5/30/2014 12:06 PM, Arnd Bergmann wrote:
On Friday 30 May 2014 08:16:05 Rob Herring wrote:
Presumably the ID would be the streamID on ARM's SMMU. How would a
master with 8 streamIDs be described? This is what Calxeda midway has
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM
On Thu, Jun 19, 2014 at 05:40:49PM +0100, Tomasz Figa wrote:
On 19.06.2014 18:31, Doug Anderson wrote:
My personal vote would be to submit a patch to change cycles_t to
always be 32-bits. Given that 32-bits was fine for udelay() for ARM
that seems sane and simple. If someone later comes
On Fri, Jun 20, 2014 at 04:53:08PM +0100, Arnd Bergmann wrote:
On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
- Each master has a set of fixed StreamIDs
- StreamIDs can be remastered by adding a constant offset
On Tue, Jun 17, 2014 at 03:50:25PM +0100, Stuart Yoder wrote:
I think for simple masters (i.e. those that have all their StreamIDs
under control of one driver), then setting something during attach (or
add?) based on the DT could work pretty well. The other case is when we
have masters
On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
On Tue, Jun 17, 2014 at 01:18:11PM +0100, Will Deacon wrote:
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
On Wed, Jun 04, 2014 at 10:12:38PM
On Tue, Jun 17, 2014 at 11:26:48AM +0100, Varun Sethi wrote:
The way we generally thought it would work was something like
this:
-u-boot/bootloader makes any static streamID allocation if needed,
sets a default streamID (e.g. 0x0) in device and expresses
that in the device
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
It can easily be argued that if the algorithm used to remap the ID
varies, the compatibility
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
[...]
Arnd, can you take another look at this binding and see if there's
anything else missing? If
Hi Varun,
On Thu, Jun 05, 2014 at 08:10:19PM +0100, Varun Sethi wrote:
The set of StreamIDs that can be generated by a master is fixed in the
hardware. The SMMU can then be programmed to map these incoming IDs onto
a context ID (or a set of context IDs), which are the IDs used internally
Hi Stuart,
On Mon, Jun 16, 2014 at 05:56:32PM +0100, Stuart Yoder wrote:
Do you have use-cases where you really need to change these mappings
dynamically?
Yes. In the case of a PCI bus-- you may not know in advance how many
PCI devices there are until you probe the bus. We have another
On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote:
On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
The disadvantage of this is that this limits the max number of streamIDs
to support. If # of streamID is
On Wed, Jun 04, 2014 at 03:01:15PM +0100, Arnd Bergmann wrote:
On Wednesday 04 June 2014 14:56:01 Will Deacon wrote:
On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote:
On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
On Friday 30 May 2014 22:29:13 Hiroshi Doyu
On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote:
On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote:
In the strictest sense, no.
But for a large set of sane configurations, this probably works.
Small sets of randomly-assigned IDs can just be enumerated one by
On Fri, May 30, 2014 at 08:54:37PM +0100, Arnd Bergmann wrote:
On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
bit) to afford 64 stream IDs so that a single device can hold multiple
IDs. If we apply the same bitmap
On Tue, May 20, 2014 at 02:23:47PM +0100, Arnd Bergmann wrote:
Bit# 3322 1100
10987654 32109876 54321098 76543210
phys.hi cell: npt000ss dfff
phys.mid cell:
phys.lo cell:
On Wed, Jan 08, 2014 at 01:33:11PM +, Vivek Gautam wrote:
The erratum-773769 occurs on Arm Coretex-A15 (rev r2p0),
when L2 Data Ram latency is set to 4 cycles or more; or
when ACP is in use, or with L2 Data RAM slice configured.
Therefore, the effective latency as calculated in Table 7-2
On Sat, Oct 19, 2013 at 03:04:22PM +0100, Tomasz Figa wrote:
On Saturday 19 of October 2013 18:09:15 Sachin Kamat wrote:
Hi Tomasz,
On 17 October 2013 18:35, Tomasz Figa t.f...@samsung.com wrote:
Hi Sachin,
On Thursday 17 of October 2013 17:33:12 Sachin Kamat wrote:
L2x0 cache
On Thu, Aug 08, 2013 at 10:38:10PM +0100, Tomasz Figa wrote:
On Thursday 08 of August 2013 08:09:49 Rob Herring wrote:
On Thu, Aug 1, 2013 at 8:05 AM, Cho KyongHo pullip@samsung.com
wrote:
Should this align with ARM System MMU bindings?
System MMU in Exynos SoC is different from ARM
[adding Arnd, as he plays with randconfig too]
On Wed, Apr 17, 2013 at 10:25:34AM +0100, Chen Gang wrote:
On 2013年04月03日 18:29, Chen Gang wrote:
I repeat it again (but it report another location), and put the config as
attachment.
Thanks.
when you have time, please help check (if you
On Wed, Apr 03, 2013 at 10:46:53AM +0100, Chen Gang wrote:
Hello Maintainers:
when you have time, could you help to check this suggestion ?
[...]
make:
make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set arm-linux-gnu-
Hi Hiroshi,
On Wed, Jan 16, 2013 at 04:43:21PM +, Hiroshi Doyu wrote:
Will Deacon will.dea...@arm.com wrote @ Wed, 16 Jan 2013 12:51:14 +0100:
Given that this information is not discoverable, it needs to be encoded
in the device tree, but where? I can see two approaches:
1
On Wed, Dec 26, 2012 at 01:53:15AM +, Cho KyongHo wrote:
notice: v6 patch-set is rebased on next/iommu-exynos branch of
linux-samsung.git. This patch-set does not include 2 patches (05 and 06
patches in v5 patch-se) because they alread exist already in the branch.
Given that
On Tue, Dec 11, 2012 at 11:09:47AM +, Cho KyongHo wrote:
This commit adds System MMU nodes to DT of Exynos SoCs.
[Adding devicetree-discuss and some other IOMMU/DT people to CC]
Signed-off-by: KyongHo Cho pullip@samsung.com
---
.../devicetree/bindings/arm/exynos/system-mmu.txt |
On Fri, Oct 26, 2012 at 05:05:36AM +0100, Chanho Park wrote:
I agree that we definitely want to support the PMU on Exynos4, but I'm
tempted to postpone adding that code until DT support is available.
I already included DT support for exynos4(except exynos4412) in this patchset.
(Please
On Thu, Oct 25, 2012 at 02:41:46AM +0100, Chanho Park wrote:
On Tue, Oct 23, 2012 at 10:34 PM, Chanho Park
chanho61.p...@samsung.com wrote:
This patch defines irq numbers of ARM performance monitoring unit for
exynos4.
Firs of all, we need to fix IRQ_PMU correctly and to split pmu
On Tue, Oct 23, 2012 at 03:48:21PM +0100, Kukjin Kim wrote:
Hi all,
Now, v3.7-rc2 happens following build error with s3c2410_defconfig...
ERROR: read_current_timer [fs/ext4/ext4.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: *** Waiting for
On Wed, Aug 29, 2012 at 02:14:56AM +0100, Chanho Park wrote:
This patch define irq numbers of ARM performance monitoring unit for exynos4.
The number of CPU cores and PMU irq numbers are vary according to soc types.
So we need to identify each soc type using soc_is_xxx function and define the
On Sat, Jul 28, 2012 at 05:26:43AM +0100, Chanho Park wrote:
We have devicetree bindings for the PMU -- why can't you use those instead
of probing the SoC all the time?
Exynos4 isn't fully supported the DT yet. Thus, we should support legacy
probing.
Ok, but what about Exynos5? You seem
On Fri, Jul 27, 2012 at 09:08:29AM +0100, Chanho Park wrote:
This patch define irq numbers of ARM performance monitoring unit for
exynos4/5.
The number of CPU cores and PMU irq numbers are vary according to soc types.
So we need to identify each soc type using soc_is_xxx function and define
On Wed, Feb 01, 2012 at 08:50:23AM +, Olof Johansson wrote:
On Tue, Jan 31, 2012 at 8:20 PM, Kyungmin Park kmp...@infradead.org wrote:
As I remember only DT based board file is acceptable for mainline?
For a new SoC family like 5250 it would be much preferred to only add
device-tree
Hi Kukjin,
On Tue, Jan 31, 2012 at 12:11:10PM +, Kukjin Kim wrote:
Actually, the number of A15 CPU core gets from L2 control
register not SCU configuration.
Suggested-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Russell King
On Tue, Jan 31, 2012 at 02:21:28PM +, Kukjin Kim wrote:
On 01/31/12 23:13, Will Deacon wrote:
This doesn't belong in smp.c but, more importantly, this doesn't work for
multi-cluster configurations at all. Since all A15 implementations will be
on new platforms, the code will be device
PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ { IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ{ IRQ_PB1176_SCI }
This looks fine to me. It matches what I posted originally, which was the
intention.
Acked-by: Will Deacon will.dea...@arm.com
On Tue, Jan 24, 2012 at 09:45:31PM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 05:26:00PM +, Will Deacon wrote:
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
On Wed, Jan 25, 2012 at 10:22:02AM +, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 09:58:00AM +, Will Deacon wrote:
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
Hi Russell,
On Tue, Jan 24, 2012 at 09:50:09AM +, Russell King - ARM Linux wrote:
Right, although it's out there - but I'd like to get the AMBA changes
into it which are already conflicting the Samsung development. So I'm
going to hold off officially asking for people to include the
On Tue, Jan 24, 2012 at 11:27:45AM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 10:56:45AM +, Will Deacon wrote:
I took a look at your amba branch, but all I can see in there is:
6cfa627 ARM: 7079/1: spi: Fix builderror in spi-pl022.c
1c3be36 PM: add runtime PM
++--
3 files changed, 14 insertions(+), 31 deletions(-)
Looks good to me, and I've boot-tested it on my board as well.
Acked-by: Will Deacon will.dea...@arm.com
Will
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord
though; I suspect it's
related to the recent VIC changes and removal of MULTI_IRQ_HANDLER
(especially since the ethernet interrupts lives on the secondary
controller).
So for this patch:
Tested-by: Will Deacon will.dea...@arm.com
I'll investigate the other problem separately.
Will
--
To unsubscribe
Hi Russell,
On Fri, Jan 20, 2012 at 09:29:30AM +, Russell King - ARM Linux wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-realview/core.h| 20 ---
arch/arm/mach-realview/realview_eb.c | 38
+++---
files changed, 22 insertions(+), 97 deletions(-)
Seems happy enough on my Integrator-CP w/ 1136 core tile.
Tested-by: Will Deacon will.dea...@arm.com
Will
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More
On Tue, Jan 24, 2012 at 04:23:28PM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 04:00:44PM +, Will Deacon wrote:
but then I see a warning during boot:
[1.669654] [ cut here ]
[1.684021] WARNING: at drivers/amba/bus.c:514
On Wed, Dec 14, 2011 at 04:57:10AM +, Axel Lin wrote:
I got below build error on linux-next 20111213.
CC arch/arm/kernel/process.o
In file included from arch/arm/mach-s5p64x0/include/mach/system.h:16,
from arch/arm/kernel/process.c:64:
On Mon, Oct 10, 2011 at 12:56:24PM +0100, Thomas Abraham wrote:
Hi Will,
Hi Thomas,
What is your opinion about the following diff instead of the above one?
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 65cf8c6..035f5cd 100644
--- a/arch/arm/Kconfig.debug
+++
On Mon, Oct 10, 2011 at 01:35:54PM +0100, Thomas Abraham wrote:
There are no difficulties with the original patch. But that was not
how Samsung boards have been selecting the low level debug uart port
number. The proposed patch tried to maintain the old style.
Another point is that Samsung's
Hi Marc,
On Fri, Oct 07, 2011 at 10:44:59AM +0100, Marc Zyngier wrote:
So to make my suggestion completely clear, here's a patch I'm now
carrying in my tree. It's only been test compiled on EXYNOS4, but works
nicely on my 11MP. It turns both dist_base and cpu_base into per-cpu
variables,
73 matches
Mail list logo
