Re: Device node for a controller with two interrupt parents
On Wed, Mar 21, 2012 at 07:55:43AM +0530, Thomas Abraham wrote: > Hi, > > Exynos5 includes a gpio wakeup interrupt controller that generates 32 > interrupts. The first 16 interrupts are routed to the interrupt > combiner controller. The last 16 are muxed into one interrupt and this > interrupt line is connected to the GIC interrupt controller. > > So, the wakeup interrupt controller node in device tree requires two > interrupt parents. I do not know how to handle this. Any suggestions > will be very helpful. This has occurred before, for example on the MAL device on 440EP (see the bamboo board dts for example). The semi-standard approach is to make the node an interrupt-nexus for itself. That is in the node's interrupts property, just list 0..N giving as many interrupts as you need. Set the node's interrupt-parent to point to the node itself, then add interrupt-map and interrupt-map-mask properties which remap those interrupts 0..N to the correct interrupts on the actual interrupt controllers. Each entry in the interrupt map specifies an interrupt parent phandle, so you can distribute the irqs to multiple interrupt controllers that way. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- 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
Device node for a controller with two interrupt parents
Hi, Exynos5 includes a gpio wakeup interrupt controller that generates 32 interrupts. The first 16 interrupts are routed to the interrupt combiner controller. The last 16 are muxed into one interrupt and this interrupt line is connected to the GIC interrupt controller. So, the wakeup interrupt controller node in device tree requires two interrupt parents. I do not know how to handle this. Any suggestions will be very helpful. Thanks, Thomas. -- 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
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
On Tue, Mar 20, 2012 at 10:50 PM, Subash Patel wrote: > Sorry for digging this very late. But as part of integrating dma_map v7 & > sysmmu v12 on 3.3-rc5, I am facing below issue: > > a) By un-selecting IOMMU in menu config, I am able to allocate memory in > vb2-dma-contig > > b) When I enable SYSMMU support for the IP's, I am receiving below fault: > > Unhandled fault: external abort on non-linefetch (0x818) at 0xb6f55000 > > I think this has something to do with the access to the SYSMMU registers for > writing the page table. Has anyone of you faced this issue while testing > these(dma_map+iommu) patches on kernel mentioned above? This must be > something related to recent changes, as I didn't have issues with these > patches on 3.2 kernel. > 0xb6f55000 is not an address of SYSMMU register if your kernel starts at 0xc000. Can you tell me any detailed information or situation? Regards, KyongHo. -- 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
[PATCH][RESEND] ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
From: Maurus Cuelenaere When selecting SAMSUNG_PM_DEBUG, it complains about a missing printascii() function if you do not select DEBUG_LL, so make the former select the latter. Signed-off-by: Maurus Cuelenaere Acked-by: Heiko Stuebner --- This was originally sent in september 2010, but seems to have been forgotten. As this problem has bitten me today, here it is again. arch/arm/plat-samsung/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 6a2abe6..ec84c1a 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -302,6 +302,7 @@ comment "Power management" config SAMSUNG_PM_DEBUG bool "S3C2410 PM Suspend debug" depends on PM + select DEBUG_LL help Say Y here if you want verbose debugging from the PM Suspend and Resume code. See -- 1.7.2.3 -- 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
Re: [PATCHv7 9/9] ARM: dma-mapping: add support for IOMMU mapper
Sorry for digging this very late. But as part of integrating dma_map v7
& sysmmu v12 on 3.3-rc5, I am facing below issue:
a) By un-selecting IOMMU in menu config, I am able to allocate memory in
vb2-dma-contig
b) When I enable SYSMMU support for the IP's, I am receiving below fault:
Unhandled fault: external abort on non-linefetch (0x818) at 0xb6f55000
I think this has something to do with the access to the SYSMMU registers
for writing the page table. Has anyone of you faced this issue while
testing these(dma_map+iommu) patches on kernel mentioned above? This
must be something related to recent changes, as I didn't have issues
with these patches on 3.2 kernel.
Regards,
Subash
On 03/02/2012 01:35 PM, KyongHo Cho wrote:
On Thu, Mar 1, 2012 at 12:04 AM, Marek Szyprowski
wrote:
+/**
+ * arm_iommu_map_sg - map a set of SG buffers for streaming mode DMA
+ * @dev: valid struct device pointer
+ * @sg: list of buffers
+ * @nents: number of buffers to map
+ * @dir: DMA transfer direction
+ *
+ * Map a set of buffers described by scatterlist in streaming mode for DMA.
+ * The scatter gather list elements are merged together (if possible) and
+ * tagged with the appropriate dma address and length. They are obtained via
+ * sg_dma_{address,length}.
+ */
+int arm_iommu_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ struct scatterlist *s = sg, *dma = sg, *start = sg;
+ int i, count = 0;
+ unsigned int offset = s->offset;
+ unsigned int size = s->offset + s->length;
+ unsigned int max = dma_get_max_seg_size(dev);
+
+ for (i = 1; i< nents; i++) {
+ s->dma_address = ARM_DMA_ERROR;
+ s->dma_length = 0;
+
+ s = sg_next(s);
+
+ if (s->offset || (size& ~PAGE_MASK) || size + s->length> max)
{
+ if (__map_sg_chunk(dev, start, size,&dma->dma_address,
+ dir)< 0)
+ goto bad_mapping;
+
+ dma->dma_address += offset;
+ dma->dma_length = size - offset;
+
+ size = offset = s->offset;
+ start = s;
+ dma = sg_next(dma);
+ count += 1;
+ }
+ size += s->length;
+ }
+ if (__map_sg_chunk(dev, start, size,&dma->dma_address, dir)< 0)
+ goto bad_mapping;
+
+ dma->dma_address += offset;
+ dma->dma_length = size - offset;
+
+ return count+1;
+
+bad_mapping:
+ for_each_sg(sg, s, count, i)
+ __iommu_remove_mapping(dev, sg_dma_address(s), sg_dma_len(s));
+ return 0;
+}
+
This looks that the given sg list specifies the list of physical
memory chunks and
the list of IO virtual memory chunks at the same time after calling
arm_dma_map_sg().
It can happen that dma_address and dma_length of a sg entry does not
correspond to
physical memory information of the sg entry.
I think it is beneficial for handling IO virtual memory.
However, I worry about any other problems caused by a single sg entry contains
information from 2 different context.
Regards,
Cho KyongHo.
--
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
--
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
