* [patch 2/2] arch/powerpc/platforms/pseries/eeh_event.c: slightly fix set_current_state() wart
From: akpm @ 2012-03-28 22:20 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, paulus
From: Andrew Morton <akpm@linux-foundation.org>
Subject: arch/powerpc/platforms/pseries/eeh_event.c: slightly fix set_current_state() wart
That set_current_state() won't work very well: the subsequent mutex_lock()
might flip the task back into TASK_RUNNING.
Attempt to put it somewhere where it might have been meant to be, and
attempt to describe why it might have been added.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/powerpc/platforms/pseries/eeh_event.c~arch-powerpc-platforms-pseries-eeh_eventc-slightly-fix-set_current_state-wart arch/powerpc/platforms/pseries/eeh_event.c
--- a/arch/powerpc/platforms/pseries/eeh_event.c~arch-powerpc-platforms-pseries-eeh_eventc-slightly-fix-set_current_state-wart
+++ a/arch/powerpc/platforms/pseries/eeh_event.c
@@ -60,7 +60,6 @@ static int eeh_event_handler(void * dumm
struct eeh_dev *edev;
set_task_comm(current, "eehd");
- set_current_state(TASK_INTERRUPTIBLE);
spin_lock_irqsave(&eeh_eventlist_lock, flags);
event = NULL;
@@ -83,6 +82,7 @@ static int eeh_event_handler(void * dumm
printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
eeh_pci_name(edev->pdev));
+ set_current_state(TASK_INTERRUPTIBLE); /* Don't add to load average */
edev = handle_eeh_events(event);
eeh_clear_slot(eeh_dev_to_of_node(edev), EEH_MODE_RECOVERING);
_
^ permalink raw reply
* Help initialize phy-less ethernet in 2.6.38
From: Fabio @ 2012-03-28 16:13 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am a newbie trying to get the FCC1 ethernet interface to work on a
custom board.
The hardware used is based on mpc8270 which is connected via FCC1 to a
phy-less interface linked to another microcontroller.
FCC1 should be recognized as eth0 by the linux kernel and it should
receive data when set up in promiscuous mode.
Currently during the boot it seems that the device initialization goes
ok but I can't understand why I can't receive data when I put the
interface in promiscuous mode.
Going into details I can see that the fs_enet probe function gets called.
I customized it to setup the fs_platform_info structure using the
values taken from the old kernel driver for now.
The only fields I cannot setup are the bus_id,phy_irq,phy_addr because
they are not part of the fs_platform_info data structure anymore.
I can't see any errors during the initialization, but I can't receive
data on the interface.
I think the problem can be in an interrupt misconfiguration but I
haven't figured out how to configure the ethernet dts part in the
right way or how to handle the phy-less situation correctly.
--- dts snippet ---
eth0: ethernet@11300 {
device_type = "network";
compatible = "fsl,cpm2-fcc-enet";
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
local-mac-address = [ 00 01 02 03 04 05 ];
interrupts = <32 8>;
interrupt-parent = <&PIC>;
linux,network-index = <0>;
fsl,cpm-command = <0x12000300>;
};
---
Thanks in advance,
--
Fabio Pozzi
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
From: Kumar Gala @ 2012-03-28 14:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Varun Sethi, Linuxppc-dev, Stuart Yoder
In-Reply-To: <4F721209.5030706@freescale.com>
On Mar 27, 2012, at 2:16 PM, Scott Wood wrote:
> On 03/27/2012 01:44 PM, Scott Wood wrote:
>> On 03/27/2012 10:21 AM, Stuart Yoder wrote:
>>> On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>>>=20
>>>> On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
>>>>=20
>>>>> FSL MPIC supports 16 bit vectors so our vector number space isn't
>>>>> restricted to 256 vectors. We should use the MPIC_LARG_VECTORS =
flag
>>>>> while intializing the MPIC. This also prevents us from eating in =
to
>>>>> hardware vector number space (MSIs) while setting up internal =
sources.
>>>>=20
>>>> What is driving this change?
>>>=20
>>> Whats driving the change is proper handling of error interrupts. =
Right
>>> now error interrupts (muxed on int 16) are treated as a shared
>>> interrupt source. We want each to be handled as a individual =
interrupt
>>> source...thus the desire to support more than 256 interrupts.
>>=20
>> We don't actually need more than 256 interrupts for this (the =
individual
>> error interrupts are not counted against this). But unless we change
>> how vectors are allocated, we need vectors >=3D 256, since we have =
MSIs
>> close enough to 256 that under the current scheme the IPIs, timers, =
and
>> such collide with the third MSI bank.
>=20
> Note that this is the case today even without the error interrupt =
stuff
> -- the highest vector used by MSIs on MPIC 4.1 is 0xf7, and we have 13
> special vectors (4 IPIs, 8 timers, and spurious).
This all makes sense, what I ask is that the commit message be updated =
to convey this.
- k=
^ permalink raw reply
* RE: [PATCHv2 01/14] common: dma-mapping: introduce alloc_attrs and free_attrs methods
From: Marek Szyprowski @ 2012-03-28 14:38 UTC (permalink / raw)
To: 'Sergei Shtylyov'
Cc: linux-mips, 'Kevin Cernekee', linux-ia64, linux-sh,
linux-mm, sparclinux, 'Guan Xuetao', linux-arch,
'Stephen Rothwell', 'Jonathan Corbet', x86,
'Matt Turner', 'Dezhong Diao',
'Fenghua Yu', 'Arnd Bergmann', microblaze-uclinux,
linaro-mm-sig, 'Ivan Kokshaysky', Andrzej Pietrasiewicz,
'Thomas Gleixner', linux-arm-kernel,
'Richard Henderson', discuss, 'Michal Simek',
'Tony Luck', linux-kernel, 'Richard Kuo',
'FUJITA Tomonori', 'Kyungmin Park',
'Paul Mundt', linux-alpha, 'Andrew Morton',
linuxppc-dev, 'David S. Miller'
In-Reply-To: <4F72F603.2000803@mvista.com>
Hi Sergei,
On Wednesday, March 28, 2012 1:29 PM Sergei Shtylyov wrote:
> On 27-03-2012 17:42, Marek Szyprowski wrote:
>
> > Introduce new generic alloc and free methods with attributes argument.
>
> The method names don't match the ones in the subject.
Right, I will reword the subject to "common: dma-mapping: introduce generic alloc()
and free() methods".
> > Existing alloc_coherent and free_coherent can be implemented on top of the
> > new calls with NULL attributes argument. Later also dma_alloc_non_coherent
> > can be implemented using DMA_ATTR_NONCOHERENT attribute as well as
> > dma_alloc_writecombine with separate DMA_ATTR_WRITECOMBINE attribute.
>
> > This way the drivers will get more generic, platform independent way of
> > allocating dma buffers with specific parameters.
>
> > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> > Reviewed-by: David Gibson <david@gibson.dropbear.ud.au>
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Kumar Gala @ 2012-03-28 14:35 UTC (permalink / raw)
To: Scott Wood; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <4F720FE3.7080101@freescale.com>
On Mar 27, 2012, at 2:07 PM, Scott Wood wrote:
> On 03/27/2012 08:59 AM, Kumar Gala wrote:
>>=20
>> On Mar 27, 2012, at 7:17 AM, Varun Sethi wrote:
>>=20
>>> All SOC device error interrupts are muxed and delivered to the core =
as a single
>>> MPIC error interrupt. Currently all the device drivers requiring =
access to device
>>> errors have to register for the MPIC error interrupt as a shared =
interrupt.
>>>=20
>>> With this patch we add interrupt demuxing capability in the mpic =
driver, allowing
>>> device drivers to register for their individual error interrupts. =
This is achieved
>>> by handling error interrupts in a cascaded fashion.
>>>=20
>>> MPIC error interrupt is handled by the "error_int_handler", which =
subsequently demuxes
>>> it using the EISR and delivers it to the respective drivers.=20
>>>=20
>>> The error interrupt capability is dependent on the MPIC EIMR =
register, which was
>>> introduced in FSL MPIC version 4.1 (P4080 rev2). So, error interrupt =
demuxing capability
>>> is dependent on the MPIC version and can be used for versions >=3D =
4.1.
>>>=20
>>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>>> ---
>>=20
>> This isn't quite right. Doing the 'request_irq' on behalf of the =
driver isn't treating the error interrupts as a real cascade, in =
addition to how you are hooking things up.
>=20
> Define "real cascade". If you mean the chained handler stuff that's =
how
> Varun initially did it and I asked him to change it, because it gets a
> lot trickier to get things right, and I didn't see what it was buying =
us.
>=20
> The request_irq() isn't on behalf of the individual drivers, it's
> requesting the cascade itself (not a shared interrupt).
I missed the bit related to err_int_config_done, need to re-look at it. =
Was thinking request_irq() was getting called for every error interrupt.
>> I think you need to add proper irq_domain_ops, etc. Thus when we map =
the virq the proper thing can happen
>=20
> What proper thing is not happening?
>=20
> Maybe it would be cleaner from an interrupt number management
> perspective to keep things more separate, but do you have a functional
> issue in mind?
>=20
>> I'd also suggest maybe thinking about pulling this code into an =
mpic_fsl.c
>>=20
>>> arch/powerpc/include/asm/mpic.h | 18 +++++
>>> arch/powerpc/sysdev/mpic.c | 155 =
++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 171 insertions(+), 2 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/mpic.h =
b/arch/powerpc/include/asm/mpic.h
>>> index 3929b4b..db51015 100644
>>> --- a/arch/powerpc/include/asm/mpic.h
>>> +++ b/arch/powerpc/include/asm/mpic.h
>>> @@ -114,12 +114,21 @@
>>> #define MPIC_FSL_BRR1 0x00000
>>> #define MPIC_FSL_BRR1_VER 0x0000ffff
>>>=20
>>> +/*
>>> + * Error interrupt registers
>>> + */
>>> +
>>> +#define MPIC_ERR_INT_BASE 0x3900
>>> +#define MPIC_ERR_INT_EISR 0x0000
>>> +#define MPIC_ERR_INT_EIMR 0x0010
>>> +
>>> #define MPIC_MAX_IRQ_SOURCES 2048
>>> #define MPIC_MAX_CPUS 32
>>> #define MPIC_MAX_ISU 32
>>>=20
>>> #define MPIC_MAX_TIMER 8
>>> #define MPIC_MAX_IPI 4
>>> +#define MPIC_MAX_ERR 32
>>=20
>> Should probably be 64
>=20
> This patch supports MPIC 4.1 and EISR0. When support is added for =
EISR1
> (didn't realize this was coming until your comment prompted me to
> check...), this should be updated, but this change alone would not =
make
> it work.
Would prefer we handle this now rather than later (T4240 is going to =
need EISR1 support).
>>> +static void mpic_mask_err(struct irq_data *d)
>>> +{
>>> + u32 eimr;
>>> + struct mpic *mpic =3D mpic_from_irq_data(d);
>>> + unsigned int src =3D virq_to_hw(d->irq) - mpic->err_int_vecs[0];
>>> + unsigned int err_reg_offset =3D MPIC_INFO(ERR_INT_EIMR);
>>> +
>>> + eimr =3D mpic_err_read(err_reg_offset);
>>> + eimr |=3D (0x80000000 >> src);
>>=20
>> This seems funny, add a comment about src # and bit # being opposite.
>=20
> People in PPC-land should be used to this craziness by now. :-P
:), as I said a comment would be helpful.
>> Maybe do:
>>=20
>> eimr |=3D (1 << (31 - src));
>=20
> I'm not sure it's really any clearer that way...
>=20
>>> +static irqreturn_t error_int_handler(int irq, void *data)
>>> +{
>>> + struct mpic *mpic =3D (struct mpic *) data;
>>> + unsigned int eisr_offset =3D MPIC_INFO(ERR_INT_EISR);
>>> + unsigned int eimr_offset =3D MPIC_INFO(ERR_INT_EIMR);
>>> + u32 eisr, eimr;
>>> + int errint;
>>> + unsigned int cascade_irq;
>>> +
>>> + eisr =3D mpic_err_read(eisr_offset);
>>> + eimr =3D mpic_err_read(eimr_offset);
>>> +
>>> + if (!(eisr & ~eimr))
>>> + return IRQ_NONE;
>>> +
>>> + while (eisr) {
>>> + errint =3D __ffs(eisr);
>>> + cascade_irq =3D irq_linear_revmap(mpic->irqhost,
>>> + mpic->err_int_vecs[31 - errint]);
>>=20
>> Should 31, be replaced w/MPIC_MAX_ERR - 1 ?
>=20
> No, the 31 here is due to the backwards bit numbering within the
> register. It'd be better to say "errint =3D 31 - __ffs(eisr)" -- or
> perhaps "errint =3D __builtin_clz(eisr)".
gotcha
- k=
^ permalink raw reply
* Re: [PATCHv2 01/14] common: dma-mapping: introduce alloc_attrs and free_attrs methods
From: Sergei Shtylyov @ 2012-03-28 11:29 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Matt Turner, Dezhong Diao, Fenghua Yu,
Arnd Bergmann, microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
Richard Kuo, FUJITA Tomonori, Kyungmin Park, Paul Mundt,
linux-alpha, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-2-git-send-email-m.szyprowski@samsung.com>
Hello.
On 27-03-2012 17:42, Marek Szyprowski wrote:
> Introduce new generic alloc and free methods with attributes argument.
The method names don't match the ones in the subject.
> Existing alloc_coherent and free_coherent can be implemented on top of the
> new calls with NULL attributes argument. Later also dma_alloc_non_coherent
> can be implemented using DMA_ATTR_NONCOHERENT attribute as well as
> dma_alloc_writecombine with separate DMA_ATTR_WRITECOMBINE attribute.
> This way the drivers will get more generic, platform independent way of
> allocating dma buffers with specific parameters.
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.ud.au>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 10/10] oom: Make find_lock_task_mm() sparse-aware
From: David Rientjes @ 2012-03-28 7:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Mike Frysinger, user-mode-linux-devel, linux-sh, linuxppc-dev,
Oleg Nesterov, linux-kernel, linux-mm, Anton Vorontsov,
Paul Mundt, John Stultz, KOSAKI Motohiro, Richard Weinberger,
Russell King, Andrew Morton, uclinux-dist-devel, linux-arm-kernel
In-Reply-To: <1332593574.16159.31.camel@twins>
On Sat, 24 Mar 2012, Peter Zijlstra wrote:
> Yeah, so Nacked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
> Also, why didn't lockdep catch it?
>
> Fix sparse already instead of smearing ugly all over.
>
Fully agreed, please don't add this to the oom killer.
^ permalink raw reply
* RE: [PATCHv2 09/14] Unicore32: adapt for dma_map_ops changes
From: Marek Szyprowski @ 2012-03-28 6:10 UTC (permalink / raw)
To: 'Guan Xuetao'
Cc: linux-mips, 'Kevin Cernekee', linux-ia64, linux-sh,
linux-mm, sparclinux, linux-arch, 'Stephen Rothwell',
'Jonathan Corbet', x86, 'Matt Turner',
'Dezhong Diao', 'Fenghua Yu',
'Arnd Bergmann', microblaze-uclinux, linaro-mm-sig,
'Ivan Kokshaysky', Andrzej Pietrasiewicz,
'Thomas Gleixner', linux-arm-kernel,
'Richard Henderson', discuss, 'Michal Simek',
'Tony Luck', linux-kernel, 'Richard Kuo',
'FUJITA Tomonori', 'Kyungmin Park',
'Paul Mundt', linux-alpha, 'Andrew Morton',
linuxppc-dev, 'David S. Miller'
In-Reply-To: <4F7275FE.8000100@mprc.pku.edu.cn>
Hello,
On Wednesday, March 28, 2012 4:23 AM Guan Xuetao wrote:
> On 03/27/2012 09:42 PM, Marek Szyprowski wrote:
> > diff --git a/arch/unicore32/mm/dma-swiotlb.c b/arch/unicore32/mm/dma-swiotlb.c
> > index bfa9fbb..4cf5f0c 100644
> > --- a/arch/unicore32/mm/dma-swiotlb.c
> > +++ b/arch/unicore32/mm/dma-swiotlb.c
> > @@ -17,9 +17,23 @@
> >
> > #include<asm/dma.h>
> >
> > +static void *unicore_swiotlb_alloc_coherent(struct device *dev, size_t size,
> > + dma_addr_t *dma_handle, gfp_t flags,
> > + struct dma_attrs *attrs)
> > +{
> > + return swiotlb_alloc_coherent(dev, size, dma_handle, flags);
> > +}
> > +
> > +static void unicode_swiotlb_free_coherent(struct device *dev, size_t size,
> The bit is ok for me. Only a typo here, please change unicode to unicore.
Ups, I'm sorry for that typo. I've fixed it on my git tree:
http://git.linaro.org/gitweb?p=people/mszyprowski/linux-dma-mapping.git;a=commitdiff;h=bbe43c05b0653
9c09f89e07bcaf61ea0fca8d67f
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-28 5:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <4F720462.5020400@freescale.com>
On Tue, 27 Mar 2012 13:18:10 -0500, Timur Tabi <timur@freescale.com> wrote:
> Grant, do you have a moment to consider my question? Like I said, I'm
> anxious to get a fix into 3.3.
I've been out of town for the past week, so email processing volume
has been low. Answer below.
> Timur Tabi wrote:
> > Timur Tabi wrote:
> >> They only problem I see with this is that I am thinking about modifying
> >> the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
> >> directly. If I do that, then who should call of_platform_populate()?
> >
> > Grant, could you tell me if there's anything actually work with my patch?
> > All I'm doing is adding a couple more commonly used entries to
> > mpc85xx_common_ids[]. After all, they're common IDs, so don't they belong
> > into an array called common_ids?
That's between you and Kumar. I don't have any problem with it since
it's all contained within the mpc85xx code.
If those nodes really do make sense to represent as independent
platform devices, then adding them to the match list for bus types
isn't a problem.
g.
^ permalink raw reply
* Re: [PATCHv2 07/14] SH: adapt for dma_map_ops changes
From: Paul Mundt @ 2012-03-28 4:15 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Matt Turner, Dezhong Diao, Fenghua Yu,
Arnd Bergmann, microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
Richard Kuo, FUJITA Tomonori, Kyungmin Park, linux-alpha,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-8-git-send-email-m.szyprowski@samsung.com>
On Tue, Mar 27, 2012 at 03:42:41PM +0200, Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>
> Adapt core SH architecture code for dma_map_ops changes: replace
> alloc/free_coherent with generic alloc/free methods.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: [PATCHv2 04/14] PowerPC: adapt for dma_map_ops changes
From: Benjamin Herrenschmidt @ 2012-03-28 3:56 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Matt Turner, Dezhong Diao, Fenghua Yu,
Arnd Bergmann, microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
Richard Kuo, FUJITA Tomonori, Kyungmin Park, Paul Mundt,
linux-alpha, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-5-git-send-email-m.szyprowski@samsung.com>
On Tue, 2012-03-27 at 15:42 +0200, Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>
> Adapt core PowerPC architecture code for dma_map_ops changes: replace
> alloc/free_coherent with generic alloc/free methods.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> [added missing changes to arch/powerpc/kernel/vio.c]
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
FYI. David and Arnd reviews are good enough for me ppc-side.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCHv2 09/14] Unicore32: adapt for dma_map_ops changes
From: Guan Xuetao @ 2012-03-28 2:22 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, linux-arch, Stephen Rothwell, Jonathan Corbet, x86,
Matt Turner, Dezhong Diao, Fenghua Yu, Arnd Bergmann,
microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
Richard Kuo, FUJITA Tomonori, Kyungmin Park, Paul Mundt,
linux-alpha, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-10-git-send-email-m.szyprowski@samsung.com>
On 03/27/2012 09:42 PM, Marek Szyprowski wrote:
> diff --git a/arch/unicore32/mm/dma-swiotlb.c b/arch/unicore32/mm/dma-swiotlb.c
> index bfa9fbb..4cf5f0c 100644
> --- a/arch/unicore32/mm/dma-swiotlb.c
> +++ b/arch/unicore32/mm/dma-swiotlb.c
> @@ -17,9 +17,23 @@
>
> #include<asm/dma.h>
>
> +static void *unicore_swiotlb_alloc_coherent(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flags,
> + struct dma_attrs *attrs)
> +{
> + return swiotlb_alloc_coherent(dev, size, dma_handle, flags);
> +}
> +
> +static void unicode_swiotlb_free_coherent(struct device *dev, size_t size,
The bit is ok for me. Only a typo here, please change unicode to unicore.
Thanks and Regards.
Guan Xuetao
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2012-03-28 3:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a few more things for powerpc this time around:
- Anton's did some recent improvements to EPOW event reporting
on pSeries (power supply failures and such). The patches are self
contained enough and replace really nasty code so I felt it should
still go in
- I did the vio driver registration change Greg requested, I
don't see the point of leaving that til the next merge window
- The remaining EEH changes I said were still pending to get
rid of the EEH references from the generic struct device_node
- A few more iSeries removal bits
- A perf bug fix on 970
Cheers,
Ben.
The following changes since commit e22057c8599373e5caef0bc42bdb95d2a361ab0d:
Merge tag 'stable/for-linus-3.4-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen (2012-03-24 12:20:25 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
for you to fetch changes up to 1ce447b90f3e71c81ae59e0062bc305ef267668b:
powerpc/perf: Fix instruction address sampling on 970 and Power4 (2012-03-28 11:33:24 +1100)
----------------------------------------------------------------
Anton Blanchard (6):
powerpc: Make function that parses RTAS error logs global
powerpc/pseries: Parse and handle EPOW interrupts
powerpc/pseries: Use rtas_get_sensor in RAS code
powerpc/pseries: Remove RTAS_POWERMGM_EVENTS
powerpc/pseries: Clean up ras_error_interrupt code
powerpc/pseries: Cut down on enthusiastic use of defines in RAS code
Benjamin Herrenschmidt (2):
powerpc+sparc/vio: Modernize driver registration
powerpc/perf: Fix instruction address sampling on 970 and Power4
Gavin Shan (3):
powerpc/eeh: Remove eeh device from OF node
powerpc/eeh: Remove eeh information from pci_dn
powerpc/eeh: Retrieve PHB from global list
Stephen Rothwell (2):
powerpc: Remove NO_IRQ_IGNORE
powerpc: Random little legacy iSeries removal tidy ups
arch/powerpc/boot/.gitignore | 1 -
arch/powerpc/include/asm/iommu.h | 1 -
arch/powerpc/include/asm/irq.h | 6 -
arch/powerpc/include/asm/machdep.h | 4 +-
arch/powerpc/include/asm/mmu-hash64.h | 12 --
arch/powerpc/include/asm/pci-bridge.h | 16 +-
arch/powerpc/include/asm/perf_event_server.h | 2 +
arch/powerpc/include/asm/rtas.h | 34 ++++-
arch/powerpc/include/asm/smp.h | 1 -
arch/powerpc/include/asm/udbg.h | 1 -
arch/powerpc/include/asm/vio.h | 10 +-
arch/powerpc/kernel/irq.c | 8 +-
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/rtas.c | 34 +++++
arch/powerpc/kernel/udbg.c | 3 -
arch/powerpc/kernel/vdso.c | 4 +-
arch/powerpc/kernel/vio.c | 12 +-
arch/powerpc/perf/core-book3s.c | 46 +++++-
arch/powerpc/perf/power4-pmu.c | 1 +
arch/powerpc/perf/ppc970-pmu.c | 1 +
arch/powerpc/platforms/cell/beat_htab.c | 2 -
arch/powerpc/platforms/pseries/eeh.c | 19 +--
arch/powerpc/platforms/pseries/eeh_dev.c | 2 +-
arch/powerpc/platforms/pseries/io_event_irq.c | 68 +---------
arch/powerpc/platforms/pseries/iommu.c | 29 ++--
arch/powerpc/platforms/pseries/ras.c | 195 ++++++++++++++++---------
arch/sparc/include/asm/vio.h | 9 +-
arch/sparc/kernel/ds.c | 5 +-
arch/sparc/kernel/vio.c | 8 +-
drivers/block/sunvdc.c | 5 +-
drivers/net/ethernet/ibm/ibmveth.c | 7 +-
drivers/net/ethernet/sun/sunvnet.c | 5 +-
drivers/scsi/ibmvscsi/ibmvfc.c | 7 +-
drivers/scsi/ibmvscsi/ibmvscsi.c | 7 +-
drivers/scsi/ibmvscsi/ibmvstgt.c | 5 +-
drivers/tty/hvc/hvc_vio.c | 7 +-
drivers/tty/hvc/hvcs.c | 5 +-
include/linux/of.h | 10 --
38 files changed, 321 insertions(+), 273 deletions(-)
^ permalink raw reply
* Re: [PATCH v2.1 01/10] cpu: Introduce clear_tasks_mm_cpumask() helper
From: Benjamin Herrenschmidt @ 2012-03-28 0:01 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Mike Frysinger, Peter Zijlstra, user-mode-linux-devel, linux-sh,
Richard Weinberger, linux-kernel, Russell King, linux-mm,
Anton Vorontsov, Paul Mundt, John Stultz, KOSAKI Motohiro,
uclinux-dist-devel, Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120325174210.GA23605@redhat.com>
On Sun, 2012-03-25 at 19:42 +0200, Oleg Nesterov wrote:
> > Also, Per Peter Zijlstra's idea, now we don't grab tasklist_lock in
> > the new helper, instead we take the rcu read lock. We can do this
> > because the function is called after the cpu is taken down and
> marked
> > offline, so no new tasks will get this cpu set in their mm mask.
>
> And only powerpc needs rcu_read_lock() and task_lock().
>
> OTOH, I do not understand why powepc does this on CPU_DEAD...
> And probably CPU_UP_CANCELED doesn't need to clear mm_cpumask().
>
> That said, personally I think these patches are fine, the common
> helper makes sense.
Not strictly speaking a problem with this patch, but I was wondering...
Do we know for sure that the mmu context has been fully flushed out
before the unplug ? idle_task_exit() will do a context switch but in our
case that may not be enough.
Once the CPU is offline, tlb flushes won't hit it any more so it can get
out of sync (in some cases the offlining process is just some kind of
deep sleep loop that doesn't involve a TLB state loss).
Should we add a flush_tlb_mm of all those bits in that loop ? that would
be a tad expensive... we don't have a flush_tlb_all() as a generic kind
of accessors, but we could add something like that as a requirement for
ppc_md.cpu_die ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 05/14] IA64: adapt for dma_map_ops changes
From: Luck, Tony @ 2012-03-27 21:53 UTC (permalink / raw)
To: Luck, Tony, Marek Szyprowski
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
linux-sh@vger.kernel.org, linux-mm@kvack.org,
sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
Stephen Rothwell, Jonathan Corbet, x86@kernel.org, Arnd Bergmann,
microblaze-uclinux@itee.uq.edu.au, linaro-mm-sig@lists.linaro.org,
Andrzej Pietrasiewicz, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, discuss@x86-64.org,
linux-kernel@vger.kernel.org, Kyungmin Park,
linux-alpha@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CA+8MBbLAafFbVwviFmkjD0DNz5RsCbB_TNLL67wEi2k-hyXkXA@mail.gmail.com>
> until part 5 (when ia64 sees the changes to match). You could either mer=
ge part
> 5 into part 2 (to make a combined x86+ia64 piece
Doh! I see that you already did this in the re-post you did a few hours
ago (which my mail client had filed away in my linux-arch folder).
-Tony
=20
^ permalink raw reply
* Re: [PATCH 05/14] IA64: adapt for dma_map_ops changes
From: Tony Luck @ 2012-03-27 21:20 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
linux-arch, Stephen Rothwell, Jonathan Corbet, x86, Arnd Bergmann,
microblaze-uclinux, linaro-mm-sig, Andrzej Pietrasiewicz,
Thomas Gleixner, linux-arm-kernel, discuss, linux-kernel,
Kyungmin Park, linux-alpha, Andrew Morton, linuxppc-dev
In-Reply-To: <1324643253-3024-6-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 23, 2011 at 4:27 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>
> Adapt core IA64 architecture code for dma_map_ops changes: replace
> alloc/free_coherent with generic alloc/free methods.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> =A0arch/ia64/hp/common/sba_iommu.c =A0 =A0 | =A0 11 ++++++-----
> =A0arch/ia64/include/asm/dma-mapping.h | =A0 18 ++++++++++++------
> =A0arch/ia64/kernel/pci-swiotlb.c =A0 =A0 =A0| =A0 =A09 +++++----
> =A0arch/ia64/sn/pci/pci_dma.c =A0 =A0 =A0 =A0 =A0| =A0 =A09 +++++----
> =A04 files changed, 28 insertions(+), 19 deletions(-)
The series breaks bisection from part 2 (when the x86 part changes
lib/swiotlb.c)
until part 5 (when ia64 sees the changes to match). You could either merge=
part
5 into part 2 (to make a combined x86+ia64 piece) ... or try to pull
the libswiotlb
changes into their own piece (which would have some of the ia64 and x86 bit=
s).
Or at the very least minimize the breakage window by putting ia64
right after x86
in the patch sequence.
Otherwise seems OK
Acked-by: Tony Luck <tony.luck@intel.com>
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
From: Scott Wood @ 2012-03-27 19:16 UTC (permalink / raw)
To: Stuart Yoder; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <4F720A90.1040600@freescale.com>
On 03/27/2012 01:44 PM, Scott Wood wrote:
> On 03/27/2012 10:21 AM, Stuart Yoder wrote:
>> On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>
>>> On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
>>>
>>>> FSL MPIC supports 16 bit vectors so our vector number space isn't
>>>> restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
>>>> while intializing the MPIC. This also prevents us from eating in to
>>>> hardware vector number space (MSIs) while setting up internal sources.
>>>
>>> What is driving this change?
>>
>> Whats driving the change is proper handling of error interrupts. Right
>> now error interrupts (muxed on int 16) are treated as a shared
>> interrupt source. We want each to be handled as a individual interrupt
>> source...thus the desire to support more than 256 interrupts.
>
> We don't actually need more than 256 interrupts for this (the individual
> error interrupts are not counted against this). But unless we change
> how vectors are allocated, we need vectors >= 256, since we have MSIs
> close enough to 256 that under the current scheme the IPIs, timers, and
> such collide with the third MSI bank.
Note that this is the case today even without the error interrupt stuff
-- the highest vector used by MSIs on MPIC 4.1 is 0xf7, and we have 13
special vectors (4 IPIs, 8 timers, and spurious).
-Scott
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Scott Wood @ 2012-03-27 19:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <7F9EFF8D-82E4-414E-BB76-24BE84F2D8BC@kernel.crashing.org>
On 03/27/2012 08:59 AM, Kumar Gala wrote:
>
> On Mar 27, 2012, at 7:17 AM, Varun Sethi wrote:
>
>> All SOC device error interrupts are muxed and delivered to the core as a single
>> MPIC error interrupt. Currently all the device drivers requiring access to device
>> errors have to register for the MPIC error interrupt as a shared interrupt.
>>
>> With this patch we add interrupt demuxing capability in the mpic driver, allowing
>> device drivers to register for their individual error interrupts. This is achieved
>> by handling error interrupts in a cascaded fashion.
>>
>> MPIC error interrupt is handled by the "error_int_handler", which subsequently demuxes
>> it using the EISR and delivers it to the respective drivers.
>>
>> The error interrupt capability is dependent on the MPIC EIMR register, which was
>> introduced in FSL MPIC version 4.1 (P4080 rev2). So, error interrupt demuxing capability
>> is dependent on the MPIC version and can be used for versions >= 4.1.
>>
>> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>> ---
>
> This isn't quite right. Doing the 'request_irq' on behalf of the driver isn't treating the error interrupts as a real cascade, in addition to how you are hooking things up.
Define "real cascade". If you mean the chained handler stuff that's how
Varun initially did it and I asked him to change it, because it gets a
lot trickier to get things right, and I didn't see what it was buying us.
The request_irq() isn't on behalf of the individual drivers, it's
requesting the cascade itself (not a shared interrupt).
> I think you need to add proper irq_domain_ops, etc. Thus when we map the virq the proper thing can happen
What proper thing is not happening?
Maybe it would be cleaner from an interrupt number management
perspective to keep things more separate, but do you have a functional
issue in mind?
> I'd also suggest maybe thinking about pulling this code into an mpic_fsl.c
>
>> arch/powerpc/include/asm/mpic.h | 18 +++++
>> arch/powerpc/sysdev/mpic.c | 155 ++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 171 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
>> index 3929b4b..db51015 100644
>> --- a/arch/powerpc/include/asm/mpic.h
>> +++ b/arch/powerpc/include/asm/mpic.h
>> @@ -114,12 +114,21 @@
>> #define MPIC_FSL_BRR1 0x00000
>> #define MPIC_FSL_BRR1_VER 0x0000ffff
>>
>> +/*
>> + * Error interrupt registers
>> + */
>> +
>> +#define MPIC_ERR_INT_BASE 0x3900
>> +#define MPIC_ERR_INT_EISR 0x0000
>> +#define MPIC_ERR_INT_EIMR 0x0010
>> +
>> #define MPIC_MAX_IRQ_SOURCES 2048
>> #define MPIC_MAX_CPUS 32
>> #define MPIC_MAX_ISU 32
>>
>> #define MPIC_MAX_TIMER 8
>> #define MPIC_MAX_IPI 4
>> +#define MPIC_MAX_ERR 32
>
> Should probably be 64
This patch supports MPIC 4.1 and EISR0. When support is added for EISR1
(didn't realize this was coming until your comment prompted me to
check...), this should be updated, but this change alone would not make
it work.
>> +static void mpic_mask_err(struct irq_data *d)
>> +{
>> + u32 eimr;
>> + struct mpic *mpic = mpic_from_irq_data(d);
>> + unsigned int src = virq_to_hw(d->irq) - mpic->err_int_vecs[0];
>> + unsigned int err_reg_offset = MPIC_INFO(ERR_INT_EIMR);
>> +
>> + eimr = mpic_err_read(err_reg_offset);
>> + eimr |= (0x80000000 >> src);
>
> This seems funny, add a comment about src # and bit # being opposite.
People in PPC-land should be used to this craziness by now. :-P
> Maybe do:
>
> eimr |= (1 << (31 - src));
I'm not sure it's really any clearer that way...
>> +static irqreturn_t error_int_handler(int irq, void *data)
>> +{
>> + struct mpic *mpic = (struct mpic *) data;
>> + unsigned int eisr_offset = MPIC_INFO(ERR_INT_EISR);
>> + unsigned int eimr_offset = MPIC_INFO(ERR_INT_EIMR);
>> + u32 eisr, eimr;
>> + int errint;
>> + unsigned int cascade_irq;
>> +
>> + eisr = mpic_err_read(eisr_offset);
>> + eimr = mpic_err_read(eimr_offset);
>> +
>> + if (!(eisr & ~eimr))
>> + return IRQ_NONE;
>> +
>> + while (eisr) {
>> + errint = __ffs(eisr);
>> + cascade_irq = irq_linear_revmap(mpic->irqhost,
>> + mpic->err_int_vecs[31 - errint]);
>
> Should 31, be replaced w/MPIC_MAX_ERR - 1 ?
No, the 31 here is due to the backwards bit numbering within the
register. It'd be better to say "errint = 31 - __ffs(eisr)" -- or
perhaps "errint = __builtin_clz(eisr)".
-Scott
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
From: Scott Wood @ 2012-03-27 18:47 UTC (permalink / raw)
To: Stuart Yoder; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <4F720A90.1040600@freescale.com>
On 03/27/2012 01:44 PM, Scott Wood wrote:
> On 03/27/2012 10:21 AM, Stuart Yoder wrote:
>> On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>
>>> On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
>>>
>>>> FSL MPIC supports 16 bit vectors so our vector number space isn't
>>>> restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
>>>> while intializing the MPIC. This also prevents us from eating in to
>>>> hardware vector number space (MSIs) while setting up internal sources.
>>>
>>> What is driving this change?
>>
>> Whats driving the change is proper handling of error interrupts. Right
>> now error interrupts (muxed on int 16) are treated as a shared
>> interrupt source. We want each to be handled as a individual interrupt
>> source...thus the desire to support more than 256 interrupts.
>
> We don't actually need more than 256 interrupts for this (the individual
> error interrupts are not counted against this). But unless we change
> how vectors are allocated, we need vectors >= 256, since we have MSIs
> close enough to 256 that under the current scheme the IPIs, timers, and
> such collide with the third MSI bank.
Sorry, I misremembered -- the error interrupts do count against the 256,
but only for Linux IRQ numbering purposes (not hardware vector assignment).
-Scott
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
From: Scott Wood @ 2012-03-27 18:44 UTC (permalink / raw)
To: Stuart Yoder; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <CALRxmdDhHpxDoemWj6u_NUJtOfmAWo9U0YgO0xNzpqOt4EXD9w@mail.gmail.com>
On 03/27/2012 10:21 AM, Stuart Yoder wrote:
> On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
>>
>>> FSL MPIC supports 16 bit vectors so our vector number space isn't
>>> restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
>>> while intializing the MPIC. This also prevents us from eating in to
>>> hardware vector number space (MSIs) while setting up internal sources.
>>
>> What is driving this change?
>
> Whats driving the change is proper handling of error interrupts. Right
> now error interrupts (muxed on int 16) are treated as a shared
> interrupt source. We want each to be handled as a individual interrupt
> source...thus the desire to support more than 256 interrupts.
We don't actually need more than 256 interrupts for this (the individual
error interrupts are not counted against this). But unless we change
how vectors are allocated, we need vectors >= 256, since we have MSIs
close enough to 256 that under the current scheme the IPIs, timers, and
such collide with the third MSI bank.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Timur Tabi @ 2012-03-27 18:18 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <4F69F099.4070409@freescale.com>
Grant, do you have a moment to consider my question? Like I said, I'm
anxious to get a fix into 3.3.
Timur Tabi wrote:
> Timur Tabi wrote:
>> They only problem I see with this is that I am thinking about modifying
>> the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
>> directly. If I do that, then who should call of_platform_populate()?
>
> Grant, could you tell me if there's anything actually work with my patch?
> All I'm doing is adding a couple more commonly used entries to
> mpc85xx_common_ids[]. After all, they're common IDs, so don't they belong
> into an array called common_ids?
>
> I've been waiting for months for this problem to be fixed, and 3.3 is
> broken without it. We've already established that you cannot actually
> call of_platform_bus_probe() twice on the same level, so it's not like my
> patch description is wrong or anything.
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCHv2 10/14] Hexagon: adapt for dma_map_ops changes
From: Richard Kuo @ 2012-03-27 16:41 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Matt Turner, Dezhong Diao, Fenghua Yu,
Arnd Bergmann, microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
FUJITA Tomonori, Kyungmin Park, Paul Mundt, linux-alpha,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-11-git-send-email-m.szyprowski@samsung.com>
On Tue, Mar 27, 2012 at 03:42:44PM +0200, Marek Szyprowski wrote:
> Adapt core Hexagon architecture code for dma_map_ops changes: replace
> alloc/free_coherent with generic alloc/free methods.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/hexagon/include/asm/dma-mapping.h | 18 ++++++++++++------
> arch/hexagon/kernel/dma.c | 9 +++++----
> 2 files changed, 17 insertions(+), 10 deletions(-)
>
Acked-by: Richard Kuo <rkuo@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH V2 1/2] rapidio: add DMA engine support for RIO data transfers
From: Vinod Koul @ 2012-03-27 16:11 UTC (permalink / raw)
To: Alexandre Bounine
Cc: dan.j.williams, linux-kernel, paul.gortmaker, linuxppc-dev, akpm
In-Reply-To: <1332794725-1928-1-git-send-email-alexandre.bounine@idt.com>
On Mon, 2012-03-26 at 16:45 -0400, Alexandre Bounine wrote:
> Adds DMA Engine framework support into RapidIO subsystem.
> Uses DMA Engine DMA_SLAVE interface to generate data transfers to/from
> remote RapidIO target devices.
> Introduces RapidIO-specific wrapper for prep_slave_sg() interface
> with an extra parameter to pass target specific information.
> Uses scatterlist to describe local data buffer. Address flat data buffer
> on a remote side.
>
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Acked by: Vinod Koul <vinod.koul@linux.intel.com>
> ---
>
> This patch is applicable to linux-next-20120326 and after.
>
> v2: Uses updated DMA engine prep_slave_sg() interface.
> See https://lkml.org/lkml/2012/3/8/373 for more details.
>
> drivers/rapidio/Kconfig | 14 ++++++++
> drivers/rapidio/rio.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/dmaengine.h | 12 +++++++
> include/linux/rio.h | 47 ++++++++++++++++++++++++++
> include/linux/rio_drv.h | 9 +++++
> 5 files changed, 163 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig
> index bc87192..6194d35 100644
> --- a/drivers/rapidio/Kconfig
> +++ b/drivers/rapidio/Kconfig
> @@ -22,6 +22,20 @@ config RAPIDIO_ENABLE_RX_TX_PORTS
> ports for Input/Output direction to allow other traffic
> than Maintenance transfers.
>
> +config RAPIDIO_DMA_ENGINE
> + bool "DMA Engine support for RapidIO"
> + depends on RAPIDIO
> + select DMADEVICES
> + select DMA_ENGINE
> + help
> + Say Y here if you want to use DMA Engine frameork for RapidIO data
> + transfers to/from target RIO devices. RapidIO uses NREAD and
> + NWRITE (NWRITE_R, SWRITE) requests to transfer data between local
> + memory and memory on remote target device. You need a DMA controller
> + capable to perform data transfers to/from RapidIO.
> +
> + If you are unsure about this, say Y here.
> +
> config RAPIDIO_DEBUG
> bool "RapidIO subsystem debug messages"
> depends on RAPIDIO
> diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
> index 86c9a09..c40665a 100644
> --- a/drivers/rapidio/rio.c
> +++ b/drivers/rapidio/rio.c
> @@ -1121,6 +1121,87 @@ int rio_std_route_clr_table(struct rio_mport *mport, u16 destid, u8 hopcount,
> return 0;
> }
>
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> +
> +static bool rio_chan_filter(struct dma_chan *chan, void *arg)
> +{
> + struct rio_dev *rdev = arg;
> +
> + /* Check that DMA device belongs to the right MPORT */
> + return (rdev->net->hport ==
> + container_of(chan->device, struct rio_mport, dma));
> +}
> +
> +/**
> + * rio_request_dma - request RapidIO capable DMA channel that supports
> + * specified target RapidIO device.
> + * @rdev: RIO device control structure
> + *
> + * Returns pointer to allocated DMA channel or NULL if failed.
> + */
> +struct dma_chan *rio_request_dma(struct rio_dev *rdev)
> +{
> + dma_cap_mask_t mask;
> + struct dma_chan *dchan;
> +
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> + dchan = dma_request_channel(mask, rio_chan_filter, rdev);
> +
> + return dchan;
> +}
> +EXPORT_SYMBOL_GPL(rio_request_dma);
> +
> +/**
> + * rio_release_dma - release specified DMA channel
> + * @dchan: DMA channel to release
> + */
> +void rio_release_dma(struct dma_chan *dchan)
> +{
> + dma_release_channel(dchan);
> +}
> +EXPORT_SYMBOL_GPL(rio_release_dma);
> +
> +/**
> + * rio_dma_prep_slave_sg - RapidIO specific wrapper
> + * for device_prep_slave_sg callback defined by DMAENGINE.
> + * @rdev: RIO device control structure
> + * @dchan: DMA channel to configure
> + * @data: RIO specific data descriptor
> + * @direction: DMA data transfer direction (TO or FROM the device)
> + * @flags: dmaengine defined flags
> + *
> + * Initializes RapidIO capable DMA channel for the specified data transfer.
> + * Uses DMA channel private extension to pass information related to remote
> + * target RIO device.
> + * Returns pointer to DMA transaction descriptor or NULL if failed.
> + */
> +struct dma_async_tx_descriptor *rio_dma_prep_slave_sg(struct rio_dev *rdev,
> + struct dma_chan *dchan, struct rio_dma_data *data,
> + enum dma_transfer_direction direction, unsigned long flags)
> +{
> + struct dma_async_tx_descriptor *txd = NULL;
> + struct rio_dma_ext rio_ext;
> +
> + if (dchan->device->device_prep_slave_sg == NULL) {
> + pr_err("%s: prep_rio_sg == NULL\n", __func__);
> + return NULL;
> + }
> +
> + rio_ext.destid = rdev->destid;
> + rio_ext.rio_addr_u = data->rio_addr_u;
> + rio_ext.rio_addr = data->rio_addr;
> + rio_ext.wr_type = data->wr_type;
> +
> + txd = dmaengine_prep_rio_sg(dchan, data->sg, data->sg_len,
> + direction, flags, &rio_ext);
> +
> + return txd;
> +}
> +EXPORT_SYMBOL_GPL(rio_dma_prep_slave_sg);
> +
> +#endif /* CONFIG_RAPIDIO_DMA_ENGINE */
> +
> static void rio_fixup_device(struct rio_dev *dev)
> {
> }
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 676f967..3596a3a 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -633,6 +633,18 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> dir, flags, NULL);
> }
>
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> +struct rio_dma_ext;
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
> + struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> + enum dma_transfer_direction dir, unsigned long flags,
> + struct rio_dma_ext *rio_ext)
> +{
> + return chan->device->device_prep_slave_sg(chan, sgl, sg_len,
> + dir, flags, rio_ext);
> +}
> +#endif
> +
> static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
> struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> size_t period_len, enum dma_transfer_direction dir)
> diff --git a/include/linux/rio.h b/include/linux/rio.h
> index 4d50611..a90ebad 100644
> --- a/include/linux/rio.h
> +++ b/include/linux/rio.h
> @@ -20,6 +20,9 @@
> #include <linux/errno.h>
> #include <linux/device.h>
> #include <linux/rio_regs.h>
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> +#include <linux/dmaengine.h>
> +#endif
>
> #define RIO_NO_HOPCOUNT -1
> #define RIO_INVALID_DESTID 0xffff
> @@ -254,6 +257,9 @@ struct rio_mport {
> u32 phys_efptr;
> unsigned char name[40];
> void *priv; /* Master port private data */
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> + struct dma_device dma;
> +#endif
> };
>
> /**
> @@ -395,6 +401,47 @@ union rio_pw_msg {
> u32 raw[RIO_PW_MSG_SIZE/sizeof(u32)];
> };
>
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> +
> +/**
> + * enum rio_write_type - RIO write transaction types used in DMA transfers
> + *
> + * Note: RapidIO specification defines write (NWRITE) and
> + * write-with-response (NWRITE_R) data transfer operations.
> + * Existing DMA controllers that service RapidIO may use one of these operations
> + * for entire data transfer or their combination with only the last data packet
> + * requires response.
> + */
> +enum rio_write_type {
> + RDW_DEFAULT, /* default method used by DMA driver */
> + RDW_ALL_NWRITE, /* all packets use NWRITE */
> + RDW_ALL_NWRITE_R, /* all packets use NWRITE_R */
> + RDW_LAST_NWRITE_R, /* last packet uses NWRITE_R, others - NWRITE */
> +};
> +
> +struct rio_dma_ext {
> + u16 destid;
> + u64 rio_addr; /* low 64-bits of 66-bit RapidIO address */
> + u8 rio_addr_u; /* upper 2-bits of 66-bit RapidIO address */
> + enum rio_write_type wr_type; /* preferred RIO write operation type */
> +};
> +
> +struct rio_dma_data {
> + /* Local data (as scatterlist) */
> + struct scatterlist *sg; /* I/O scatter list */
> + unsigned int sg_len; /* size of scatter list */
> + /* Remote device address (flat buffer) */
> + u64 rio_addr; /* low 64-bits of 66-bit RapidIO address */
> + u8 rio_addr_u; /* upper 2-bits of 66-bit RapidIO address */
> + enum rio_write_type wr_type; /* preferred RIO write operation type */
> +};
> +
> +static inline struct rio_mport *dma_to_mport(struct dma_device *ddev)
> +{
> + return container_of(ddev, struct rio_mport, dma);
> +}
> +#endif /* CONFIG_RAPIDIO_DMA_ENGINE */
> +
> /* Architecture and hardware-specific functions */
> extern int rio_register_mport(struct rio_mport *);
> extern int rio_open_inb_mbox(struct rio_mport *, void *, int, int);
> diff --git a/include/linux/rio_drv.h b/include/linux/rio_drv.h
> index 7f07470..31ad146 100644
> --- a/include/linux/rio_drv.h
> +++ b/include/linux/rio_drv.h
> @@ -377,6 +377,15 @@ void rio_unregister_driver(struct rio_driver *);
> struct rio_dev *rio_dev_get(struct rio_dev *);
> void rio_dev_put(struct rio_dev *);
>
> +#ifdef CONFIG_RAPIDIO_DMA_ENGINE
> +extern struct dma_chan *rio_request_dma(struct rio_dev *rdev);
> +extern void rio_release_dma(struct dma_chan *dchan);
> +extern struct dma_async_tx_descriptor *rio_dma_prep_slave_sg(
> + struct rio_dev *rdev, struct dma_chan *dchan,
> + struct rio_dma_data *data,
> + enum dma_transfer_direction direction, unsigned long flags);
> +#endif
> +
> /**
> * rio_name - Get the unique RIO device identifier
> * @rdev: RIO device
--
~Vinod
^ permalink raw reply
* Re: [PATCHv2 06/14] Alpha: adapt for dma_map_ops changes
From: Matt Turner @ 2012-03-27 15:56 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Dezhong Diao, Fenghua Yu, Arnd Bergmann,
microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, discuss, Michal Simek, Tony Luck, linux-kernel,
Richard Kuo, FUJITA Tomonori, Kyungmin Park, Paul Mundt,
linux-alpha, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-7-git-send-email-m.szyprowski@samsung.com>
On Tue, Mar 27, 2012 at 9:42 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>
> Adapt core Alpha architecture code for dma_map_ops changes: replace
> alloc/free_coherent with generic alloc/free methods.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
> =A0arch/alpha/include/asm/dma-mapping.h | =A0 18 ++++++++++++------
> =A0arch/alpha/kernel/pci-noop.c =A0 =A0 =A0 =A0 | =A0 10 ++++++----
> =A0arch/alpha/kernel/pci_iommu.c =A0 =A0 =A0 =A0| =A0 10 ++++++----
> =A03 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/arch/alpha/include/asm/dma-mapping.h b/arch/alpha/include/as=
m/dma-mapping.h
> index 4567aca..dfa32f0 100644
> --- a/arch/alpha/include/asm/dma-mapping.h
> +++ b/arch/alpha/include/asm/dma-mapping.h
> @@ -12,16 +12,22 @@ static inline struct dma_map_ops *get_dma_ops(struct =
device *dev)
>
> =A0#include <asm-generic/dma-mapping-common.h>
>
> -static inline void *dma_alloc_coherent(struct device *dev, size_t size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0dma_addr_t *dma_handle, gfp_t gfp)
> +#define dma_alloc_coherent(d,s,h,f) =A0 =A0dma_alloc_attrs(d,s,h,f,NULL)
> +
> +static inline void *dma_alloc_attrs(struct device *dev, size_t size,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma=
_addr_t *dma_handle, gfp_t gfp,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct dma_attrs *attrs)
> =A0{
> - =A0 =A0 =A0 return get_dma_ops(dev)->alloc_coherent(dev, size, dma_hand=
le, gfp);
> + =A0 =A0 =A0 return get_dma_ops(dev)->alloc(dev, size, dma_handle, gfp, =
attrs);
> =A0}
>
> -static inline void dma_free_coherent(struct device *dev, size_t size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
void *vaddr, dma_addr_t dma_handle)
> +#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
> +
> +static inline void dma_free_attrs(struct device *dev, size_t size,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void *v=
addr, dma_addr_t dma_handle,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct =
dma_attrs *attrs)
> =A0{
> - =A0 =A0 =A0 get_dma_ops(dev)->free_coherent(dev, size, vaddr, dma_handl=
e);
> + =A0 =A0 =A0 get_dma_ops(dev)->free(dev, size, vaddr, dma_handle, attrs)=
;
> =A0}
>
> =A0static inline int dma_mapping_error(struct device *dev, dma_addr_t dma=
_addr)
> diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
> index 04eea48..df24b76 100644
> --- a/arch/alpha/kernel/pci-noop.c
> +++ b/arch/alpha/kernel/pci-noop.c
> @@ -108,7 +108,8 @@ sys_pciconfig_write(unsigned long bus, unsigned long =
dfn,
> =A0}
>
> =A0static void *alpha_noop_alloc_coherent(struct device *dev, size_t size=
,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0dma_addr_t *dma_handle, gfp_t gfp)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0dma_addr_t *dma_handle, gfp_t gfp,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0struct dma_attrs *attrs)
> =A0{
> =A0 =A0 =A0 =A0void *ret;
>
> @@ -123,7 +124,8 @@ static void *alpha_noop_alloc_coherent(struct device =
*dev, size_t size,
> =A0}
>
> =A0static void alpha_noop_free_coherent(struct device *dev, size_t size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
void *cpu_addr, dma_addr_t dma_addr)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
void *cpu_addr, dma_addr_t dma_addr,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
struct dma_attrs *attrs)
> =A0{
> =A0 =A0 =A0 =A0free_pages((unsigned long)cpu_addr, get_order(size));
> =A0}
> @@ -174,8 +176,8 @@ static int alpha_noop_set_mask(struct device *dev, u6=
4 mask)
> =A0}
>
> =A0struct dma_map_ops alpha_noop_ops =3D {
> - =A0 =A0 =A0 .alloc_coherent =A0 =A0 =A0 =A0 =3D alpha_noop_alloc_cohere=
nt,
> - =A0 =A0 =A0 .free_coherent =A0 =A0 =A0 =A0 =A0=3D alpha_noop_free_coher=
ent,
> + =A0 =A0 =A0 .alloc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D alpha_noop_al=
loc_coherent,
> + =A0 =A0 =A0 .free =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_noop_fr=
ee_coherent,
> =A0 =A0 =A0 =A0.map_page =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_noop_map_p=
age,
> =A0 =A0 =A0 =A0.map_sg =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_noop_map=
_sg,
> =A0 =A0 =A0 =A0.mapping_error =A0 =A0 =A0 =A0 =A0=3D alpha_noop_mapping_e=
rror,
> diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.=
c
> index 4361080..cd63479 100644
> --- a/arch/alpha/kernel/pci_iommu.c
> +++ b/arch/alpha/kernel/pci_iommu.c
> @@ -434,7 +434,8 @@ static void alpha_pci_unmap_page(struct device *dev, =
dma_addr_t dma_addr,
> =A0 =A0else DMA_ADDRP is undefined. =A0*/
>
> =A0static void *alpha_pci_alloc_coherent(struct device *dev, size_t size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
dma_addr_t *dma_addrp, gfp_t gfp)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
dma_addr_t *dma_addrp, gfp_t gfp,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
struct dma_attrs *attrs)
> =A0{
> =A0 =A0 =A0 =A0struct pci_dev *pdev =3D alpha_gendev_to_pci(dev);
> =A0 =A0 =A0 =A0void *cpu_addr;
> @@ -478,7 +479,8 @@ try_again:
> =A0 =A0DMA_ADDR past this call are illegal. =A0*/
>
> =A0static void alpha_pci_free_coherent(struct device *dev, size_t size,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 voi=
d *cpu_addr, dma_addr_t dma_addr)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 voi=
d *cpu_addr, dma_addr_t dma_addr,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 str=
uct dma_attrs *attrs)
> =A0{
> =A0 =A0 =A0 =A0struct pci_dev *pdev =3D alpha_gendev_to_pci(dev);
> =A0 =A0 =A0 =A0pci_unmap_single(pdev, dma_addr, size, PCI_DMA_BIDIRECTION=
AL);
> @@ -952,8 +954,8 @@ static int alpha_pci_set_mask(struct device *dev, u64=
mask)
> =A0}
>
> =A0struct dma_map_ops alpha_pci_ops =3D {
> - =A0 =A0 =A0 .alloc_coherent =A0 =A0 =A0 =A0 =3D alpha_pci_alloc_coheren=
t,
> - =A0 =A0 =A0 .free_coherent =A0 =A0 =A0 =A0 =A0=3D alpha_pci_free_cohere=
nt,
> + =A0 =A0 =A0 .alloc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D alpha_pci_all=
oc_coherent,
> + =A0 =A0 =A0 .free =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_pci_fre=
e_coherent,
> =A0 =A0 =A0 =A0.map_page =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_pci_map_pa=
ge,
> =A0 =A0 =A0 =A0.unmap_page =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_pci_unmap_pa=
ge,
> =A0 =A0 =A0 =A0.map_sg =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D alpha_pci_map_=
sg,
> --
> 1.7.1.569.g6f426
>
Acked-by: Matt Turner <mattst88@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.
From: Stuart Yoder @ 2012-03-27 15:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: Varun Sethi, Linuxppc-dev
In-Reply-To: <295B3D3A-F038-4176-90EF-423A6BB84F62@kernel.crashing.org>
On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
>
>> FSL MPIC supports 16 bit vectors so our vector number space isn't
>> restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
>> while intializing the MPIC. This also prevents us from eating in to
>> hardware vector number space (MSIs) while setting up internal sources.
>
> What is driving this change?
Whats driving the change is proper handling of error interrupts. Right
now error interrupts (muxed on int 16) are treated as a shared
interrupt source. We want each to be handled as a individual interrupt
source...thus the desire to support more than 256 interrupts.
Stuart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox