rrently are.
So, for the arm-smmu patch and the core IOMMU changes:
Acked-by: Will Deacon
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 "unsubsc
Hi Joerg,
Thanks for posting this!
On Mon, Jan 26, 2015 at 11:51:32PM +, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This allows to handle domains differently based on their
> type in the future. An IOMMU driver can implement certain
> optimizations for DMA-API domains for example.
>
> Si
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.infrad
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 ea
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 wr
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:
> >
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 tha
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.
>
>
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
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
> ---
> arch/arm/mm/
On Wed, Sep 10, 2014 at 05:03:52PM +0100, Doug Anderson wrote:
> On Wed, Sep 10, 2014 at 4:17 AM, Will Deacon 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
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 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.
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
> >&
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 t
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 wrote:
> >>> I'd usually try to debug this a bit further, but without a console it's
> >>> really painful to get anywhere. 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 m
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
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 t
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
patch after discussion with Russell). There are cores 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,
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
> >
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
> &g
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
> &
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,
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, Ola
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
> > > th
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. Howev
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 mi
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
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
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 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
> > > h
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
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
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 a
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 internal
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 mis
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 enumerate
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 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 i
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 b
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: ll
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-
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 wrote:
> > > Hi Sachin,
> > >
> > > On Thursday 17 of October 2013 17:33:12 Sachin Kamat wrote:
> > >> L2x0 cach
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
> wrote:
> > > Should this align with ARM System MMU bindings?
> > > System MMU in Exynos SoC is different from ARM System MMU.
[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 yo
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-l
Hi Hiroshi,
On Wed, Jan 16, 2013 at 04:43:21PM +, Hiroshi Doyu wrote:
> Will Deacon 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:
> >
&g
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
> ---
> .../devicetree/bindings/arm/exynos/system-mmu.txt | 86
> a
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 devicetree-
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.
>
On Thu, Oct 25, 2012 at 02:41:46AM +0100, Chanho Park wrote:
> > On Tue, Oct 23, 2012 at 10:34 PM, Chanho Park
> > 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
> > > initializati
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 f
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
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 defin
On Wed, Feb 01, 2012 at 08:50:23AM +, Olof Johansson wrote:
> On Tue, Jan 31, 2012 at 8:20 PM, Kyungmin Park 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 enabled boards.
A
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
>
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
> Signed-off-by: Kukjin Kim
> Cc: Russell King
> ---
NAK.
> diff --git a/arch/arm/include/a
_PB1176_GPIO0 }
> > +#define 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 25, 2012 at 10:22:02AM +, Russell King - ARM Linux wrote:
> On Wed, Jan 25, 2012 at 09:58:00AM +0000, 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 ab
On Tue, Jan 24, 2012 at 09:45:31PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 24, 2012 at 05:26:00PM +0000, 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 5c
On Tue, Jan 24, 2012 at 04:23:28PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 24, 2012 at 04:00:44PM +0000, Will Deacon wrote:
> > but then I see a warning during boot:
> >
> > [1.669654] [ cut here ]
> > [1.684021] WARNING
files changed, 22 insertions(+), 97 deletions(-)
Seems happy enough on my Integrator-CP w/ 1136 core tile.
Tested-by: Will Deacon
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 majordomo inf
Hi Russell,
On Fri, Jan 20, 2012 at 09:29:30AM +, Russell King - ARM Linux wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-realview/core.h| 20 ---
> arch/arm/mach-realview/realview_eb.c | 38
> +++---
> arch/arm/mach-realvi
tch 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
I'll investigate the other problem separately.
Will
--
To unsub
--
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.
On Tue, Jan 24, 2012 at 11:27:45AM +, Russell King - ARM Linux wrote:
> On Tue, Jan 24, 2012 at 10:56:45AM +0000, 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.
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 bas
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:
> arch/arm/plat-samsung/
On Thu, Oct 13, 2011 at 12:09:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 10, 2011 at 02:02:09PM +0100, Marc Zyngier wrote:
> > On 07/10/11 16:16, Will Deacon wrote:
> > > On Fri, Oct 07, 2011 at 10:44:59AM +0100, Marc Zyngier wrote:
> > &
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 Samsu
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
> +
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, r
75 matches
Mail list logo
