RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov...@gmail.com] Sent: Thursday, January 23, 2014 2:38 AM To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues Link seems to be coming blank to me :) Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Ivaylo Dimitrov Sent: Thursday, January 09, 2014 1:05 PM To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- fb...@vger.kernel.org Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 09.01.2014 07:06, Hiremath, Vaibhav wrote: Tomi, I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Thanks, Vaibhav AFAIK underflow interrupts could come from badly calculated DSS core clock or bad HW resizer setup and should be unrelated to the memory allocation. It might be something similar to the problem I have on N900 - see https://lkml.org/lkml/2014/1/6/173 I can see the difference when I really omapfb_vram command line argument. Without omapfb_vram in bootargs --- bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y I do not get UNDERFLOW during boot. With omapfb_vram in the bootargs - bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M@0xA000 omapfb.debug=y omapdss.debug=y I always get UNDERFLOW during boot itself. Is it possible to upload the video you have problems with, so me to test it on N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case you're not aware), no matter the resolution of the videos I played(up to 720p), however I didn't test the part that allocates the memory on a pre-defined address. Though I don't think that should matter. No, that's what is causing issue to me. Can you try predefined address flow? Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace. Boot LOG: [1.443021] OMAPFB: omapfb_probe [1.446137] OMAPFB: create 3 framebuffers [1.446178] OMAPFB: fb_infos allocated [1.446198] OMAPFB: allocating 1536000 bytes for fb 0 [1.451044] OMAPFB: allocated VRAM paddr a000, vaddr ca00 [1.451069] OMAPFB: region0 phys a000 virt ca00 size=1536000 [1.451086] OMAPFB: region1 phys virt (null) size=0 [1.451100] OMAPFB: region2 phys virt (null) size=0 [1.451109] OMAPFB: fbmems allocated [1.451363] OMAPFB: check_fb_var 0 [1.451386] OMAPFB: max frame size 1536000, line size 3200 [1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480 [1.451414] OMAPFB: set_fb_fix [1.460278] OMAPFB: fb_infos initialized [1.465325] OMAPFB: set_par(0) [1.465384] OMAPFB: set_fb_fix [1.465393] OMAPFB: apply_changes, fb 0, ovl 0 [1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [1.465450] OMAPFB: paddr a000 [1.465592] OMAPFB: pan_display(0) [1.465600] OMAPFB: setcmap [1.465607] OMAPFB: setcmap [1.474504] Console: switching to colour frame buffer device 100x30 [1.474528] OMAPFB: pan_display(0) [1.474534] OMAPFB: setcmap [1.482185] OMAPFB: setcmap [1.484808] OMAPFB: framebuffers registered [1.484839] OMAPFB: apply_changes, fb 0, ovl 0 [1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [1.484870] OMAPFB: paddr a000 [1.484919] OMAPFB: apply_changes, fb 1, ovl 1 [1.485010] OMAPFB: apply_changes, fb 2, ovl 2 [1.485111] OMAPFB: create_framebuffers done [1.485128] OMAPFB: mgr-apply'ed [1.489793] OMAPFB: create sysfs for fbs [1.489816] OMAPFB: create sysfs for fbs [4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000) [5.276615] OMAPFB: pan_display(0) [5.276625] OMAPFB: setcmap [5.276635] OMAPFB: setcmap [5.293518] OMAPFB: user mmap region start a000, len 1536000, off 0 [5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay ... [ 20.499076] OMAPFB: pan_display(0) [ 20.499085] OMAPFB: setcmap [ 20.499093] OMAPFB: setcmap [ 20.544419] OMAPFB: check_var(0) [ 20.544631] OMAPFB: check_fb_var 0 [ 20.544644] OMAPFB: max frame size 1536000, line size 3200 [ 20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480 [ 20.544699] OMAPFB: set_par(0) [ 20.544706] OMAPFB: set_fb_fix [ 20.544712] OMAPFB: apply_changes, fb 0, ovl 0 [ 20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [ 20.544767] OMAPFB: paddr a000 [ 20.544798] OMAPFB: pan_display(0) [ 20.544802] OMAPFB: setcmap [ 20.544859] OMAPFB: pan_display(0) [ 20.544865] OMAPFB: setcmap [ 20.544872
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Valkeinen, Tomi Sent: Thursday, January 09, 2014 1:52 PM To: Hiremath, Vaibhav; Ivaylo Dimitrov Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 2014-01-09 07:06, Hiremath, Vaibhav wrote: I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows easily in other situations also. Well, there's a small difference in the allocation. The normal dma alloc uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas allocating from the absolute address just uses the piece of memory. I couldn't find how to set write-combine for the abs memory area. Then again, that's for CPU caching, so I don't see why it would affect DSS as such (but that's still something we should measure, cpu read/write perf for normal and abs allocation). The only thought I have is that somehow the reserved memory area is missing some configuration that is done for the rest of the memory. But that's purely a guess, this is totally out of my area of expertise... Vaibhav, just to be sure, can you run both with normal dma_alloc and with the reserve, and verify that the dispc register dumps are the same? I don't see how they could be different, but just to be sure. Will check and update you shortly. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Valkeinen, Tomi Sent: Thursday, January 09, 2014 1:57 PM To: Hiremath, Vaibhav; Ivaylo Dimitrov; Ivaylo Dimitrov Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 2014-01-09 10:08, Hiremath, Vaibhav wrote: No, that's what is causing issue to me. Can you try predefined address flow? Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace. Boot LOG: [4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000) [5.276615] OMAPFB: pan_display(0) [5.276625] OMAPFB: setcmap [5.276635] OMAPFB: setcmap [5.293518] OMAPFB: user mmap region start a000, len 1536000, off 0 [5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Hmm that's interesting... So you have some tool that's ran early, which draws something on the screen? Or maybe that's X starting? It's initial demo, not sure whether you heard of MATRIX demo. I am running Matrix demo As part of init script. Ah... I think I understand now. As I mentioned, AM4x has issues already. I think the CPU/others can block DSS when accessing memory. So, if we have bad caching for the mapped framebuffer, the CPU will use more bandwidth when reading/writing to it, and that will cause DSS to underflow. Yeah, AM4x already has some issues but I am comparing normal dma_alloc and reserved Memory and I see different behavior and it could be due to bad caching for the mapped buffers. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Hiremath, Vaibhav Sent: Thursday, January 09, 2014 2:01 PM To: Valkeinen, Tomi; Ivaylo Dimitrov Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support -Original Message- From: Valkeinen, Tomi Sent: Thursday, January 09, 2014 1:52 PM To: Hiremath, Vaibhav; Ivaylo Dimitrov Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 2014-01-09 07:06, Hiremath, Vaibhav wrote: I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows easily in other situations also. Well, there's a small difference in the allocation. The normal dma alloc uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas allocating from the absolute address just uses the piece of memory. I couldn't find how to set write-combine for the abs memory area. Then again, that's for CPU caching, so I don't see why it would affect DSS as such (but that's still something we should measure, cpu read/write perf for normal and abs allocation). The only thought I have is that somehow the reserved memory area is missing some configuration that is done for the rest of the memory. But that's purely a guess, this is totally out of my area of expertise... Vaibhav, just to be sure, can you run both with normal dma_alloc and with the reserve, and verify that the dispc register dumps are the same? I don't see how they could be different, but just to be sure. Will check and update you shortly. I checked both the DSS configuration in both scenarios and they look same to me. With normal dma_alloc: === root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /proc/cmdline console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss DSS_REVISION0020 DSS_SYSCONFIG 0001 DSS_SYSSTATUS 0001 DSS_CONTROL 0018 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk - DSS - DSS_FCK (DSS_FCLK1) = 19800 - DISPC - dispc fclk source = DSS_FCK (DSS_FCLK1) fck 19800 - LCD - LCD clk source = DSS_FCK (DSS_FCLK1) lck 19800 lck div 1 pck 3300pck div 6 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq period 44780 ms irqs 1 FRAMEDONE 0 VSYNC 1 EVSYNC_EVEN 1 EVSYNC_ODD1 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 1 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP0 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc DISPC_REVISION 0030 DISPC_SYSCONFIG2011 DISPC_SYSSTATUS0001 DISPC_IRQSTATUS00ae DISPC_IRQENABLEd640 DISPC_CONTROL 00018309 DISPC_CONFIG 0204 DISPC_CAPABLE 03ff DISPC_LINE_STATUS 00b1 DISPC_LINE_NUMBER DISPC_GLOBAL_ALPHA 00ff DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_SIZE_MGR(LCD)01df031f DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_TIMING_H(LCD)00f0d11d DISPC_TIMING_V(LCD)00a0160c DISPC_POL_FREQ(LCD)3000 DISPC_DIVISORo(LCD)00010006 DISPC_SIZE_MGR(LCD)01df031f DISPC_DATA_CYCLE1(LCD
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Valkeinen, Tomi Sent: Wednesday, January 08, 2014 7:44 PM To: Tony Lindgren; Ivaylo Dimitrov Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 2014-01-08 01:59, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131230 05:21]: The omapfb driver uses dma_alloc to reserve memory for the framebuffers. However, on some use cases, even when CMA is in use, it's quite probable that omapfb fails to allocate the fb, either due to not enough free dma memory, fragmented dma memory, or CMA failing to make enough contiguous space. This patch adds a kernel cmdline parameter 'omapfb_vram' which can be used to give the size of a memory area reserved exclusively for omapfb, and optionally a physical address where the memory area is reserved. The memory area is reserved with memblock, and assigned to omapfb with dma_declare_coherent_memory. The dma_alloc function will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@atomide.com Thanks. This introduces new kernel boot parameter, and I haven't really had time to test and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd rather leave this for 3.15 as adding new parameter that we need to support forever should be thought a bit more. Tomi, I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Thanks, Vaibhav Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, January 06, 2014 6:56 PM To: Hiremath, Vaibhav Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases On Mon, Jan 06, 2014 at 05:09:04AM +, Hiremath, Vaibhav wrote: The idea behind this RFC (or rather query) is, to get feedback or comments on the use-case of using SGI for secure-to-nonsecure communication on non-SMP architecture or SMP architecture with uniprocessor. I understand that, lot of things I need to take care from SMP architecture perspective. Based on the feedback I can spend more time to make below changes more generic to handle both uniprocessor and multi-processor architectures including more validation. So it seems that your intention is to use the existing infrastructure for this by directing SGIs through the normal IRQ processing. To that idea, I say no way. You have any other alternative? I also think you need to think more about the changes you're making in your patch - several of them seem to have just been a case of s/32/0/ without any further thought whether that change is actually appropriate. Really, I'd suggest reading the GIC documentation, especially the bits about the first register being banked between each CPU. So changing the setup in the distributor initialisation is only going to hit the register on the CPU it's running on... I completely agree with you and I am willing to spend time to have more generic implementation, which will also handle banked registers. The changes were just to prove the secure-to-nonsecure communication concept which I wanted to introduce here as part of this RFC. I will quote my statement again I understand that, lot of things I need to take care from SMP architecture perspective. Based on the feedback I can spend more time to make below changes more generic to handle both uniprocessor and multi-processor architectures including more validation. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
Hi,
Currently the Software Generated Interrupts (SGI) are restricted to use only
for SMP architecture for inter-processor communication as rightly documented
in ARM GIC spec V1.
In the system with the uniprocessor (and/or multiprocessor variants)
architecture with
TRUSTZONE enabled device (like, AM43xx device), the SGI can be used for
communication between secure-to-nonsecure world.
And in order to enable SGI event from secure world to non-secure world,
GIC driver __must__ support registration of interrupt service routines for
SGI's;
which is currently restricted by GIC driver.
The usecase is something like,
On any asynchronous HW or SW events, certain secure functionality gets
triggered
and SGI will be used to notify to the public world on the completion and/or
result of operation.
Non Secure | Secure (TrustZone)
(Linux Booted | (Secure software init happed
To prompt) | and trusted code getting executed)
|
(On any secure operation Where we would
like public world communication)
|
| - Use SGI to trigger event to public
Linux code
| - And share the public info/data with
public world for further processing
=
Public code |
handles it|
In order to prototype and to make sure that it works,
I did change the GIC driver to allow registration of SGI interrupts (interrupts
0 - 16) and
tried it on AM43xx EVM and pasted the diff of the changes below.
I have also validated using SGI for secure to non-secure communication.
The idea behind this RFC (or rather query) is, to get feedback or
comments on the use-case of using SGI for secure-to-nonsecure communication
on non-SMP architecture or SMP architecture with uniprocessor.
I understand that, lot of things I need to take care from SMP architecture
perspective.
Based on the feedback I can spend more time to make below changes more generic
to handle
both uniprocessor and multi-processor architectures including more validation.
Also, please note that, this requires change in all the DT files using GIC
interrupt controller.
Any pointers and suggestions are welcome here.
Thanks,
Vaibhav
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d0e9480..135385a 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -290,7 +290,7 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
irqnr = irqstat ~0x1c00;
- if (likely(irqnr 15 irqnr 1021)) {
+ if (likely(irqnr = 0 irqnr 1021)) {
irqnr = irq_find_mapping(gic-domain, irqnr);
handle_IRQ(irqnr, regs);
continue;
@@ -324,7 +324,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct
irq_desc *desc)
goto out;
cascade_irq = irq_find_mapping(chip_data-domain, gic_irq);
- if (unlikely(gic_irq 32 || gic_irq 1020))
+ if (unlikely(gic_irq 1020))
handle_bad_irq(cascade_irq, desc);
else
generic_handle_irq(cascade_irq);
@@ -395,20 +395,20 @@ static void __init gic_dist_init(struct gic_chip_data
*gic)
cpumask = gic_get_cpumask(gic);
cpumask |= cpumask 8;
cpumask |= cpumask 16;
- for (i = 32; i gic_irqs; i += 4)
+ for (i = 0; i gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
/*
* Set priority on all global interrupts.
*/
- for (i = 32; i gic_irqs; i += 4)
+ for (i = 0; i gic_irqs; i += 4)
writel_relaxed(0xa0a0a0a0, base + GIC_DIST_PRI + i * 4 / 4);
/*
* Disable all interrupts. Leave the PPI and SGIs alone
* as these enables are banked registers.
*/
- for (i = 32; i gic_irqs; i += 32)
+ for (i = 0; i gic_irqs; i += 32)
writel_relaxed(0x, base + GIC_DIST_ENABLE_CLEAR + i * 4
/ 32);
writel_relaxed(1, base + GIC_DIST_CTRL);
@@ -672,7 +672,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned
int irq)
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- if (hw 32) {
+ if (hw 0) {
irq_set_percpu_devid(irq);
irq_set_chip_and_handler(irq, gic_chip,
handle_percpu_devid_irq);
@@ -696,8 +696,11 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
if (intsize 3)
return -EINVAL;
-/* Get the interrupt number and add 16 to skip over SGIs */
- *out_hwirq =
RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
-Original Message- From: bhupesh.sha...@freescale.com [mailto:bhupesh.sha...@freescale.com] Sent: Monday, January 06, 2014 11:02 AM To: Hiremath, Vaibhav; 'linux-arm-ker...@lists.infradead.org' Cc: 'Tony Lindgren'; 'linux-omap@vger.kernel.org'; 'Russell King' Subject: RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases -Original Message- From: linux-arm-kernel [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Hiremath, Vaibhav Sent: Monday, January 06, 2014 10:39 AM To: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren; linux-omap@vger.kernel.org; Russell King Subject: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases Hi, Currently the Software Generated Interrupts (SGI) are restricted to use only for SMP architecture for inter-processor communication as rightly documented in ARM GIC spec V1. In the system with the uniprocessor (and/or multiprocessor variants) architecture with TRUSTZONE enabled device (like, AM43xx device), the SGI can be used for communication between secure-to-nonsecure world. And in order to enable SGI event from secure world to non-secure world, GIC driver __must__ support registration of interrupt service routines for SGI's; which is currently restricted by GIC driver. I am not an expert on this, but as per my understanding the model recommended by ARM is the use of IRQ as a Normal world interrupt source, and FIQ as the Secure world source. [Hiremath, Vaibhav] Absolutely and I also follow same recommendation here. If IRQ is received by the Secure world, it should cause a hardware trap to the monitor and the monitor mode should cause a context switch and jumps to the normal world, where the interrupt handler should execute (see reference [1]). I think I missed to explicitly talk about FIQ in the RFC, sorry for the confusion. Yes, IRQ received by secure world should cause HW trap to monitor mode and Further should cause context switch to public world to handle the interrupt. And this RFC wants to leverage this, where, any operations on secure world, - Functional operation (entered through monitor mode) which want to pass on the event to public world - Any FIQ (secure interrupts) wants to pass on certain events or information to Public world - It could be any secure peripheral interrupt causing FIQ Secure world can use IRQ, which is generated by software to pass on the event information to public world. Please note that, the SGI is non-secure, so if you raise and SGI from secure world it will follow the execution mentioned above. So this RFC enables asynchronous communication channel between secure world to Non-secure world using SGI. For making a transition from the secure world to the normal world and vice- versa, the core should transition via the monitor mode. Assuming a Uniprocessor system running both Normal and Secure world - thus providing a view of two virtual processors running in a time-sliced fashion, the world in which the processor is executing should be indicated by the NS-bit in the Secure Configuration Register (SCR) in CP15. The IRQ, FIQ, Abort exceptions can all be configured to cause the processor to switch into monitor mode. The software that executes within monitor mode is implementation defined, but it generally saves the state of the current world and restores the state of the world being switched to. It then performs a return-from-exception to restart processing in the restored world. (see reference [2]). Does this RFC implementation take into account the monitor mode switch while switching/passing information b/w the two worlds? Yes, as recommended by ARM, this RFC is also based on the recommendation, where, monitor mode is responsible for saving and restoring contexts. RFC doesn't handle the monitor mode implementation which lacks context save/restore. Please let me know if you still have any confusion on the usecase and on this RFC Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, July 01, 2013 7:46 AM To: Vutla, Lokesh Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- o...@vger.kernel.org; Balbi, Felipe; linux-arm- ker...@lists.infradead.org Subject: Re: OMAP baseline test results for v3.10-rc6 On Fri, 28 Jun 2013, Paul Walmsley wrote: On Thu, 27 Jun 2013, Lokesh Vutla wrote: Here is the catch.. Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was generated in arch/arm/boot). Ugh... that's probably it :-( Indeed, this was at least one major problem. With this fixed, and with CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone white boots here now with v3.10-rc7. Will test the previous releases going back Surely it will boot. :) Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reset handling in am335x hwmod data
-Original Message- From: Balbi, Felipe Sent: Friday, June 28, 2013 4:24 PM To: Hiremath, Vaibhav Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej Siewior Subject: Re: reset handling in am335x hwmod data Hi, On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: -Original Message- From: Menon, Nishanth Sent: Monday, May 20, 2013 11:34 PM To: Hiremath, Vaibhav Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 12:47-20130520, Hiremath, Vaibhav wrote: [...] On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Yes - that is what the above does - as long as the GPIO is requested and set to the right level by the relevant driver, it is not unused and hence not reset at late_init. May be I am missing something here, Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall. Hmm.. You are right, I missed that :( I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be both seem to be different to me needs a little further elaboration? GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup. Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no driver to hold the gpio? Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset? That’s the idea. It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Forgot to mention, Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set HWMOD_INIT_NO_RESET flag For GPIO0 bank. a) if the GPIO gets moved over to some other GPIO bank on another platform, this wont work Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank. unless you mark the GPIO as taken, another driver could in- adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES). b) for platforms that dont use gpio to hold DDR power, maybe this is not even relevant and the GPIO bank can safely be reset? As I mentioned, there is no known side-effect of not resetting GPIO bank 0. It should depend on the platform
RE: OMAP baseline test results for v3.10-rc6
-Original Message- From: linux-arm-kernel [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Kevin Hilman Sent: Wednesday, June 26, 2013 1:28 AM To: Rini, Tom Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav Subject: Re: OMAP baseline test results for v3.10-rc6 Tom Rini tr...@ti.com writes: On 06/25/2013 02:20 PM, Paul Walmsley wrote: + Vaibhav and Kevin Hi, On Tue, 25 Jun 2013, Felipe Balbi wrote: On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Paul, we have at least 2 different folks who can't reproduce your bone and bone black boot to userspace failures. I wonder how you're trying to boot them. Care to share your test scripts ? Sure... the methodology is completely open and has been posted in the online logs since the first test cycle. (For some reason, almost no one clicks through the test directory trees that I post online. Is this a documentation issue? What can we do to make it easier for people to explore this?) Well, another link never hurts the search results :) [snip] Am certainly open to the idea that there's something wrong with the way that I'm booting either of these. But AFAIK no one's been able to identify exactly what it could be. I haven't had the time recently to spend hours going through the various permutations, given all the other breakage :-( BeagleBone-white has the additional complication that it is not easy to automate, due to the way that power is delivered to the board, so there is an extra dimension of difficulty there. Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, rather than pass them separately, it fails to boot. If you switch to mainline U-Boot (v2012.10 or later) you get support for separate image + dtb (v2013.04 gives you bootz and zImage support). v2013.04 will also work out of the box for BeagleBone-Black. Just to confirm, my problems with mainline were with appended DTB also. Separate DTB and zImage work fine (at least using u-boot v2013.04.) That being said, appended DTB should still work, so there's a bug hiding someplace that needs to be found fixed. Can you guys update your tests to test appended DTB also? What is missing here is, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y And for the code which is required in case of appended DTB, please refer to the code arch/arm/boot/compressed/head.S Please __NOTE__ that these options are not enabled in default omap2plus_defconfig. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.10-rc6
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, June 25, 2013 11:51 PM To: Balbi, Felipe Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Rini, Tom; Hiremath, Vaibhav; khil...@ti.com Subject: Re: OMAP baseline test results for v3.10-rc6 + Vaibhav and Kevin Hi, On Tue, 25 Jun 2013, Felipe Balbi wrote: On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt Paul, we have at least 2 different folks who can't reproduce your bone and bone black boot to userspace failures. I wonder how you're trying to boot them. Care to share your test scripts ? Sure... the methodology is completely open and has been posted in the online logs since the first test cycle. (For some reason, almost no one clicks through the test directory trees that I post online. Is this a documentation issue? What can we do to make it easier for people to explore this?) That’s not quite true, I remember going through your log in detail multiple Times. The issue is, for appended DTB you must enable 2 config options, CONFIG_ARM_APPENDED_DTB = y CONFIG_ARM_ATAG_DTB_COMPAT = y OR If you don’t want to change/modify default config (omap2plus_defconfig), Use separate DTB and zImage, which is standard way of booting kernel. Same applies to BeagleBone Black. Infact same DTB and zImage boots up fine On both boards without any issues. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] Remove unused voltagedomain data for AM33xx
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Friday, June 14, 2013 7:31 PM To: Paul Walmsley Cc: Nayak, Rajendra; Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 0/2] Remove unused voltagedomain data for AM33xx Paul Walmsley p...@pwsan.com writes: cc Kevin, Vaibhav On Thu, 13 Jun 2013, Rajendra Nayak wrote: The powerdomain framework today expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. Instead of adding dummy voltage domain data files, make the powerdomain framework aware of the fact that some SoCs' might not really have scalable voltage domains. Fine with me in principle if AM335x doesn't support voltage scaling. Vaibhav, if this is okay for you, please ack it. Then, in terms of merging, probably Kevin would be the right person for this since he's done much of the voltagedomain work. Yeah, I'll take this series after the minor issues I commented on are fixed, and Vaivhav ack's the AM33xx parts. Yeup, Feel free to add my Ack here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
-Original Message- From: Vutla, Lokesh Sent: Tuesday, June 11, 2013 9:45 AM To: Kevin Hilman Cc: Paul Walmsley; Shilimkar, Santosh; t...@atomide.com; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav; R, Sricharan; Nayak, Rajendra Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up Hi Kevin, On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote: Hi Lokesh, Lokesh Vutla lokeshvu...@ti.com writes: Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Following are the details: U-Boot: url: git://git.denx.de/u-boot.git branch : master config: am335x_evm Top commit: 842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option Kernel: url: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux- 2.6.git branch: master config: omap2plus_defocnfig dtb file: am335x-bone.dtb Top commit: 317ddd2 Linux 3.10-rc5 (On top of this I have a local patch for appending dtb) You can find the logs here: http://pastebin.com/vcBr0UhM Paul/Kevin/Santosh, AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD data got merged to Mainline. We have discussed on this in the past as well, let me explain the issue here in detail again for everybody - In case of Am335x we have only two possible options, as AM335x only boots up With DTB (Tested in BBB) - 1. Mainline u-boot + mainline Kernel: = 1.a. Appended DTB method Here you __must__ enabled below config options in order to get kernel booting, CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And, I have used below command to append DTB to kernel image # cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb zImage-append mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d zImage-append uImage-append I have attached complete log here with this mail for reference http://pastebin.com/82duFh78 1.b. Discrete DTB and uImage method: Here you don’t need to enable any extra config options. Plain omap2plus_defconfig Should work without any issues. I have attached complete log here with this mail for reference http://pastebin.com/Nqr0PiwW 2. Older U-Boot (without DTB) + Mainline Kernel: This is same as #OPTION-1.a above. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
-Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Friday, June 07, 2013 3:57 AM To: Paul Walmsley Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav; R, Sricharan Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I've also not been able to boot a mainline kernel on the BeagleBone for some time. Sorry for delayed response, as I was on vacation for almost for a week. I have just responded to this thread on complete analysis of the issue. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Wednesday, June 12, 2013 11:34 AM To: Kevin Hilman; Paul Walmsley Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; R, Sricharan Subject: RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up -Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Friday, June 07, 2013 3:57 AM To: Paul Walmsley Cc: Shilimkar, Santosh; t...@atomide.com; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav; R, Sricharan Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up Paul Walmsley p...@pwsan.com writes: On Wed, 29 May 2013, Santosh Shilimkar wrote: From: Vaibhav Hiremath hvaib...@ti.com AM33XX only supports DT boot mode and with addition of extracting module resources like, irq, dma and address space from DT block, so now we can remove duplicate information from hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I've also not been able to boot a mainline kernel on the BeagleBone for some time. Sorry for delayed response, as I was on vacation for almost for a week. I have just responded to this thread on complete analysis of the issue. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html I have also pushed the branch to github, https://github.com/hvaibhav/am335x-linux.git linus-master OR https://github.com/hvaibhav/am335x-linux/tree/linus-master NOTE: Tested on BeagleBone-Black platform. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up
-Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Thursday, June 13, 2013 4:09 AM To: Hiremath, Vaibhav Cc: Vutla, Lokesh; Paul Walmsley; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; R, Sricharan; Nayak, Rajendra Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up Hi Vaibhav, Hiremath, Vaibhav hvaib...@ti.com writes: [...] Paul/Kevin/Santosh, AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD data got merged to Mainline. We have discussed on this in the past as well, let me explain the issue here in detail again for everybody - Thanks for the detail. In my case, after more debug, it appears that where I was putting the DTB in memory from u-boot was not working. Using the addresses you used gets things working again. Thanks. u-boot mainline (v2013.04) for BeagleBone has defaults that don't work appear together: U-Boot# printenv loadaddr loadaddr=0x8020 U-Boot# printenv fdtaddr fdtaddr=0x80F8 I tried above address and it is booting up for me, below is the log for your reference - Boot LOG: = U-Boot SPL 2013.04-00274-ga71d45d (Jun 12 2013 - 10:54:45) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00274-ga71d45d (Jun 12 2013 - 10:54:45) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# mmc rescan U-Boot# fatload mmc 0 0x80F8 am335x-bone.dtb reading am335x-bone.dtb 8865 bytes read in 6 ms (1.4 MiB/s) U-Boot# fatload mmc 0 0x8020 uImage reading uImage 4044224 bytes read in 464 ms (8.3 MiB/s) U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read in 235 ms (8.2 MiB/s) U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,32MB ramdisk_size=65536 earlyprintk=serial omap_wdt.nowayout=60 U-Boot# bootm 0x8020 - 0x80F8 ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.10.0-rc5-00054-g75da4e1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4044160 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Loading Kernel Image ... OK OK Using Device Tree in place at 80f8, end 80f852a0 Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.10.0-rc5-00054-g75da4e1 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Wed Jun 12 10:51:03 IST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] cma: CMA: reserved 16 MiB at 8e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f83000 s13632 r8192 d15040 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,32MB ramdisk_size=65536 earlyprintk=serial omap_wdt.nowayout=60 [0.00] Booting kernel: `60' invalid for parameter `omap_wdt.nowayout' [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes
RE: [PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
-Original Message-
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
Sent: Tuesday, May 28, 2013 8:48 PM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hiremath, Vaibhav; Paul Walmsley
Subject: [PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..9113251 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2006,6 +2006,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = tx, .dma_req = 28, },
+ { .name = rx, .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -2016,7 +2023,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = uart_class,
.clkdm_name = l4ls_clkdm,
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = dpll_per_m2_div4_ck,
.prcm = {
.omap4 = {
Good catch.
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reset handling in am335x hwmod data
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, May 17, 2013 11:49 PM To: Peter Korsgaard Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reset handling in am335x hwmod data
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Monday, May 20, 2013 12:09 PM To: Menon, Nishanth; Peter Korsgaard Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: RE: reset handling in am335x hwmod data -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, May 17, 2013 11:49 PM To: Peter Korsgaard Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Forgot to mention, Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set HWMOD_INIT_NO_RESET flag For GPIO0 bank. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reset handling in am335x hwmod data
-Original Message- From: Menon, Nishanth Sent: Monday, May 20, 2013 8:36 PM To: Hiremath, Vaibhav Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 01:55-20130520, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Monday, May 20, 2013 12:09 PM To: Menon, Nishanth; Peter Korsgaard Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: RE: reset handling in am335x hwmod data -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, May 17, 2013 11:49 PM To: Peter Korsgaard Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Yes - that is what the above does - as long as the GPIO is requested and set to the right level by the relevant driver, it is not unused and hence not reset at late_init. May be I am missing something here, Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall. I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be both seem to be different to me needs a little further elaboration? GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup. Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no driver to hold the gpio? Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset? That’s the idea. It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Forgot to mention, Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set HWMOD_INIT_NO_RESET flag For GPIO0 bank. a) if the GPIO gets moved over to some other GPIO bank on another platform, this wont work Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank. b) for platforms that dont use gpio to hold DDR power, maybe this is not even relevant and the GPIO bank can safely be reset? As I mentioned, there is no known side-effect of not resetting GPIO bank 0. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: OMAP2+: AM33xx: Fix missing reset status data to GFX hwmod
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, May 20, 2013 8:09 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH-V2] ARM: OMAP2+: AM33xx: Fix missing reset status data to GFX hwmod On Mon, 20 May 2013, Vaibhav Hiremath wrote: GFX has a reset status register (PRM_GFX.RM_GFX_RSTST), so update the GFX hwmod data with .rstst_off and .st_shift information. Although it doesn't have impact on kernel boot, but this is regression fix from original hwmod commit. Did it ever work? If not, then it's not a regression, right? As we know none of the GFX sw is available in the mainline, so never got exercised so far; but kernel boots up fine without any issues. I was also confused a bit on this, but then thought, this could be regression As it is fixing wrong/missing data without which GFX will not work. May be I was wrong. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: reset handling in am335x hwmod data
-Original Message-
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
o...@vger.kernel.org; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data
On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]
On 20:10-20130517, Peter Korsgaard wrote:
Kevin == Kevin Hilman khil...@linaro.org writes:
In this case, we cannot reset that bank, otherwise
Starter
Kit
will
never boot in mainline. Bad PCB design, I know, but
it's
not
something
we can change now :-)
Kevin FWIW, we've seen this before (GPIO connected to
PMIC
reset
is
a
Kevin fun one), and this is why we have
omap_hwmod_no_setup_reset().
Yes, but there's no dts bindings for this, and from a quick
test
the
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas - GPIO
controls
the
voltage register supplying MPU, without any driver setting
things
up,
GPIO gets reset and obviously voltage value switches to an
voltage
where
device does not function.
Solution I am working on to solve this is [1]: snippet is
part of
a
patch that I am working on atm.
This is the right way to do it IMHO. Will allow the driver to
exist
when
HWMOD will be eventually replaced by some other framework.
[1]: http://pastebin.com/XPmAB1Zb
Both seems to be different to me. What we need is to
Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
and
set to the right level by the relevant driver, it is not unused
and
hence not reset at late_init.
May be I am missing something here,
Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(
I am a little unclear as to why this needs to have anything to do
with
the precise under-lying mechanism (hwmod or something else). May be
both seem to be different to me needs a little further
elaboration?
GPIO is connected to the DDR VTT control pin, and we have observed
that
Due to GPIO bank reset as part of hwmod init during bootup.
Is this because there is no need for an EMIF driver to handle DDR?
and
reset of the GPIO will occur as EMIF is configured at bootloader
and
there is no need to do that in kernel, correspondingly there is no
driver to hold the gpio?
Ideally, it would have been much better if drivers starts
handling
Idle, ocp reset and standby on their own (killing dependency on
hwmod
init layer).
But looking at current state,
I agree we need to use DT property here, so how about
Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod?
something like ti,hwmod-no-init-reset?
That’s the idea.
It early during hwmod init stage. We should read all DT nodes
Inside function __setup() function, that way can get rid of
HWMOD_INIT_NO_RESET flag completely. Also, this will handle
Both ocp_reset and domain reset.
Forgot to mention,
Since this is kernel boot failure issue, I think,
By the time we reach to conclusion, another approach is to
set HWMOD_INIT_NO_RESET flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on another
platform,
this wont work
Yes that’s true, but such schematic interface is not recommended.
And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-adverantly
take over the GPIO and set it to a wrong level (we had a similar story
with LED gpio between Panda Vs Panda-ES).
b) for platforms that dont use gpio to hold DDR power, maybe this
is
not
even relevant and the GPIO bank can safely be reset?
As I mentioned, there is no known side-effect of not resetting GPIO
bank 0.
It should depend on the platform.
There are other uses for hwmod-no-reset - Eg. boot logo displayed by
bootloader - if there is a reset of DSS block and re-configuration,
we'd
notice a blank-out, which is not desirable either. There could be a few
other usage based on no-reset.
In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they
attempt ther'd at least be some form of warning.
Completely agree with you on both the points, and my point and all my comments
Were more related to option 'a' above.
Thanks,
Vaibhav
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 1/2] ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, May 20, 2013 8:20 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; Cousson, Benoit; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init On Tue, 7 May 2013, Vaibhav Hiremath wrote: clkout2 comes out on the pad and is being used by various external on-board peripherals like, Audio codecs and stuff. So enable the clkout2 by default during init sequence itself. I don't like this: the clock should be enabled by the drivers for those external peripherals, not enabled by default. Neither do I. And certainly respective driver should make sure that he enables all required clocks. The gap here is, we only support DT only boot and currently clock bindings Is not coming from DT. Once we get there this needs to change. Also, note that, I do not expect impact on PM (atleast on AM335x). So I think you should reconsider the part of the patch that enables it upon init. But if you really want to do this, I'm not inclined to stand in the way; you can add my ack. Thanks for your ack, I will send out next version shortly. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, May 20, 2013 8:21 AM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com; Cousson, Benoit;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] ARM: dts: AM33XX: Set pinmux for clkout2 pad
used for clock output
Hi
something that you should fix:
On Tue, 7 May 2013, Vaibhav Hiremath wrote:
xdma_event_intr1.clkout2 pad can be used to source clock
from either 32K OSC or any of the PLL (except MPU) outputs.
On the existing AM335x based boards (EVM, EVM-SK and Bone),
this pad is used to feed the clock to audio codes.
So, this patch configures the pinmux to get clkout2 on the pad.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 +++-
arch/arm/boot/dts/am335x-evm.dts |8 +++-
arch/arm/boot/dts/am335x-evmsk.dts |8 +++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index bfba6fc..f4630a3 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = ;
+ pinctrl-0 = clkout2_pin;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -50,6 +50,12 @@
0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
|
MODE0 */
;
};
+
+ clkout2_pin: pinumx_clkout2_pin {
pinmux is misspelled here and in several other parts of this file.
Very good catch. Once misspelled and it gets copy-pasted everywhere :)
Will send next version shortly.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, May 20, 2013 8:17 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; Cousson, Benoit; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad On Fri, 17 May 2013, Hiremath, Vaibhav wrote: Tony, Paul and Benoit, Any update on this series? Most of the changes are DT-related, so it should probably go in via Benoît. I'll ack the clock side, but have a comment on patch 2, to be sent shortly. Thanks Paul for the review, I will next version shortly with your ack. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, May 17, 2013 10:55 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Paul Walmsley
Subject: Re: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info
to GFX hwmod
* Hiremath, Vaibhav hvaib...@ti.com [130517 04:13]:
-Original Message-
From: Hiremath, Vaibhav
Sent: Sunday, May 05, 2013 12:18 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org;
Hiremath,
Vaibhav; Paul Walmsley
Subject: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info
to
GFX hwmod
GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
so update the GFX hwmod data with .rstst_off and .st_shift
information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d1cf3ab..38c7b04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -329,7 +329,7 @@ static struct omap_hwmod_class
am33xx_gfx_hwmod_class = {
};
static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
- { .name = gfx, .rst_shift = 0 },
+ { .name = gfx, .rst_shift = 0, .st_shift = 0},
};
static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
@@ -347,6 +347,7 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
Tony and Paul,
Any Update on this one as well?
Is this needed for v3.10 as a fix? If so, it should describe the
regression or error.
Certainly this is fix, but no impact on kernel boot.
I will describe it more in the description and send next version shortly.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, May 17, 2013 10:40 PM To: Hiremath, Vaibhav Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Nayak, Rajendra Subject: Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock * Hiremath, Vaibhav hvaib...@ti.com [130517 03:36]: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, March 27, 2013 11:15 PM To: Tony Lindgren; Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Nayak, Rajendra Subject: Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock- domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? Looks like we missed this so far. Tony, can you merge this patch for v3.10-rc ? Oops, sorry somehow this did not make it. I'll apply it to omap-for- v3.10/fixes with cc: stable flag. Thanks Tony, I saw it in your yesterday's pull request. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
-Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Tuesday, May 14, 2013 3:23 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature Vaibhav Hiremath hvaib...@ti.com writes: Layout of DEV_FEATURE register (offset = 0x604) is different between TI81xx and AM33xx device, so create separate function which will check for features available on specific AM33xx SoC and set the flags accordingly. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Minor nit below, otherwise... Reviewed-by: Kevin Hilman khil...@linaro.org --- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/id.c | 13 + arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/soc.h |1 + 4 files changed, 20 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach- omap2/control.h index e6c3281..4acdfc5 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -358,6 +358,11 @@ #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22) +/* DEV Feature register to identify AM33XX features */ +#define AM33XX_DEV_FEATURE 0x604 +#define AM33XX_SGX_SHIFT 29 You don't need the shift value anywhere in the code, so... +#define AM33XX_SGX_MASK(1 AM33XX_SGX_SHIFT) #define AM33XX_SGX_MASK BIT(29) instead? Otherwise, rest of patch looks fine. Thanks for the review Kevin. I just sent out V2 version of the patch with your reviewed-by With changes you mentioned. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, March 27, 2013 11:15 PM To: Tony Lindgren; Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Nayak, Rajendra Subject: Re: [PATCH-V2] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Wed, 27 Mar 2013, Vaibhav Hiremath wrote: It is required to enable respective clock-domain before enabling any clock/module inside that clock-domain. During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so it will be disabled even if childs of this clock-domain is enabled, which keeps child modules in idle mode. This fixes the kernel crash observed on AM335xEVM-SK platform, where clkdiv32_ick clock is being used as a gpio debounce clock and since clkdiv32k_ick is in idle mode it leads to below crash - Crash Log: == [2.598347] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa1ac150 [2.606434] Internal error: : 1028 [#1] SMP ARM [2.611207] Modules linked in: [2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4) [2.620973] PC is at _set_gpio_debounce+0x60/0x104 [2.626025] LR is at clk_enable+0x30/0x3c Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Tony, if it isn't too late, could this one be added to your 3.9-rc fixes series? Looks like we missed this so far. Tony, can you merge this patch for v3.10-rc ? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad
-Original Message- From: Hiremath, Vaibhav Sent: Tuesday, May 07, 2013 3:10 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; Cousson, Benoit; p...@pwsan.com; linux-arm- ker...@lists.infradead.org; Hiremath, Vaibhav Subject: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad 'clkout2' comes out on the device pad and is being used by various external on-board peripherals like, Audio codecs, Wilink and stuff. So enable the clkout2 by default during init sequence itself along with right pinmux configuration clkout2 output. Also, add the missing entry of clkout2_ck to the AM33xx clock table. As far as enabling of clkout2 during init is concerned, we can argue that it can be handled using DT property and enable the clock only when specified; but not until OMAP clock-tree migration to DT. Vaibhav Hiremath (2): ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output arch/arm/boot/dts/am335x-bone.dts |8 +++- arch/arm/boot/dts/am335x-evm.dts |8 +++- arch/arm/boot/dts/am335x-evmsk.dts|8 +++- arch/arm/mach-omap2/cclock33xx_data.c |2 ++ 4 files changed, 23 insertions(+), 3 deletions(-) Tony, Paul and Benoit, Any update on this series? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
-Original Message-
From: Hiremath, Vaibhav
Sent: Sunday, May 05, 2013 12:18 AM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; linux-arm-ker...@lists.infradead.org; Hiremath,
Vaibhav; Paul Walmsley
Subject: [PATCH] ARM: OMAP2+: AM33xx: Add missing reset status info to
GFX hwmod
GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
so update the GFX hwmod data with .rstst_off and .st_shift
information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d1cf3ab..38c7b04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -329,7 +329,7 @@ static struct omap_hwmod_class
am33xx_gfx_hwmod_class = {
};
static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
- { .name = gfx, .rst_shift = 0 },
+ { .name = gfx, .rst_shift = 0, .st_shift = 0},
};
static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
@@ -347,6 +347,7 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
Tony and Paul,
Any Update on this one as well?
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
Hi, Not sure whether this got discussed and fixed already, but Google didn't give me anything :) The below commit got merged wrongly to Mainline (Changes from timer.c got missed), and due to this none of omap boards will boot. From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak rna...@ti.com Date: Thu, 21 Mar 2013 11:04:52 + Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized It seems Linux-omap tree has the fix patch for this, and it should get pushed ASAP. Below are links for Linus's mainline commit [1], the actual patch submitted to the list [2] and Commit present in Linux-omap [3]. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 [2] https://patchwork.kernel.org/patch/2300071/ [3] http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/arch/arm/mach-omap2/timer.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Monday, May 06, 2013 8:57 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
arm-ker...@lists.infradead.org
Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch -
ff931c82
* Hiremath, Vaibhav hvaib...@ti.com [130506 00:12]:
Hi,
Not sure whether this got discussed and fixed already, but Google
didn't give me anything :)
The below commit got merged wrongly to Mainline (Changes from timer.c
got missed), and
due to this none of omap boards will boot.
From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00
2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 21 Mar 2013 11:04:52 +
Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is
initialized
It seems Linux-omap tree has the fix patch for this, and it should
get pushed ASAP.
Below are links for Linus's mainline commit [1], the actual patch
submitted to the list [2] and
Commit present in Linux-omap [3].
Can you please provide a proper patch for the regression since sounds
like you already figured out what happened?
Ohh yeah, I already have a patch for it -
From: Vaibhav Hiremath hvaib...@ti.com
Date: Mon, 6 May 2013 13:23:27 +0530
Subject: [PATCH] ARM: OMAP2+: Regression: Add missing code while merging commit
ff931c82 to Mainline
While merging commit ff931c82 [1] to Mainline,, it seems not all the changes
from
the original patch [2] have been merged; changes from mach-omap2/timer.c have
been
dropped, which invokes xxx_clk_init() function required to register platform
clock table. And without this none of OMAP family of devices will boot from
Mainline.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36
[2] https://patchwork.kernel.org/patch/2300071/
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/timer.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f12aa6c..31ae764 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -549,6 +549,8 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
@@ -559,6 +561,8 @@ void __init omap##name##_gptimer_timer_init(void)
\
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource=gp_timer kernel parameter */ \
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, May 07, 2013 5:08 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux- arm-ker...@lists.infradead.org Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82 * Hiremath, Vaibhav hvaib...@ti.com [130506 11:35]: Ohh yeah, I already have a patch for it - Thanks, I'll add that into omap-for-v3.10/fixes. I modified the comments a bit trying to figure out where it changed, updated patch below. Thanks Tony. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [v3, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
-Original Message-
From: Gupta, Pekon
Sent: Thursday, May 02, 2013 2:18 PM
To: Gupta, Pekon; Cousson, Benoit; t...@atomide.com;
li...@arm.linux.org.uk
Cc: Philip, Avinash; linux-omap@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux-
ker...@vger.kernel.org; Nori, Sekhar; Hebbar, Gururaja; Hiremath,
Vaibhav; zon...@gmail.com; jac...@sunsite.dk
Subject: [v3, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to
am335x-evm
From: avinash philip avinashphi...@ti.com
NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am3355-evm with GPMC contoller timing for NAND
flash
interface, NAND partition table, ECC scheme, elm handle id.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Gupta, Pekon pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 95
1 file changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..07761fd 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,26 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7
*/
;
};
+
+ nandflash_pins_s0: nandflash_pins_s0 {
+ pinctrl-single,pins =
+ 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
PULLUP | MODE0 */
+ 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
PULLUP | MODE0 */
+ 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
PULLUP | MODE0 */
+ 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
PULLUP | MODE0 */
+ 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
PULLUP | MODE0 */
+ 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
PULLUP | MODE0 */
+ 0x18 0x30 /* gpmc_ad6.gpmc_ad6, INPUT |
PULLUP | MODE0 */
+ 0x1c 0x30 /* gpmc_ad7.gpmc_ad7, INPUT |
PULLUP | MODE0 */
+ 0x70 0x30 /* gpmc_wait0.gpmc_wait0, INPUT
|
PULLUP | MODE0 */
+ 0x74 0x37 /* gpmc_wpn.gpio0_30, INPUT |
PULLUP | MODE7 */
+ 0x7c 0x8/* gpmc_csn0.gpmc_csn0, PULL
DISA
*/
+ 0x90 0x8/* gpmc_advn_ale.gpmc_advn_ale,
PULL DISA */
+ 0x94 0x8/* gpmc_oen_ren.gpmc_oen_ren,
PULL
DISA */
+ 0x98 0x8/* gpmc_wen.gpmc_wen, PULL DISA
*/
+ 0x9c 0x8/* gpmc_be0n_cle.gpmc_be0n_cle,
PULL DISA */
+ ;
+ };
};
ocp {
@@ -102,6 +122,81 @@
reg = 0x48;
};
};
+
+ elm: elm@4808 {
+ status = okay;
+ };
+
+ gpmc: gpmc@5000 {
+ status = okay;
+ pinctrl-0 = nandflash_pins_s0;
It would be good, if you label this pin configuration with 'default' name,
as below -
pinctrl-names = default;
Thanks,
Vaibhav
+ ranges = 0 0 0x0800 0x1000; /* CS0:
NAND */
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 8;
+ ti,nand-ecc-opt = bch8;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 44;
+ gpmc,cs-wr-off = 44;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 34;
+ gpmc,adv-wr-off = 44;
+ gpmc,we-off = 40;
+ gpmc,oe-off = 54;
+ gpmc,access = 64;
+ gpmc,rd-cycle = 82;
+ gpmc,wr-cycle = 82;
+ gpmc,wr-access = 40;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+ elm_id = elm;
+
+ /* MTD partition table */
+ partition@0 {
+ label = SPL1;
+ reg = 0x 0x2;
+ };
+
+ partition@1 {
+ label = SPL2;
+ reg = 0x0002 0x0002
RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, April 10, 2013 5:02 PM To: Hiremath, Vaibhav Cc: Tony Lindgren; Paul Walmsley; linux-omap@vger.kernel.org; linux- arm-ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 On Wednesday 10 April 2013 04:45 PM, Hiremath, Vaibhav wrote: -Original Message- From: Shilimkar, Santosh Sent: Friday, April 05, 2013 10:20 PM To: Tony Lindgren Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. This seems unnecessary churn to me. DT bindings for most of the devices which you mentioned above are submitted and are at various stages of review process. ADC: GPMC: PWM: The modules are dropped as per what is going for 3.10 merge window. Above 3 modules can be retained if the DT conversion patches are under review and can go along with this patch most likely for 3.11. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. I would not recommend to get into unnecessary code churn in the future just to reduce temp Number of Lines of code. This will also kill our autogeneration concept as well. It doesn't break any concept. We just autogenrate what is *useful* rather. BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have to manually do the updates. Can you send me a pointer if you have a sript for this. With script it is much simpler to clean-up the data. I would suggest you to just alone drop base-addr, irq and dma references from hwmod entries. That we are doing anyways. Apart from that we should also clean-up data which is not used and useful. Why do you need unused data like firewall and friends ? So as I understood, you would like to keep the data for ADC, PWM and GPMC which is fine by me. We just need those DT bindings in place so that they go together. Who is following the DT patches for these ? Thanks for looking into it Vaibhav. Are you planning to send updated version of this? I would rather prefer to review next version. Please let me know if you need any help here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call _init_mpu_rt_base if no sysc
-Original Message-
From: Hunter, Jon
Sent: Thursday, April 11, 2013 7:17 AM
To: Shilimkar, Santosh
Cc: Cousson, Benoit; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; t...@atomide.com; Hiremath, Vaibhav
Subject: Re: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call
_init_mpu_rt_base if no sysc
On 03/19/2013 08:30 AM, Santosh Shilimkar wrote:
OMAP hwmod layer does the reset of the IPs in early code so that
we have SOC in sane state. To do the soft-reset, it needs to
ioremap()
the ip address space to be able to write to sysconfig registers.
But there are few hwmod which doesn't have sysconfig registers and
hence
no need to ioremap() them in early init code.
So this patch makes prevet calling the _init_mpu_rt_base()
conditional
based on sysc availability.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index 4501038..1a1f0a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2449,7 +2449,8 @@ static int __init _init(struct omap_hwmod *oh,
void *data)
if (oh-_state != _HWMOD_STATE_REGISTERED)
return 0;
- _init_mpu_rt_base(oh, NULL);
+ if (oh-class-sysc)
+ _init_mpu_rt_base(oh, NULL);
r = _init_clocks(oh, NULL);
if (IS_ERR_VALUE(r)) {
I have not looked into why, but this commit is triggering the following
panic on am335x-evm. I don't see this on the omap platforms only
am335x.
Adding Vaibhav ...
I think I have already fixed this, can you try applying below patches
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87524.html
Thanks,
Vaibhav
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, April 08, 2013 11:00 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; khil...@linaro.org; p...@pwsan.com;
Nayak, Rajendra; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
for debugSS module control
Hi,
* hvaib...@ti.com hvaib...@ti.com [130304 03:40]:
From: Vaibhav Hiremath hvaib...@ti.com
Currently there is no clean mechanism to control debugSS module and
you have to always keep clocks enabled, either,
- By enabling it during boot as part of clk_init function.
Or
- By having HWMOD_INIT_NO_IDLE flag in hwmod data.
Based on the discussion,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg81771.html
This patch introduces new kernel parameter omap_debugss_en,
which will allow user to control debugSS module enable/disable
part during boot-time.
I suggest you just make this part into a standard DT only
device driver. That way the command line parsing and clock
enabling can happen the normal way.
That’s good idea, as we are moving towards DT only boot support.
Also, are you suggesting to have both command-line param and DT
Property for this?
Is there any reason why this could not be a loadable module?
Because we want to keep it enabled before late_initcall. As part of
late_initcall
Clock/hwmod framework will start disabling unused modules, which will impact the
Debugs as well. Consider the case where this debugss is loaded as a module, the
user
Will loose the JTAG connection until the module is loaded; and once module is
Loaded, he has to again re-connect to the debugss.
With only DT option the code will look like below, is this what you also have
in your mind -
arch/arm/boot/dts/am33xx.dtsi:
debugss: debugss@4b00 {
compatible = ti,debugss;
ti,hwmods = debugss;
reg = 0x4b00 100;
status = disabled;/* User need to enable it if he need
JTAG connectivity*/
};
arch/arm/mach-omap2/debugss.c:
static int __init _omap2_debugss_enable(void)
{
struct device_node *np;
np = of_find_matching_node(oh_name);
if (!node || ! of_device_is_available()) {
pr_err(debugss device is not found\n);
return -ENODEV;
}
...
hwmod lookup./setup/enable along with optional clock enable.
...
}
device_initcall(_omap2_debugss_enable);
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, April 08, 2013 11:01 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; khil...@linaro.org; p...@pwsan.com; Nayak, Rajendra; linux-arm-ker...@lists.infradead.org Subject: Re: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control * Hiremath, Vaibhav hvaib...@ti.com [130314 04:33]: From: Hiremath, Vaibhav This patch introduces new kernel parameter omap_debugss_en, which will allow user to control debugSS module enable/disable part during boot-time. In case of OMAP3, the debugSS is part of EMU domain and is currently controlled by clock tree alone. In case of OMAP4, the debugSS is part of EMU domain and is currently controlled by clock tree, as MODULEMODE_SWCTRL is not defined for hwmod. In case of AM335x, the debugSS is in wakeup domain and is currently controlled through hwmod alone. Currently we keep it always enabled. Any comments or input on this patch series? No comments on adding the clocks, but the enabling of them should be just a regular device driver. Thanks for review, on this patch I will add your Reviewed-by line on next version Of the patch-series. I have just responded my comment to the other mail on this, and based on Your response we can conclude. Thanks, Vaibhav . -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, April 05, 2013 10:41 PM To: Shilimkar, Santosh Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak, Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath, Vaibhav Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10 * Santosh Shilimkar santosh.shilim...@ti.com [130405 09:52]: On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote: On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]: [..] Can't we already trim the am33xx hwmod data after your patches for v3.10 as am33xx is already DT only? Unfortunately we cannot create negative diffstat in other ways for v3.10 merge window as we cannot make omap4 DT only just quite yet. Yes we can and I can take a stab it tomorrow. The only thing is I might need some support for testing but thats manageable. Will take a stab at it tomorrow and if everything goes well, post a patch for smae. Patch for the AM33XX to trim is end of the email. Thanks to Sricharan and Pekon for patch and testing. Looping both Vaibhav's if they have any objection on the patch. Regards, Santosh From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. Great, that's a nice reduction :) Considering am33xx is DT only, it should be safe.. But can the am33xx guys please test and ack it? I am reviewing the patch-diff and will give my comment as soon as possible. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, April 09, 2013 10:05 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; khil...@linaro.org; p...@pwsan.com;
Nayak, Rajendra; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
for debugSS module control
* Hiremath, Vaibhav hvaib...@ti.com [130409 01:12]:
From: Tony Lindgren [mailto:t...@atomide.com]
I suggest you just make this part into a standard DT only
device driver. That way the command line parsing and clock
enabling can happen the normal way.
That’s good idea, as we are moving towards DT only boot support.
Also, are you suggesting to have both command-line param and DT
Property for this?
Is there any reason why this could not be a loadable module?
Because we want to keep it enabled before late_initcall. As part of
late_initcall
Clock/hwmod framework will start disabling unused modules, which will
impact the
Debugs as well. Consider the case where this debugss is loaded as a
module, the user
Will loose the JTAG connection until the module is loaded; and once
module is
Loaded, he has to again re-connect to the debugss.
It will get run before late_initcall if compiled in. Sounds
like there are no issues also make it work as a loadable module
as needed.
Agreed on making it as a module.
But do you think we should allow it as a loadable module (M) as well,
as user will loose Connectivity to JTAG during boot.
Another perspective here would be, user can insert the module and
Get JTAG connectivity, which also seems ok to me.
Can you also confirm on having command line argument? I think
We can only live with DT based approach, right?
Thanks,
Vaibhav
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Query regarding clk framework - from .set_rate api
Hi Rajendra/Paul/Mike,
I am debugging the issue reported by Michal on AM33xx clock tree
In the context of LCDC driver functionality-
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg36102.html
Where, the clk_set_rate() seems to be not working, and that's true
with the current implementation of OMAP/AM33xx clock tree,
as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes.
Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks
And which doesn't allow you to specify the flags.
Below is the propagation scenario under discussion:
DISP_DPLL (dpll_disp_ck) -
dpll_disp_m2_ck -
lcd_clk_mux_sel -
lcd_gclk
Just to make sure that propagation works fine, I hacked the code and
tested it on AM335x BeagleBone platform without any issues.
Can I create a patch modifying DEFINE_STRUCT_CLK() macro to take
Another argument '.flags and change all clock-trees accrordingly??
Diff Starts here:
=
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 7baede1..51fc78b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include linux/clk-private.h
#include linux/io.h
#include linux/of_irq.h
#include linux/of_platform.h
@@ -100,6 +101,7 @@ exit:
static void __init omap_generic_init(void)
{
struct device_node *np;
+ struct clk *clk;
omap_sdrc_init(NULL, NULL);
@@ -115,6 +117,15 @@ static void __init omap_generic_init(void)
if (of_machine_is_compatible(ti,omap5))
omap_sata_init();
+
+ clk = clk_get(NULL, lcd_gclk);
+ if (IS_ERR(clk))
+ printk(Can not get lcd_gclk clock\n);
+
+ printk(%s:%d gclk_rate - %lu\n, __func__, __LINE__,
clk_get_rate(clk));
+ clk_set_rate(clk, 3);
+ printk(%s:%d clk_rate - %lu\n, __func__, __LINE__, clk_get_rate(clk));
+ clk_put(clk);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index e674e01..d4552db 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -284,7 +284,7 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents,
dpll_ddr_ck_ops);
* TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
* and ALT_CLK1/2)
*/
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, dpll_disp_ck, dpll_disp_ck,
CLK_SET_RATE_PARENT,
AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 836311f..3830e5b 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -64,6 +64,7 @@ struct clockdomain;
.parent_names = _parent_array_name, \
.num_parents = ARRAY_SIZE(_parent_array_name), \
.ops = _clkops_name, \
+ .flags = CLK_SET_RATE_PARENT, \
};
#define DEFINE_STRUCT_CLK_HW_OMAP(_name, _clkdm_name) \
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query regarding clk framework - from .set_rate api
-Original Message- From: Nayak, Rajendra Sent: Monday, April 01, 2013 4:14 PM To: Hiremath, Vaibhav Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: Re: Query regarding clk framework - from .set_rate api Where, the clk_set_rate() seems to be not working, and that's true with the current implementation of OMAP/AM33xx clock tree, as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes. Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks And which doesn't allow you to specify the flags. Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree. Its not there in my kernel baseline v3.8.5, that’s why I missed it. It got merged into v3.9-rc. I am testing it now, and will update shortly. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Query regarding clk framework - from .set_rate api
-Original Message- From: Hiremath, Vaibhav Sent: Monday, April 01, 2013 4:37 PM To: Nayak, Rajendra Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: RE: Query regarding clk framework - from .set_rate api -Original Message- From: Nayak, Rajendra Sent: Monday, April 01, 2013 4:14 PM To: Hiremath, Vaibhav Cc: mturque...@linaro.org; Paul Walmsley; Tony Lindgren; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com Subject: Re: Query regarding clk framework - from .set_rate api Where, the clk_set_rate() seems to be not working, and that's true with the current implementation of OMAP/AM33xx clock tree, as the CLK_SET_RATE_PARENT flag is not set to any of the clock nodes. Please note that I am using DEFINE_STRUCT_CLK() macro for defining clocks And which doesn't allow you to specify the flags. Use DEFINE_STRUCT_CLK_FLAGS() then. Its already used in AM33xx clock tree. Its not there in my kernel baseline v3.8.5, that’s why I missed it. It got merged into v3.9-rc. I am testing it now, and will update shortly. And it works fine... Sorry for the noise, I should have checked mainline status before drafting this email. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support
-Original Message- From: Cousson, Benoit Sent: Thursday, March 28, 2013 5:57 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree-disc...@lists.ozlabs.org; Porter, Matt; jac...@sunsite.dk Subject: Re: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support Hi Vaibhav, The series looks good to me, but unfortunately does not apply cleanly on top of the latest for_3.10/dts branch. Could you rebase it? Benoit, You can simply skip below two patches, [PATCH 1/6] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM [PATCH 3/6] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM You have already merged Anil Kumar's patch into your branch. commit 9115b7c03565b5797714b2e819f6a79f040d8782 Author: AnilKumar Ch anilku...@ti.com Date: Wed Nov 21 17:22:17 2012 +0530 ARM: dts: AM33XX: Rename I2C and GPIO nodes NOTE: I have build and boot tested by skipping above 2 patches. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, March 26, 2013 11:43 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Mon, 25 Mar 2013, Vaibhav Hiremath wrote: During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. Looks fine to me. You're planning to update the patch description, right? So should I wait until you repost it? Yeup, will submit today. Also you should probably trim the crash log after [2.626025] LR is at clk_enable+0x30/0x3c Ok, Thanks, Vaibhav - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Wednesday, March 27, 2013 7:03 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Cousson, Benoit; devicetree-disc...@lists.ozlabs.org
Subject: Re: [PATCH 5/5] ARM: dts: AM33XX: Add default pinctrl binding
for UART0 device
On Wed, Mar 27, 2013 at 12:59:16PM +, Vaibhav Hiremath wrote:
Add pin control binding for UART0 device nodes in all
board specific DT files.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Except for trivial comments below I'll add my
Acked-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/am335x-evm.dts | 10 ++
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d623e4..3c4c66f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -43,10 +43,20 @@
0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
;
};
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
+ 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
|
MODE0 */
+ ;
+ };
};
ocp {
uart1: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+
Please change this to be uart0 so it all matches.
Yes, you are right, this also can be changed now.
I tested it with changed uart numbering and it is working.
I didn’t touch uart, as I recall earlier discussion of
Having 1-based uart numbering and also it is being documented
In DT for hwmod -
ti,hwmods : Must be uartn, n being the instance number (1-based)
I will change it and submit the next version with your acked-by.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
-Original Message- From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard Sent: Wednesday, March 27, 2013 6:52 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Cousson, Benoit; Porter, Matt; devicetree-disc...@lists.ozlabs.org Subject: Re: [PATCH 1/5] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM Vaibhav == Vaibhav Hiremath hvaib...@ti.com writes: Vaibhav With DT support, where naming convention is based on base- addr Vaibhav and not id, so we should follow TRM/Spec numbering label. Vaibhav This patch changes I2C numbering as per TRM, as I2C0, I2C1 and I2C2. Acked-by: Peter Korsgaard jac...@sunsite.dk What about the uart numbers while we're at it? Just responded to Matt on the same note, I will change it and submit the next version with your acked-by. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message-
From: Nayak, Rajendra
Sent: Monday, March 25, 2013 6:07 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux-
arm-ker...@lists.infradead.org
Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to
clkdiv32k_ick clock
On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote:
During common-clock migration, .clkdm_name field got missed
for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm
unused; so boot process will try to disable the clockdomain
even childs of this clock is enabled, which keeps child modules
in idle mode.
The patch looks fine but I feel the change log certainly needs an
update. The clkdm association with the clks is maintained for those
clks which have a hard requirement that the clkdm be force woken up
before the clk can be enabled. If thats the case for clkdiv32k_ick,
then what you are doing makes sense,
Yes, that’s correct. Just again to put more clarity on this,
AM33xx clock-tree is slightly deviated compared to OMAP3/4, where
We do not have MODULE_MODE clock nodes populated in tree, since
HWMOD is handing it. CLKDIV32K_CLK is special clock gate, where
it is being used as MODULE_MODE, but in reality it is simple
clock_gate. We had multiple discussion in the past related to this
and infact I went back to design team on this, explained about
how this inconsistency is hampering SW design and recommended to fix
this in next SoC.
More discussion can be found @
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69087.html
Coming back to your comment, I will change commit description
And also try to add above details.
Thanks,
Vaibhav
but the changelog is certainlly
confusing when it says 'boot process will try to disable the
clockdomain'
This fixes the kernel crash observed on AM335xEVM-Sk platform,
where clkdiv32_ick clock is being used as a gpio debounce clock
and since clkdiv32k_ick is in idle mode it leads to below crash -
Crash Log:
=
[2.598347] Unhandled fault: external abort on non-linefetch
(0x1028) at
0xfa1ac150
[2.606434] Internal error: : 1028 [#1] SMP ARM
[2.611207] Modules linked in:
[2.614449] CPU: 0Not tainted (3.8.4-01382-g1f449cd-dirty #4)
[2.620973] PC is at _set_gpio_debounce+0x60/0x104
[2.626025] LR is at clk_enable+0x30/0x3c
[2.630249] pc : [c02e2850]lr : [c0449ad8]psr:
6193
[2.630249] sp : cf053df8 ip : 0001 fp : cf19e000
[2.642308] r10: cdc56800 r9 : cf19e010 r8 : cf0b8410
[2.647802] r7 : 0002 r6 : 0004 r5 : 00a0 r4 :
cf0b8410
[2.654668] r3 : fa1ac150 r2 : fa1ac000 r1 : r0 :
[2.661540] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[2.669324] Control: 10c5387d Table: 80004019 DAC: 0017
[2.675372] Process swapper/0 (pid: 1, stack limit = 0xcf052240)
[2.681688] Stack: (0xcf053df8 to 0xcf054000)
[2.686279] 3de0: cf0b846c 2113
[2.694892] 3e00: 1388 c02e2924 0002 cf0b848c
2113 1388 c02e0258
[2.703508] 3e20: cdc57ce8 cdca2784 c00028d8 cdc56800
c040ba10 cdc57c50 c08374e0
[2.712115] 3e40: 0001 0028 cdca2784 cdca2740 cdc57c00
cdc56800 c040bc58
[2.720727] 3e60: cf1a0bd0 cf19e010 c08374e0 c0d96ffc c08374e0
cf19e010 c08374e0
[2.729341] 3e80: c076c7b0 c07421c4 c0331c90 c0331c78
c033092c cf19e010 c08374e0
[2.737957] 3ea0: cf19e044 c0330bd8
cf19e010 c08374e0 c0330c84
[2.746573] 3ec0: c08374e0 c0330bf0 c032f2f8 cf0222a8
cf198a10 c08374e0 c08265c8
[2.755185] 3ee0: cdbca7c0 c033015c c067d1e0 c08374e0 c08374e0
c0844600 cf052000
[2.763793] 3f00: c03311b8 c0776fb0 c0844600
cf052000
[2.772393] 3f20: c07421c4 c0008818 0001dd4e 0007
c076c7b0 07753841
[2.780998] 3f40: 9a64d806 9a64d806 6113
c0776fb0 0007 c0776f90
[2.789603] 3f60: c0844600 00af c0793ee8 c07421c4
c07428f8 0007 0007
[2.798217] 3f80: c07421c4 c0513f0c
[2.806827] 3fa0: c0513f14 c0013490
[2.815447] 3fc0:
[2.824058] 3fe0: 0013
eebff7f9 3a5f1b7e
[2.832668] [c02e2850] (_set_gpio_debounce+0x60/0x104) from
[c02e2924] (gpio_debounce+0x30/0x44)
[2.842272] [c02e2924] (gpio_debounce+0x30/0x44) from
[c02e0258]
(gpio_set_debounce+0xc4/0xdc)
[2.851714] [c02e0258] (gpio_set_debounce+0xc4/0xdc) from
[c040ba10] (gpio_keys_setup_key+0x190/0x268
RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
-Original Message- From: Nayak, Rajendra Sent: Tuesday, March 26, 2013 10:51 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Tuesday 26 March 2013 10:42 AM, Hiremath, Vaibhav wrote: -Original Message- From: Nayak, Rajendra Sent: Monday, March 25, 2013 6:07 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Tony Lindgren; Paul Walmsley; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote: During common-clock migration, .clkdm_name field got missed for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm unused; so boot process will try to disable the clockdomain even childs of this clock is enabled, which keeps child modules in idle mode. The patch looks fine but I feel the change log certainly needs an update. The clkdm association with the clks is maintained for those clks which have a hard requirement that the clkdm be force woken up before the clk can be enabled. If thats the case for clkdiv32k_ick, then what you are doing makes sense, Yes, that’s correct. Just again to put more clarity on this, AM33xx clock-tree is slightly deviated compared to OMAP3/4, where We do not have MODULE_MODE clock nodes populated in tree, since HWMOD is handing it. CLKDIV32K_CLK is special clock gate, where it is being used as MODULE_MODE, but in reality it is simple clock_gate. We had multiple discussion in the past related to this and infact I went back to design team on this, explained about how this inconsistency is hampering SW design and recommended to fix this in next SoC. More discussion can be found @ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69087.html Coming back to your comment, I will change commit description And also try to add above details. Great, thanks. I also had a brief look at the am335x clock data yesterday and found most clocks with clkdm associations are actually mux clocks. Do you really need those? clkdm associations make sense for gate clocks. You should be very easily able to convert these over to generic mux types if you can drop the clkdm handling part for those muxes. We need that, and for the exact same reason you pointed out in last response We need to enabled the clockdomain before enabling the module clock. With not having leaf clocks in clock-tree HWMOD data points to parent clock, Which in most of the cases ends up into clock mux. So in order to have Link between hwmod-clock-clock-domain we need that entry. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Booting 3.9.0-rc2 on Beaglebone ?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, March 20, 2013 12:04 AM To: Mark Jackson Cc: linux-omap@vger.kernel.org Subject: Re: Booting 3.9.0-rc2 on Beaglebone ? Hi, * Mark Jackson mpfj-l...@mimc.co.uk [130312 13:48]: I'm struggling to get the latest kernel git to load on my beaglebone. Error: unrecognized/unsupported machine ID (r1 = 0x0e05). I guess I'm missing some vital step ? We're changing the mainline kernel tree to use device tree based booting only. So you need to either upgrade your bootloader to support device tree based booting, or enable CONFIG_ARM_APPENDED_DTB and ARM_ATAG_DTB_COMPAT in your .config and build u-image manually with the .dtb appended to the zImage. Doing make dtbs will generate you the am335x-bone.dtb to append. This might help you - https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
-Original Message- From: Hiremath, Vaibhav Sent: Monday, March 04, 2013 5:06 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; khil...@linaro.org; p...@pwsan.com; Nayak, Rajendra; linux-arm-ker...@lists.infradead.org; Hiremath, Vaibhav Subject: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control From: Vaibhav Hiremath hvaib...@ti.com Currently there is no clean mechanism to control debugSS module and you have to always keep clocks enabled, either, - By enabling it during boot as part of clk_init function (post common-clock migration). Or - By having HWMOD_INIT_NO_IDLE flag in hwmod data (Joel submitted patch for AM335x earlier). Based on the discussion with Kevin H, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg81771.html This patch introduces new kernel parameter omap_debugss_en, which will allow user to control debugSS module enable/disable part during boot-time. In case of OMAP3, the debugSS is part of EMU domain and is currently controlled by clock tree alone. In case of OMAP4, the debugSS is part of EMU domain and is currently controlled by clock tree, as MODULEMODE_SWCTRL is not defined for hwmod. In case of AM335x, the debugSS is in wakeup domain and is currently controlled through hwmod alone. Currently we keep it always enabled. Testing: - Tested on AM335x based EVM and BeagleBone platform As required, without this flag the debugSS module will be disabled during kernel boot. OMAP (2/3/4) may require some changes from clock/hwmod perspective in order to use this new parameter. I am still looking into OMAP spec and this RFC version of patch-series is to get comments or opinion from list. Vaibhav Hiremath (3): ARM: AM33XX: clock: Add debugSS clock nodes to clock tree ARM: AM33XX: hwmod: Add hwmod data for debugSS ARM: OMAP2+: Add command line parameter for debugSS module control Documentation/kernel-parameters.txt|3 + arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/cclock33xx_data.c | 47 +++-- arch/arm/mach-omap2/debugss.c | 80 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 5 files changed, 173 insertions(+), 28 deletions(-) create mode 100644 arch/arm/mach-omap2/debugss.c Kevin/Tony, Any comments or input on this patch series? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.9-rc1
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, March 12, 2013 10:10 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: OMAP baseline test results for v3.9-rc1 Here are some basic OMAP test results for Linux v3.9-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/ Test summary Build: FAIL ( 4/16): am33xx_only, omap1_defconfig, This requires some cleanup in Makefile and Kconfig handling, Either you disable SMP support for non-SMP devices like AM33xx OR Fix the Makefile to resolve the build dependencies (may not be trivial) OR Make functions __weak so that build will go through. I have created below patch, if it is ok with you then I can Submit patch for the same (build tested with am33xx_only and omap2plus_defconfig). diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 0a6b9c7..cb0d55d 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -233,9 +233,9 @@ extern void omap_do_wfi(void); /* Needed for secondary core boot */ extern void omap_secondary_startup(void); extern void omap_secondary_startup_4460(void); -extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); -extern void omap_auxcoreboot_addr(u32 cpu_addr); -extern u32 omap_read_auxcoreboot0(void); +extern u32 __weak omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); +extern void __weak omap_auxcoreboot_addr(u32 cpu_addr); +extern u32 __weak omap_read_auxcoreboot0(void); extern void omap4_cpu_die(unsigned int cpu); @@ -249,7 +249,7 @@ extern int omap4_mpuss_init(void); extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state); extern int omap4_finish_suspend(unsigned long cpu_state); extern void omap4_cpu_resume(void); -extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state); +extern int __weak omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state); extern u32 omap4_mpuss_read_prev_context_state(void); #else static inline int omap4_enter_lowpower(unsigned int cpu, diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h index b0fd16f..94f5281 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/omap-wakeupgen.h @@ -33,6 +33,6 @@ #define OMAP_TIMESTAMPCYCLEHI 0xc0c extern int __init omap_wakeupgen_init(void); -extern void __iomem *omap_get_wakeupgen_base(void); -extern int omap_secure_apis_support(void); +extern void __weak __iomem *omap_get_wakeupgen_base(void); +extern int __weak omap_secure_apis_support(void); #endif Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 9:33 PM To: Hiremath, Vaibhav Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 03:50:01PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:34 PM To: Hiremath, Vaibhav Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: -Original Message- From: Hiremath, Vaibhav Sent: Thursday, March 07, 2013 8:24 PM To: Porter, Matt Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:17 PM To: Hiremath, Vaibhav Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 7:43 PM To: Hiremath, Vaibhav Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux- omap- ow...@vger.kernel.org] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 9:47 AM To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support snip I believe you meant CONFIG_TI_EDMA right? Yes, I just enabled it and the result is still same. [root@arago /]# dmesg | grep -ir mmc [0.506844] vmmc: 1800 -- 3300 mV at 3300 mV [0.506970] vmmc: supplied by vbat [root@arago /]# [root@arago /]# [root@arago /]# dmesg | grep -ir dma [0.217063] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.236321] platform 4900.edma: alias fck already exists [0.236360] platform 4900.edma: alias fck already exists [0.236381] platform 4900.edma: alias fck already exists [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [root@arago /]# [root@arago /]# I have applied below patches from your recent post [2/2] ARM: dts: add AM33XX MMC support [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits [v4,3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_limits() [v4,2/3] dma: edma: add device_slave_sg_limits() support [v4,1/3] dmaengine: add dma_get_slave_sg_limits() [v9,9/9] ARM: dts: add AM33XX SPI DMA support [v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT binding [v9,7/9] spi: omap2-mcspi: convert to dma_request_slave_channel_compat() [v9,6/9] ARM: dts: add AM33XX EDMA support [v9,5/9] dmaengine: edma: Add TI EDMA device tree binding [v9,4/9] dmaengine: edma: enable build for AM33XX [v9,3/9] ARM: edma: add AM33XX support to the private EDMA API [v9,2/9] ARM: edma: remove unused transfer controller handlers [v9,1/9] ARM: davinci: move private EDMA API to arm/common [v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT binding [v3,1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() Am I missing anything here? Yes, you
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
Any specific reason why you did not add edma entry here as well?
Yes, I've answered this one before and I think this illustrates a need
for a comment in the .dtsi. mmc3 edma event are on the crossbar and so
the event that will be mapped is system-specific. Since Luca is still
working on DT support for WiLink, there's no way to show an example of
how this is used upstream as that's the only in-kernel user.
I have a test driver I've cited in the postings that shows how the
crossbar is configured via the board .dts. It doesn't belong in the
.dtsi, however, in this case. When WiLink DT support
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 8:17 PM
To: Hiremath, Vaibhav
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux
ARM Kernel List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, March 07, 2013 8:24 PM
To: Porter, Matt
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux
ARM Kernel List
Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
Matt
Sent: Thursday, March 07, 2013 8:17 PM
To: Hiremath, Vaibhav
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T;
Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux
ARM Kernel List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel
List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit;
Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP
List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
snip
I believe you meant CONFIG_TI_EDMA right?
Yes, I just enabled it and the result is still same.
[root@arago /]# dmesg | grep -ir mmc
[0.506844] vmmc: 1800 -- 3300 mV at 3300 mV
[0.506970] vmmc: supplied by vbat
[root@arago /]#
[root@arago /]#
[root@arago /]# dmesg | grep -ir dma
[0.217063] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[0.236321] platform 4900.edma: alias fck already exists
[0.236360] platform 4900.edma: alias fck already exists
[0.236381] platform 4900.edma: alias fck already exists
[0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine
driver
[0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[root@arago /]#
[root@arago /]#
I have applied below patches from your recent post
[2/2] ARM: dts: add AM33XX MMC support
[1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits
[v4,3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_limits()
[v4,2/3] dma: edma: add device_slave_sg_limits() support
[v4,1/3] dmaengine: add dma_get_slave_sg_limits()
[v9,9/9] ARM: dts: add AM33XX SPI DMA support
[v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT binding
[v9,7/9] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
[v9,6/9] ARM: dts: add AM33XX EDMA support
[v9,5/9] dmaengine: edma: Add TI EDMA device tree binding
[v9,4/9] dmaengine: edma: enable build for AM33XX
[v9,3/9] ARM: edma: add AM33XX support to the private EDMA API
[v9,2/9] ARM: edma: remove unused transfer controller handlers
[v9,1/9] ARM: davinci: move private EDMA API to arm/common
[v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT binding
[v3,1/2] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Am I missing anything here?
Thanks,
Vaibhav
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:31 PM To: Hiremath, Vaibhav Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:53:51PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 8:17 PM To: Hiremath, Vaibhav Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux ARM Kernel List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote: -Original Message- From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 7:43 PM To: Hiremath, Vaibhav Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Porter, Matt Sent: Thursday, March 07, 2013 9:47 AM To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony Lindgren; Russell King Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux Kernel Mailing List; Linux MMC List Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support Adds AM33XX MMC support for am335x-bone, am335x-evm, and am335x-evmsk. snip What's the full log now? At least that fragment you show me is better, you now have the correct dmaengine driver active. Here we go. Boot Log: == U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-evm.dtb reading am335x-evm.dtb 11419 bytes read in 10 ms (1.1 MiB/s) U-Boot# fatload mmc 0 8100 uImage reading uImage 4029168 bytes read in 441 ms (8.7 MiB/s) U-Boot# fatload mmc 0 8200 ramdisk.ext2.gz reading ramdisk.ext2.gz 3274441 bytes read in 363 ms (8.6 MiB/s) U-Boot# setenv bootargs mem=256M console=ttyO0,115200n8 root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial omap_debugss_en U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.9.0-rc1-00124-g68f2d92-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4029104 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Using Device Tree in place at 8000, end 80005c9a Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.9.0-rc1-00124-g68f2d92-dirty (XXX@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #5 SMP Thu Mar 7 20:19:23 IST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM [0.00] cma: CMA: reserved 16 MiB at 8e80 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f75000 s13632 r8192 d15040 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: mem=256M console=ttyO0,115200n8 root=/dev/ram rw initrdD hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 255MB = 255MB total [0.00] Memory: 212236k/212236k available, 49908k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 8:34 PM
To: Hiremath, Vaibhav
Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP List;
Linux ARM Kernel List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, March 07, 2013 8:24 PM
To: Porter, Matt
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T;
Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball;
Linux
ARM Kernel List
Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter,
Matt
Sent: Thursday, March 07, 2013 8:17 PM
To: Hiremath, Vaibhav
Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T;
Devicetree
Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball;
Linux
ARM Kernel List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath wrote:
-Original Message-
From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of
Porter,
Matt
Sent: Thursday, March 07, 2013 7:43 PM
To: Hiremath, Vaibhav
Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit;
Tony
Lindgren; Russell King; Devicetree Discuss; Linux ARM Kernel
List;
Linux OMAP List; Linux Kernel Mailing List; Linux MMC List
Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav Hiremath
wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-
omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson,
Benoit;
Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP
List;
Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
snip
I believe you meant CONFIG_TI_EDMA right?
Yes, I just enabled it and the result is still same.
[root@arago /]# dmesg | grep -ir mmc
[0.506844] vmmc: 1800 -- 3300 mV at 3300 mV
[0.506970] vmmc: supplied by vbat
[root@arago /]#
[root@arago /]#
[root@arago /]# dmesg | grep -ir dma
[0.217063] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[0.236321] platform 4900.edma: alias fck already exists
[0.236360] platform 4900.edma: alias fck already exists
[0.236381] platform 4900.edma: alias fck already exists
[0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA
engine
driver
[0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine
driver
[root@arago /]#
[root@arago /]#
I have applied below patches from your recent post
[2/2] ARM: dts: add AM33XX MMC support
[1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits
[v4,3/3] mmc: davinci: get SG segment limits with
dma_get_slave_sg_limits()
[v4,2/3] dma: edma: add device_slave_sg_limits() support
[v4,1/3] dmaengine: add dma_get_slave_sg_limits()
[v9,9/9] ARM: dts: add AM33XX SPI DMA support
[v9,8/9] spi: omap2-mcspi: add generic DMA request support to the DT
binding
[v9,7/9] spi: omap2-mcspi: convert to
dma_request_slave_channel_compat()
[v9,6/9] ARM: dts: add AM33XX EDMA support
[v9,5/9] dmaengine: edma: Add TI EDMA device tree binding
[v9,4/9] dmaengine: edma: enable build for AM33XX
[v9,3/9] ARM: edma: add AM33XX support to the private EDMA API
[v9,2/9] ARM: edma: remove unused transfer controller handlers
[v9,1/9] ARM: davinci: move private EDMA API to arm/common
[v3,2/2] mmc: omap_hsmmc: add generic DMA request support to the DT
binding
[v3,1/2] mmc: omap_hsmmc: convert to
dma_request_slave_channel_compat()
Am I missing anything here?
Yes, you missed the
http://www.spinics.net/lists/arm-kernel/msg227886.html dependency
mentioned first in the cover letter.
Matt, I manually edited the file with above patch and result is still the same.
Can you point me to branch where you have tested MMC code?
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8c3b1fa..e68ac38 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -730,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot = 0)
slot = EDMA_CHAN_SLOT(slot);
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Porter, Matt
Sent: Thursday, March 07, 2013 9:47 AM
To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, Benoit; Tony
Lindgren; Russell King
Cc: Devicetree Discuss; Linux ARM Kernel List; Linux OMAP List; Linux
Kernel Mailing List; Linux MMC List
Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index c3c781a..e029eea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -234,6 +234,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
Any specific reason why you did not add edma entry here as well?
Also, I wonder why interrupt property is not coming here, I understand
That hwmod is filling the gap here; but I would still recommend you to complete
The DT node, as we only support DT boot.
I will test the whole patch series today and update you.
Thanks,
Vaibhav
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM335x mpurate + bogomips
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Jackson Sent: Thursday, February 21, 2013 10:06 PM To: linux-omap@vger.kernel.org Subject: AM335x mpurate + bogomips Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to be supported for AM335x SoCs ? No, certainly not. mpurate bootargs was supported long time back, If you are probably using 2.6.32 based kernel from TI on top of AM37x. I've tried it on our custom board using 3v8, but no joy. The boot log shows:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj- nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) ... [0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait ... [0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) I have seen other boot logs outputs [1] from other people where they are getting nearly double that. Looking at omap2xxx_clk_arch_init(), only ompa24xx devices are supported. Am I missing something obvious (like it's not yet supported !!) ? I also seen same issue, and its there from long time now. Didn't get chance to nail down this. Does anybody know, whether Bogomips represents right value in case of OMAP?? On the other side, CPUFREQ is supported in the mainline kernel. Thanks, Vaibhav Cheers Mark J. [1] http://e2e.ti.com/support/embedded/linux/f/354/t/245316.aspx -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc6
On Thu, Feb 07, 2013 at 14:02:17, Balbi, Felipe wrote: Hi, On Wed, Feb 06, 2013 at 11:34:32PM +, Paul Walmsley wrote: Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html - http://marc.info/?l=linux-omapm=135903184512238w=2 - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83942.html After testing quite a lot and having help from other folks, the problem (for me at least) was missing fdt_high in u-boot environment. setenv fdt_high 0x fixed everything. Sorry for not following up on this for long, I have tested v3.8-rc6 (with latest u-boot)on both BeageBone platoforms and I have pasted the logs below as well for reference. Paul, I have used your MLO u-boot.img images and tried at my end, and as expected it didn't boot for me. I debugged it further and found that your u-boot doesn't enable support for FDT and that's is the reason it fails to boot. Below are my observations, BeagleBone: === U-Boot SPL 2013.01-00167-gd62ef56 (Feb 08 2013 - 12:41:55) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-00167-gd62ef56 (Feb 08 2013 - 12:41:55) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 7967 bytes read in 6 ms (1.3 MiB/s) U-Boot# fatload mmc 0 8100 uImage reading uImage 3927712 bytes read in 455 ms (8.2 MiB/s) U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read in 238 ms (8.1 MiB/s) U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,32MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.8.0-rc6 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3927648 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe3e000, end 8fe42f1e ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc6 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Feb 8 12:47:14 IST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f3a000 s12992 r8192 d15680 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,32MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 255MB = 255MB total [0.00] Memory: 212500k/212500k available, 49644k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06f0600 (7074 kB) [0.00] .init : 0xc06f1000 - 0xc07422c0 ( 325 kB) [0.00] .data : 0xc0744000 - 0xc07d59b8 ( 583 kB) [0.00].bss : 0xc07d59b8 - 0xc0d306b0 (5484 kB) [0.00]
RE: OMAP baseline test results for v3.8-rc6
On Fri, Feb 08, 2013 at 19:30:21, Peter Korsgaard wrote: Paul == Paul Walmsley p...@pwsan.com writes: Hi, Paul So what I'd like to know is why it doesn't work with = v3.8-rc1 Paul with an appended DTB: Paul http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/am335xbone_log.txt Paul The point is to try to minimize bootloader dependencies. Paul Haven't had the chance to try Felipe's suggestion yet re fdt_high. That shouldn't matter when using appended dtb. That's correct, relocating dtb should not matter for appended DTB kernel image. I am trying now with appended DTB, Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc6
On Fri, Feb 08, 2013 at 19:04:04, Paul Walmsley wrote: On Fri, 8 Feb 2013, Paul Walmsley wrote: The point is to try to minimize bootloader dependencies. Also if there are weird bootloader dependendencies that no one can track down, we should document them somewhere, maybe underneath Documentation/arm/OMAP. Paul, Unfortunately I do not have same observations here at my end, I just tried booting up appended dtb uImage with your shared u-boot and it is working got me. Below is the log - U-Boot SPL 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) Texas Instruments Revision detection unimplemented No AC power, disabling frequency switch OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# fatload mmc 0 8100 uImage-append reading uImage-append 3943783 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3943719 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc6-dirty (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #3 SMP Fri Feb 8 20:25:33 IST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0e3c000 s12992 r8192 d15680 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Memory: 127MB = 127MB total [0.00] Memory: 98948k/98948k available, 32124k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06f0600 (7074 kB) [0.00] .init : 0xc06f1000 - 0xc07422c0 ( 325 kB) [0.00] .data : 0xc0744000 - 0xc07d59b8 ( 583 kB) [0.00].bss : 0xc07d59b8 - 0xc0d306b0 (5484 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001262] Calibrating delay loop... 330.83 BogoMIPS (lpj=1290240) [
RE: [PATCH 1/7] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
On Fri, Feb 08, 2013 at 20:40:18, Paul Walmsley wrote:
Hi
On Wed, 2 Jan 2013, Philip Avinash wrote:
EQEP entry is HWMOD entry is not present in HWMOD entry.
Patch descriptions need to make sense. This one does not. I've fixed it
for you this time, but please take more care in the future.
- Paul
From: Philip Avinash avinashphi...@ti.com
Date: Wed, 2 Jan 2013 18:54:48 +0530
Subject: [PATCH] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD
entries
EQEP IP block integration data is not present in HWMOD data. Also
address ranges specified for EACP EHRPWM are not correct HWMOD
flags of ADDR_TYPE_RT are added to PWM subsystem register address
space. This patch:
1. Corrects register address mapping for ECAP EHRPWM
2. Removes HWMOD flags in PWM submodule register address space.
3. Adds EQEP HWMOD entries.
Signed-off-by: Philip Avinash avinashphi...@ti.com
[p...@pwsan.com: tweaked patch description]
Signed-off-by: Paul Walmsley p...@pwsan.com
Feel free to add my Acked-by on this.
Thanks,
Vaibhav
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 158
+---
1 file changed, 145 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 9e34d4c..4b1cc4d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -784,7 +784,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
};
/*
- * 'epwmss' class: ecap0,1,2, ehrpwm0,1,2
+ * 'epwmss' class: ehrpwm0,1,2 eqep0,1,2 ecap0,1,2
*/
static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs = 0x0,
@@ -864,6 +864,66 @@ static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
},
};
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+ { .irq = 79 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep0_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* eqep1 */
+static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
+ { .irq = 88 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep1_hwmod = {
+ .name = eqep1,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep1_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* eqep2 */
+static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
+ { .irq = 89 + OMAP_INTC_START, },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep2_hwmod = {
+ .name = eqep2,
+ .class = am33xx_epwmss_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .mpu_irqs = am33xx_eqep2_irqs,
+ .main_clk = l4ls_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* ecap0 */
static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
{ .irq = 31 + OMAP_INTC_START, },
@@ -2559,8 +2619,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm0_addr_space[] = {
},
{
.pa_start = 0x48300200,
- .pa_end = 0x48300200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48300200 + SZ_128 - 1,
},
{ }
};
@@ -2585,8 +2644,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm1_addr_space[] = {
},
{
.pa_start = 0x48302200,
- .pa_end = 0x48302200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48302200 + SZ_128 - 1,
},
{ }
};
@@ -2611,8 +2669,7 @@ static struct omap_hwmod_addr_space
am33xx_ehrpwm2_addr_space[] = {
},
{
.pa_start = 0x48304200,
- .pa_end = 0x48304200 + SZ_256 - 1,
- .flags = ADDR_TYPE_RT
+ .pa_end = 0x48304200 + SZ_128 - 1,
},
{ }
};
@@ -2629,6 +2686,81 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__ehrpwm2
= {
* Splitting the resources to handle access of PWMSS config space
* and module
RE: OMAP baseline test results for v3.8-rc6
On Fri, Feb 08, 2013 at 20:40:22, Hiremath, Vaibhav wrote: On Fri, Feb 08, 2013 at 19:04:04, Paul Walmsley wrote: On Fri, 8 Feb 2013, Paul Walmsley wrote: The point is to try to minimize bootloader dependencies. Also if there are weird bootloader dependendencies that no one can track down, we should document them somewhere, maybe underneath Documentation/arm/OMAP. Paul, Have you enabled below options in your defconfig, CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y I am sure you must have already enabled it, but still would like to clarify Here. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 23:49:47, Tony Lindgren wrote: * gre...@linuxfoundation.org gre...@linuxfoundation.org [130205 09:28]: On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: Hi Tony, Greg, On Tuesday 05 February 2013 08:54 PM, kishon wrote: Hi Tony, As discussed, I'm sending a pull request for the arch/arm part of my USB patches. These patches are necessary to get MUSB functional in both dt and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch series *depends* on some of the patches which are merged in usb-next. This patch series should go in only after USB. Or else it will break compilation. Then it probably should go through the USB tree, right? We don't want to break bisectability. Looks like this branch needs to be based on at least 01658f0f (usb: phy: add a new driver for usb part of control module) to compile. Probably needs other USB patches too to make sense. This branch has a high likelihood of conflicting with .dts files, so Kishon, I suggest you do two branches: 1. A branch for Greg based on top of the USB changes This branch should contain: ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: OMAP: USB: Add phy binding information Naturally please make sure they compile and boot on their own. Looks like this will only cause few trivial include merge conflicts with what I have queued up. You can add my Acked-by: Tony Lindgren t...@atomide.com for those. 2. A branch for Benoit based on v3.8-rc6 That branch should contain all the .dts changes as those will most likely cause nasty merge conflicts otherwise with what Benoit has queued up. Tony/Benoit, There are few AM33xx DTS patches pending from long time, how do you want to take it forward? You want me to put it into one branch and share? OR just provide the list of all patches to you? Thanks, Vaibhav Regards, Tony ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
On Thu, Jan 31, 2013 at 09:41:11, Patil, Rachna wrote:
On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
Op 24 jan. 2013, om 04:45 heeft Patil, Rachna rac...@ti.com het
volgende geschreven:
From: Patil, Rachna rac...@ti.com
Make changes to add DT support in the MFD core driver.
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes in v4:
Non-standard properties prefixed with vendor name.
drivers/mfd/ti_am335x_tscadc.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c
b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -22,6 +22,8 @@
#include linux/regmap.h
#include linux/mfd/core.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h #include
linux/input/ti_am335x_tsc.h
@@ -64,20 +66,31 @@ staticint ti_tscadc_probe(struct
platform_device *pdev)
struct resource *res;
struct clk *clk;
struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
- int tsc_wires, adc_channels = 0, total_channels;
+ int tsc_wires = 0, adc_channels = 0, total_channels;
- if (!pdata) {
+ if (!pdata !pdev-dev.of_node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
- if (pdata-adc_init)
- adc_channels = pdata-adc_init-adc_channels;
+ if (pdev-dev.platform_data) {
+ if (pdata-tsc_init)
+ tsc_wires = pdata-tsc_init-wires;
+
+ if (pdata-adc_init)
+ adc_channels = pdata-adc_init-adc_channels;
+ } else {
+ node = of_find_node_by_name(pdev-dev.of_node, tsc);
+ of_property_read_u32(node, ti,wires, tsc_wires);
+
+ node = of_find_node_by_name(pdev-dev.of_node, adc);
+ of_property_read_u32(node, ti,adc-channels, adc_channels);
+ }
Since AM335x is DT only, why is there a platform data codepath and why is
it the first branch it tries? And I guess the next question is related to
the first: why doesn't it work when used with DT? When I copy over the
nodes from the evm.dts to my board I get tsc tsc: Missing platform data
in dmesg.
This IP came up 1st on AM335x, but it is not platform dependent. The driver
can be used on other platforms where-in DT is not supported.
According to the maintainers platform data takes precedence over DT. Hence
the order.
Rachana,
I see no point adding support for platform_data when you know that none of
older platforms are going to use this driver and all future platforms _must_
follow device-tree model.
So I agree that you should remove board file dependency from the driver.
I do not see Missing platform data error msg in the latest driver. I am not
able to trace from where this got populated.
Can you share the branch which you have tested?
Thanks,
Vaibhav
What are the chances this driver will work when applied on top of 3.8-rcX?
Has it even been tested with that? Has it been tested at all?
This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
Regards,
Rachna
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Thu, Dec 13, 2012 at 12:59:49, Paul Walmsley wrote: On Thu, 13 Dec 2012, Hiremath, Vaibhav wrote: On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote: The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 If I am correct, it only includes one additional patch (merge commit), right??? commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes Does this also fix sparse warnings? Just ran a quick sparse check on mach-omap2 at 3e885c6 and d94831e with 'make -j4 C=2 arch/arm/mach-omap2', and no warnings showed up. There were some sparse issues that got fixed at an earlier point, though, so perhaps you have an older copy of the branches somehow? Ignore my earlier comment on sparse warning, it was my wrong sparse tool which was culprit here. I am working on remote server, which has sparse present inside /usr/bin, and somehow my default config using that one instead of what I was building. I fixed this by changing the PATH, and now I do not see any issues/warnings. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] da8xx: Allow use by am33xx based devices
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote: Hi Vaibhav, On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? You can choose to put machine dependency here, as this patch is already doing it. The side-effect of this would be, list may grow and you may have to edit this file everytime. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote: On Wed, 12 Dec 2012, Vaibhav Hiremath wrote: I am using your paul-linux-pwrdm_post_fpwrst_devel_a_3.9 branch, where all the patches which you have posted are present (I believe so) and I am getting following sparse warning - The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 If I am correct, it only includes one additional patch (merge commit), right??? commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes Does this also fix sparse warnings? Thanks, Vaibhav - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM335x: Beaglebone stops to boot with current git kernel
On Mon, Dec 03, 2012 at 23:49:36, Kevin Hilman wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.
IMO, this should not be handled in the data at all (neither clock nor
hwmod), and should be handled at runtime/boot-time, not compile time.
Wouldn't that become another interface/control for debug? We already have
various (standard) debug kernel parameters available.
But I see your point, compile-time option will force users to rebuild kernel
just in order to disable JTAG/Debug clock.
The solution to this is to rather to have a small bit of code that
requests the debugss clocks that are needed for JTAG debug, so the
kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT
option.
In case of command-line, something like below???
static int __init omap2_debug_clk_enable(char *str)
{
if (!str)
return 0;
if (!strcmp(str, debug))
enable debug clock
return 0;
}
early_param(debug, omap2_debug_clk_enable);
In case of DT, one thought,
It can be part of omap_generic_init() in board-generic.c file,
We can parse there for debug node and required property to enable debug
module.
Any thought? Or Other options???
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com
wrote:
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the
AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled
Still this can be handled and enabled during init.
(#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name
RE: AM335x: Beaglebone stops to boot with current git kernel
On Fri, Nov 23, 2012 at 02:26:40, Joel A Fernandes wrote:
Hi Vaibhav, Igor,
On and off due to vacation time too,..
Not sure but I missed the below patch from Vaibhav as it probably
wasn't copied to linux-omap so I got confused which patch was Igor
testing, whether it was the one in which we set ENABLE_ON_INIT or the
one in which hwmod data is changed.
I think Igor tried the latter and it works. In that case, I guess we
can drop the ENABLE_ON_INIT patch if this is a better fix. I had some
comments though...
Let try to explain why we should go with hwmod patches,
When I submitted clock tree patch, we decided to remove all leaf-nodes from
the data, but since modules like debugs were not enabled in hwmod (as done
for omap) I had explicitly keep these nodes in clock-tree to disable them
with RESET_CLOCKS flag.
Please refer to the comment in file clock33xx_data.c
567 /*
568 * Modules clock nodes
569 *
570 * The following clock leaf nodes are added for the moment because:
571 *
572 * - hwmod data is not present for these modules, either hwmod
573 *control is not required or its not populated.
574 * - Driver code is not yet migrated to use hwmod/runtime pm
575 * - Modules outside kernel access (to disable them by default)
576 *
577 * - debugss
578 * - mmu (gfx domain)
579 * - cefuse
580 * - usbotg_fck (its additional clock and not really a modulemode)
581 * - ieee5000
582 */
Ideally (and to keep consistency with existing implementation), we should
enable hwmod node and remove clock-tree node.
On Thu, Nov 22, 2012 at 10:40 AM, Igor Mazanov i.maza...@gmail.com wrote:
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
[..]
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 22:10:07, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Thu, Nov 22, 2012 at 20:17:26, Hiremath, Vaibhav wrote:
On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com
wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com
wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com
wrote:
Beaglebone boot process is broken with the current git kernel. I
use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in
the AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled
Still this can be handled and enabled during init.
(#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this
thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Fri, Nov 09, 2012 at 00:46:28, Hunter, Jon wrote:
On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
[snip]
There is no reliable way to determine which source should be used in
runtime
for boards that do not have the 32k oscillator wired.
So thinking about this some more and given that we are moving away from
board files, if a board does not provide a 32kHz clock source, then this
should be reflected in the device-tree source file for that board.
Hence, at boot time we should be able to determine if a 32kHz clock
source can be used.
Let me feed some more thoughts here :)
The way it is being detected currently is based on timer idle status bit.
I am worried that, this is the only option we have.
Why not use device-tree to indicate the presence of a 32k clock source?
This seems like a board level configuration and so device-tree seems to
be the perfect place for this IMO.
I think I agree with you, but for this to happen in clean way, its time to
start populating clock-nodes in DT, don't you think? Something like,
clocks {
rtc_clk: clk@X {
compatible = crystal-32k, per-32k, xyz;
clock-frequency = 32768;
};
...
};
Timer {
ref-clock = rtc_clk;
};
What do you think?
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Mon, Nov 12, 2012 at 12:54:59, Igor Grinberg wrote: On 11/12/12 08:38, Hiremath, Vaibhav wrote: On Sun, Nov 11, 2012 at 17:05:07, Igor Grinberg wrote: On 11/08/12 20:34, Jon Hunter wrote: On 11/08/2012 12:17 PM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used Just to clarify, there's no internal 32k oscillator used on the 3517/3505; just a divider from the HF clock. Ah yes I see that now! and so the gptimer will still have a 32k clock source. That's a good question and you might want to check with Igor on that one, the AM3517 TRM conflicts with the DM as to whether it's available to the GPTIMER or not :-( Well the external 32k and internal divided down version go through the same mux and so that seems to imply either they are both available to the gptimer or neither is. Yep, but the /800 do not get you the 32768... and that makes the timer suck. Of course this can be dealt with in the clock subsystem (I remember Paul said that he will look into that), but it will take time. Also, what about having the sys_clk instead of 32k for higher precision? Is that possible already (without my patch)? Yes, it is possible. You can choose it through bootargs. Is the kernel command line the only way for doing this? I personally dislike it, because it brings multiple maintenance problems. This must be possible at least through DT. Its standard interface, so carries all the applicable pros and cons. I am not quite sure about runtime change of clocksoyrce, its pros and cons. Thanks, Vaibhav -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Sun, Nov 11, 2012 at 17:05:07, Igor Grinberg wrote: On 11/08/12 20:34, Jon Hunter wrote: On 11/08/2012 12:17 PM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used Just to clarify, there's no internal 32k oscillator used on the 3517/3505; just a divider from the HF clock. Ah yes I see that now! and so the gptimer will still have a 32k clock source. That's a good question and you might want to check with Igor on that one, the AM3517 TRM conflicts with the DM as to whether it's available to the GPTIMER or not :-( Well the external 32k and internal divided down version go through the same mux and so that seems to imply either they are both available to the gptimer or neither is. Yep, but the /800 do not get you the 32768... and that makes the timer suck. Of course this can be dealt with in the clock subsystem (I remember Paul said that he will look into that), but it will take time. Also, what about having the sys_clk instead of 32k for higher precision? Is that possible already (without my patch)? Yes, it is possible. You can choose it through bootargs. Thanks, Vaibhav -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Fri, Nov 09, 2012 at 06:25:49, Hunter, Jon wrote: On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? By the way, according to the AM3358 data manual (paragraph above), even if there is no external 32k clock source and if you don't use the internal 32k oscillator, you can still generate a 32k clock from the PER PLL (CLK_32KHZ). So therefore, there should always be a 32k clock source available for the gptimer. Is that correct? Yes that's correct, but it is from PER domain, so duging suspend time, it will be disabled. This can not be treated as a persistent clock. At the end of the day, I am just trying to understand if any OMAP/AM device supports a h/w configuration where there is no 32k clock source available for the gptimer. I know and completely understand. We need to come up with solution which works on all platforms. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECUREti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECUREti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and
small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match, ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init
omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id,
+ const char *fck_source)
Nit, I personally prefer keeping gptimer, because gp just means
general-purpose and does not imply a timer per-se.
I've made
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 21:50:05, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [121107 23:15]: On 11/07/12 19:33, Tony Lindgren wrote: I think this should be the default for the timers as that counter does not stop during deeper idle states. Well, it is the default as you can see from the patch. The problem is that for boards that for some reason do not have the 32k wired and rely on MPU/GP timer source, the default will not work and currently there is no way for board to specify which timer source it can use. Yes. I was just wondering if we can avoid patching all the board files by doing it the other way around by introducing a new omap_gp_timer rather than renaming all the existing ones? We have discussed this in San Diego (remember?) and you actually proposed this way as a solution. Well, may be I took it a bit further than you thought, but this is because the board code cannot know which timer source should be used at runtime and the fall back described below, does not work. Yes thanks I agree we should get rid of that Kconfig option for sure. --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, OMAP2430 sdp2430 board) .handle_irq = omap2_intc_handle_irq, .init_machine = omap_2430sdp_init, .init_late = omap2430_init_late, -.timer = omap2_timer, +.timer = omap2_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board) .handle_irq = omap3_intc_handle_irq, .init_machine = omap_3430sdp_init, .init_late = omap3430_init_late, -.timer = omap3_timer, +.timer = omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END ... Can't we assume that the default timer is omap[234]_sync32k_timer to avoid renaming the timer entries in all the board files? Hmmm... How will this work with the macros defining the sys_timer structure? I would also not want to hide the exact timer used under the default name. Can't you just add a new sys_timer (or a new macro) for GP only setups? Then we just need a new timer entries for the hardware that does not have the sycn32k_timer available? Well, I tried to make it small patch just for the hardware that needs it, but I always found some corner case where, IMHO, this does not work/look good. Can you explain a bit further? I guess what I'm after is just to avoid renaming the existing timers in the board-*.c files and only rename the ones that need gp timer only. That would be AM33xx family :) Thanks, Vaibhav Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote:
On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
On 11/07/12 23:36, Jon Hunter wrote:
Hi Igor,
On 11/07/2012 08:42 AM, Igor Grinberg wrote:
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer structures and initialization functions are named by the
platform
name and the clock source in use. The decision which timer is
used is done statically from the machine_desc structure. In the
future it should come from DT.
2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
separate timer structures along with the timer init functions.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
[snip]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a4ad7a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -63,20 +63,8 @@
#define OMAP2_32K_SOURCE func_32k_ck
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
#define TIMER_PROP_SECURE ti,timer-secure
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE ti,timer-alwon
-#endif
+#define TIMER_PROP_ALWON ti,timer-alwon
Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
ti,timer-secure and ti,timer-alwon directly?
Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
was to drop this and use the property string directly to remove any
abstraction.
Well, I don't understand what do you mean by any abstraction.
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and
small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
I understand your point, but right now I don't anticipate that we will
have many options here and so I think that we should drop these.
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
- np = omap_get_timer_dt(omap_timer_match,
ti,timer-secure);
+ np = omap_get_timer_dt(omap_timer_match,
TIMER_PROP_SECURE);
if (np)
of_node_put(np);
}
@@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __omap2_sync32k_clocksource_init(void)
Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
Ok.
{
int ret;
struct device_node *np = NULL;
@@ -439,15 +426,9 @@ static int __init
omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
-static void __init omap2_gptimer_clocksource_init(int gptimer_id,
- const char *fck_source)
+static void __init omap2_gp_clocksource_init(int gptimer_id
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Thu, Nov 08, 2012 at 23:43:31, Hunter, Jon wrote: On 11/08/2012 12:06 PM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:28:53, Hunter, Jon wrote: On 11/08/2012 11:47 AM, Hiremath, Vaibhav wrote: On Thu, Nov 08, 2012 at 23:09:57, Hunter, Jon wrote: [snip] I think you are missing the point here. For OMAP devices we have two main external clock sources which are the 32kHz clock and the sys_clk (can be a range of frequencies from 12-38.4MHz for OMAP4). The point is for OMAP these clock sources are always present and AFAIK there is no h/w configuration that allows you not to have the 32kHz clock source. PRCM needs it and I think for OMAP1 the reset logic needs it (if memory serves). Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. So we are not discussing the 32k-sync-timer here. We are discussing whether there are any device configurations where a 32k clock source would not be available for the gptimer. Exactly that is the point I am trying to make here, In case of AM33xx, it is certainly possible to build the system without this 32Khz clock. Interesting point here is, this 32KHz clock is external clock coming from crystal connected to in-built RTC module. Thanks. Looking at the AM3358 data manual it states ... The OSC1 oscillator provides a 32.768-kHz reference clock to the real-time clock (RTC) and is connected to the RTC_XTALIN and RTC_XTALOUT terminals. OSC1 is disabled by default after power is applied. This clock input is optional and may not be required if the RTC is configured to receive a clock from the internal 32k RC oscillator (CLK_RC32K) or peripheral PLL (CLK_32KHZ) which receives a reference clock from the OSC0 input. So what is clear to me that an external 32k clock source is optional. However, it still appears that you will always have an internal 32k source and so regardless of the h/w configuration, a gptimer will always have an 32k clock available on the AM335x devices. Is that correct? Internal RC oscillator is not accurate at all, so not guaranteed to give accurate 32.768Hz clock. The oscillation band is from 16Khz to 64Khz. So it may not be useful as a system clocks, right? So I admit I am not familiar with the details on the AM stuff side so much. So maybe I should ask this question ... Do you support a configuration where there is no external 32k clock AND the internal oscillator and hence, RTC are not used? Why not, you could give-up on persistent time across suspend/resume and use OSC clock as a input clock to timer. And the timer code, which we have we have added fallback mechanism for this, First make sure that timer is properly set for RTC32K, if yes, then use it, and if no, then fall back to OSC clock. I would have expected that you would always want the RTC running, but if you are saying that you don't require an external 32k and the internal 32k is not accurate, then I assume that having the RTC available is not mandatory either. Yes, it is not mandatory, considering fact that, you will not have persistent time and other low-power modes. Actually it depends on board/EVM use-case, right? Thanks, Vaibhav Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: On 11/08/2012 01:59 AM, Igor Grinberg wrote: [snip] There is no reliable way to determine which source should be used in runtime for boards that do not have the 32k oscillator wired. So thinking about this some more and given that we are moving away from board files, if a board does not provide a 32kHz clock source, then this should be reflected in the device-tree source file for that board. Hence, at boot time we should be able to determine if a 32kHz clock source can be used. Let me feed some more thoughts here :) The way it is being detected currently is based on timer idle status bit. I am worried that, this is the only option we have. You can also refer to the implementation, so that it will help us to conclude on this - http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=58abec6ac010f4f8818caa4a52d16c4802e14acc Note that this is based on v3.2 kernel (+ additional patches), you should look the implementation of function omap_dm_timer_switch_src(). Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt,
which he has
already submitted to the list recently. So MMC support will
come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
The thread started with need of MMC support without EDMA.
So when I say polling, I would like to try MMC without DMA support, not to
put dependency on EDMA-DMA engine migration patches.
Thanks,
Vaibhav
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 11:39:18, Hiremath, Vaibhav wrote: On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: Pulling the tree, let me try now and update you shortly... Just tried -rc4, and it boots up fine for me. I tested it with Mainline u- boot and mainline Kernel, I have pasted log below for reference - U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) I do not suspect anything here, but still think we should use mainline u-boot version. Can you share the images with me, so that I can try them? Log=== U-Boot SPL 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3842256 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3842192 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc4 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 IST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b94 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH
RE: [PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Tue, Nov 06, 2012 at 15:39:11, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
+
+static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
+ .master = am33xx_epwmss0_hwmod,
+ .slave = am33xx_ecap0_hwmod,
+ .clk= l4ls_gclk,
+ .addr = am33xx_ecap0_addr_space,
+ .user = OCP_USER_MPU,
+};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
I think user field is not related to parent-child nodes, it defines the
initiator to interact with hwmod
Copy-pasted from arch/arm/plat-omap/include/plat/omap_hwmod.h
indicate the initiators that use this interface to interact with the
hwmod
And in this case, its MPU is the initiator to interact with this interface.
Thanks,
Vaibhav
Regards,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Why do you want to change the order? Just specify ADDR_TYPE_RT, that should be it. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/15] ARM: OMAP2+: hwmod: Update the reset API for AM33XX
On Mon, Nov 05, 2012 at 23:27:52, Bedia, Vaibhav wrote: On Mon, Nov 05, 2012 at 12:28:36, Hiremath, Vaibhav wrote: [...] - u32 mask = 1 shift; - - /* Check the current status to avoid de-asserting the line twice */ - if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0) - return -EEXIST; Any specific reason why you have removed this check? During bootup the hardreset line is asserted, so wouldn't that check lead to the function always returning without doing anything? The check is, /* Check the current status to avoid de-asserting the line twice */ if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0) return -EEXIST; The code is checking whether the line is already de-asserted (== 0), so I am not sure how this will change if hardreset line is asserted during bootup. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/15] ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX
On Mon, Nov 05, 2012 at 23:27:53, Bedia, Vaibhav wrote: On Mon, Nov 05, 2012 at 12:53:59, Hiremath, Vaibhav wrote: Can you cut-n-paste the ocmcram hwmod entry outside of #if and resubmit it again? Ok. Will do that in the next version. Another suggestion, all hwmod patches looks independent and trivial to me, so can you submit all hwmod patches separately so that it can go separately? Thanks, Vaibhav Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: Pulling the tree, let me try now and update you shortly... U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) Which U-boot are you using these days? I am using mainline denx u-boot. Thanks, Vaibhav - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Mon, Nov 05, 2012 at 22:24:28, Mark Jackson wrote: On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: On 30/10/12 14:48, Vaibhav Hiremath wrote: Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? Thanks, Vaibhav So I've now spent several days trying to fix this problem, but still no joy. Did my previous emails give any clue as to where I'm going wrong ? Thanks for any help you can provide. Sorry for delayed response, I was really got pulled into other things, now I am back. I looked at your boot-log, didn't understand how it was booting earlier for you - mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) I2C: ready DRAM: 256 MiB This is important, since u-boot relocated DTB file. WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 29 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... 4315695 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4308448 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Where is your DTB? Is it appended to Kernel image? Can you try below sequence/commands from u-boot? mmc rescan 0 fatload mmc 0 8000 am335x-bone.dtb fatload mmc 0 8100 uImage setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial sendln 'bootm 8100 - 8000' To build DTB files, use make dtbs command on your kernel home directory. Thanks, Vaibhav Starting kernel ... Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he
has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how
it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the past?
Thanks,
Vaibhav
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap2-clk: Add missing lcdc clock definition
On Wed, Oct 31, 2012 at 11:19:44, Paul Walmsley wrote:
On Wed, 31 Oct 2012, Hiremath, Vaibhav wrote:
As far as lck clock node is concerned, we had deliberately dropped all leaf-
node clocks from the clock tree, please refer to the description mentioned
in -
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101987.html
Ach, should have remembered that :-( Indeed there is an LCDC hwmod:
static struct omap_hwmod am33xx_lcdc_hwmod = {
.name = lcdc,
.class = am33xx_lcdc_hwmod_class,
.clkdm_name = lcdc_clkdm,
.mpu_irqs = am33xx_lcdc_irqs,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = lcd_gclk,
.prcm = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_PER_LCDC_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
From LCDC driver perspective, driver is using,
fb_clk = clk_get(device-dev, NULL);
This I feel needs to be corrected for valid name as per Spec (mostly I
would
vote for fck) and then every platform should make sure that it returns
valid clock-node for it.
Change in Driver would be,
fb_clk = clk_get(device-dev, fck);
Ok, thanks. Let me submit patch for this.
Thanks,
Vaibhav
Indeed.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: On 30/10/12 14:48, Vaibhav Hiremath wrote: On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote: Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 I just tested this branch (+ one fix which Matt provided [1]) on BeagleBone, and MMC is working without any issues. I have tested with rootFS on MMC card. [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Okay, so I'm now coming up against a brick wall regarding U-Boot. The Kernel boots fine (as per the tree + patch above) provided I build U-Boot using the v2011.09_AM335xPSP_04.06.00.06 branch from git://arago-project.org/git/projects/u-boot-am33x.git If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I'm going to raise this query on the U-Boot ML, but can you let me know which U-Boot image you're using ? I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? Thanks, Vaibhav Cheers Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
On Wed, Oct 31, 2012 at 20:47:27, Cousson, Benoit wrote:
Hi,
On 10/29/2012 09:21 AM, Vaibhav Hiremath wrote:
From: Mugunthan V N mugunthan...@ti.com
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Is there any bindings documentation for that device?
Yes, the base DT binding documentation is present in file
Documentation/devicetree/bindings/net/cpsw.txt
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 ++
arch/arm/boot/dts/am335x-evm.dts |8 ++
arch/arm/boot/dts/am33xx.dtsi | 50
+
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
Why are you using that kind of interface? You seem to want a reference
to a device.
Cannot you have something less hard coded like:
phy_id = davinci_mdio, 0;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..f6bea04 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,55 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
hexa data should be in lower case.
Oops. Will correct it.
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ host_port_no = 0;
+ cpdma_reg_ofs = 0x800;
+ cpdma_sram_ofs = 0xa00;
+ ale_reg_ofs = 0xd00;
+ ale_entries = 1024;
+ host_port_reg_ofs = 0x108;
+ hw_stats_reg_ofs = 0x900;
+ bd_ram_ofs = 0x2000;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
Do you have to store all these data in the DTS? Cannot it be in the driver?
Do you expect to have several instance of the same IP with different
parameters here?
I will let Mugunthan respond to this.
+ slaves = 2;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
Please align the address.
Ok.
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
Please use a standard multi-line comment instead of trying to put
everything in one line.
Oops. Will correct it.
+ interrupts = 40 41 42 43;
+ ranges;
You should add blank line here for readability.
OK.
+ cpsw_emac0: slave@0 {
Mmm, you are using some address later and here some relative number,
that does not looks very consistent.
+ slave_reg_ofs = 0x208;
Is it an offset from 4a10? Cannot you use the address for the slave
name?
Something like that: cpsw_emac0: slave@4a100208
+ sliver_reg_ofs = 0xd80;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
You should add blank line here for readability.
Ok
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.7-rc3
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote: cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
