Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Troy Kisky troy.ki...@boundarydevices.com writes:
Reserve channels 0,1,12,13 and
slots 78-109 for dsp use on dm644x.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
I've only verified that channels 0, and 78-101 need
reserved, but reserving a little extra seems like
a good idea.
I'm not crazy about this hard-coded reservation.
The DSP code has a kernel-side driver (dsplinkk.) That driver
should be doing the channel reservations.
Kevin
arch/arm/mach-davinci/dm644x.c|6 ++
arch/arm/mach-davinci/dma.c |8
arch/arm/mach-davinci/include/mach/edma.h |7 ++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 6a08568..86eb9ef 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -403,6 +403,12 @@ static struct edma_soc_info dm644x_edma_info = {
.n_slot = 128,
.n_tc = 2,
.noevent= dma_chan_dm644x_no_event,
+/* reserve slots 78-109 for dsp use */
+ .dsp_reserve_slot_min = 78,
+ .dsp_reserve_slot_max = 78 + 31,
+/* reserve channels 0, 1, 12, 13 for dsp use */
+ .dsp_reserve_channel_min = 0,
+ .dsp_reserve_channel_max = 13,
};
static struct resource edma_resources[] = {
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 1f58631..f2e6b8a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -1051,6 +1051,14 @@ static int __init edma_probe(struct platform_device
*pdev)
while (*noevent != -1)
set_bit(*noevent++, edma_noevent);
}
+ for (i = info-dsp_reserve_slot_min;
+ i = info-dsp_reserve_slot_max; i++)
+ set_bit(i, edma_inuse);
+
+ for (i = info-dsp_reserve_channel_min;
+ i = info-dsp_reserve_channel_max; i++)
+ if (test_bit(i, edma_noevent))
+ set_bit(i, edma_inuse);
irq = platform_get_irq(pdev, 0);
status = request_irq(irq, dma_irq_handler, 0, edma, pdev-dev);
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index b467358..cb45960 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -222,8 +222,13 @@ struct edma_soc_info {
unsignedn_slot;
unsignedn_tc;
- /* list of channels with no even trigger; terminated by -1 */
+ /* list of channels with no event trigger; terminated by -1 */
const s8*noevent;
+ u16 dsp_reserve_slot_min;
+ u16 dsp_reserve_slot_max;
+ /* only no event channels in range below are reserved */
+ u16 dsp_reserve_channel_min;
+ u16 dsp_reserve_channel_max;
};
#endif
--
1.5.4.3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Kevin Hilman wrote: Troy Kisky troy.ki...@boundarydevices.com writes: Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I've only verified that channels 0, and 78-101 need reserved, but reserving a little extra seems like a good idea. I'm not crazy about this hard-coded reservation. The DSP code has a kernel-side driver (dsplinkk.) That driver should be doing the channel reservations. Kevin I totally agree. Is anyone working on changing this??? Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Ring, Chris wrote: It's a bit too much info, but please review the Overview section here: http://tiexpressdsp.com/index.php?title=Dma_overview It attempts to describe challenges in hard-coding DMA resources on systems with multiple cores that must cooperate. Fortunately the DMA resource managers are typically flexible - so long as the users of the resources behave (e.g. codecs ask for resources from FC resource managers rather than hard-code channels). I agree with Kevin, no one should be hard-coding resources, Linux-side/BIOS-side or otherwise, unless perhaps it's a completely closed system. Finally, a detail, DSP Link doesn't manage DSP-side DMA resources - Framework Components and the EDMA3LLD (LLD == Low-Level Driver) do. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Friday, April 17, 2009 5:02 AM To: Troy Kisky Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage Troy Kisky troy.ki...@boundarydevices.com writes: Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I've only verified that channels 0, and 78-101 need reserved, but reserving a little extra seems like a good idea. I'm not crazy about this hard-coded reservation. The DSP code has a kernel-side driver (dsplinkk.) That driver should be doing the channel reservations. Kevin Very interesting Chris. So, the plan is for the dsp to ask for resources as needed? Or to request all upfront? Thanks Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
It may not have been clear, there's sort of a 2 phase resource management: 1. At build/config time where the resources are statically partitioned - some for ARM, some for DSP - and given to their respective CPU-specific resource managers. I think originally we simply cut the DMA resources in half and gave half to each CPU. 2. At run time where SW on each CPU (e.g. drivers/codecs) asks the CPU-specific resource manager for resources from their CPU-specific partition. There's no current support for the DSP resource manager stealing resources from Linux or vice-versa. The initial partitioning takes place once up front (in unfortunately 2 different you-can-easily-introduce-collisions ways). I guess my comment was just cautioning us against stuff like this... Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. ... because it's going to change from user to user and we'll never get it right all the time. I think we just need to make sure it's easy enough to change the config (on both sides!) and over-document it. Chris -Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, April 17, 2009 3:17 PM To: Ring, Chris Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage Ring, Chris wrote: It's a bit too much info, but please review the Overview section here: http://tiexpressdsp.com/index.php?title=Dma_overview It attempts to describe challenges in hard-coding DMA resources on systems with multiple cores that must cooperate. Fortunately the DMA resource managers are typically flexible - so long as the users of the resources behave (e.g. codecs ask for resources from FC resource managers rather than hard-code channels). I agree with Kevin, no one should be hard-coding resources, Linux-side/BIOS-side or otherwise, unless perhaps it's a completely closed system. Finally, a detail, DSP Link doesn't manage DSP-side DMA resources - Framework Components and the EDMA3LLD (LLD == Low-Level Driver) do. Chris -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Friday, April 17, 2009 5:02 AM To: Troy Kisky Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage Troy Kisky troy.ki...@boundarydevices.com writes: Reserve channels 0,1,12,13 and slots 78-109 for dsp use on dm644x. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I've only verified that channels 0, and 78-101 need reserved, but reserving a little extra seems like a good idea. I'm not crazy about this hard-coded reservation. The DSP code has a kernel-side driver (dsplinkk.) That driver should be doing the channel reservations. Kevin Very interesting Chris. So, the plan is for the dsp to ask for resources as needed? Or to request all upfront? Thanks Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Ring, Chris wrote: It may not have been clear, there's sort of a 2 phase resource management: 1. At build/config time where the resources are statically partitioned - some for ARM, some for DSP - and given to their respective CPU-specific resource managers. I think originally we simply cut the DMA resources in half and gave half to each CPU. This is what will need changed eventually. The sooner the better. My patch at least gets the our mpeg4 codec running again. But I agree will Kevin that this is not a long term solution. Is TI looking into this? 2. At run time where SW on each CPU (e.g. drivers/codecs) asks the CPU-specific resource manager for resources from their CPU-specific partition. There's no current support for the DSP resource manager stealing resources from Linux or vice-versa. The initial partitioning takes place once up front (in unfortunately 2 different you-can-easily-introduce-collisions ways). I guess my comment was just cautioning us against stuff like this... Thanks for the info Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage
Why does this patch get your mpeg4 codec to work - b/c the codec has a hard-coded channel 0 it needs (so your patch keeps channel 0 out of Linux's partition)? If so, IMHO, that change doesn't belong in the mainline tree - that's a customer-specific integration issue. FWIW, the architecturally 'right' thing to do would be for the codec to get this resource via DSP-side DMAN3 or RMAN rather than hard-code it. Is TI looking into this? Is TI looking into what - dynamically repartitioning DMA resources across CPUs at runtime? I don't think so, though I'm personally not at all against the idea. Chris -Original Message- From: Troy Kisky [mailto:troy.ki...@boundarydevices.com] Sent: Friday, April 17, 2009 4:15 PM To: Ring, Chris Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: edma: reserve dsp dma usage Ring, Chris wrote: It may not have been clear, there's sort of a 2 phase resource management: 1. At build/config time where the resources are statically partitioned - some for ARM, some for DSP - and given to their respective CPU-specific resource managers. I think originally we simply cut the DMA resources in half and gave half to each CPU. This is what will need changed eventually. The sooner the better. My patch at least gets the our mpeg4 codec running again. But I agree will Kevin that this is not a long term solution. Is TI looking into this? 2. At run time where SW on each CPU (e.g. drivers/codecs) asks the CPU-specific resource manager for resources from their CPU-specific partition. There's no current support for the DSP resource manager stealing resources from Linux or vice-versa. The initial partitioning takes place once up front (in unfortunately 2 different you-can-easily-introduce-collisions ways). I guess my comment was just cautioning us against stuff like this... Thanks for the info Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
