[PATCH 4/4] usb: dwc3: Remove current_trb as it is unused
This field was introduced but never used. So, remove it. Signed-off-by: Amit Virdi --- drivers/usb/dwc3/core.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 4bb9aa696ede..0842aa80976f 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -431,7 +431,6 @@ struct dwc3_event_buffer { * @dwc: pointer to DWC controller * @saved_state: ep state saved during hibernation * @flags: endpoint flags (wedged, stalled, ...) - * @current_trb: index of current used trb * @number: endpoint number (1 - 15) * @type: set to bmAttributes & USB_ENDPOINT_XFERTYPE_MASK * @resource_index: Resource transfer index @@ -464,8 +463,6 @@ struct dwc3_ep { /* This last one is specific to EP0 */ #define DWC3_EP0_DIR_IN(1 << 31) - unsignedcurrent_trb; - u8 number; u8 type; u8 resource_index; -- 1.8.0 -- 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
[PATCH 3/4] usb: dwc3: gadget: Remove redundant check
dwc3_gadget_init_hw_endpoints calls dwc3_alloc_trb_pool only if epnum is not equal to 0 or 1. Hence, rechecking it in the called function is redundant. Signed-off-by: Amit Virdi --- drivers/usb/dwc3/gadget.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 8f65ab3a3b92..8c2e2fbe6f39 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -352,9 +352,6 @@ static int dwc3_alloc_trb_pool(struct dwc3_ep *dep) if (dep->trb_pool) return 0; - if (dep->number == 0 || dep->number == 1) - return 0; - dep->trb_pool = dma_alloc_coherent(dwc->dev, sizeof(struct dwc3_trb) * DWC3_TRB_NUM, &dep->trb_pool_dma, GFP_KERNEL); -- 1.8.0 -- 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
[PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
When SG is used, there are two loops iterating to prepare TRBs: - Outer loop over the request_list - Inner loop over the SG list The driver must stop preparing TRBs when the max TRBs have been prepared. The code was missing break to get out of the outer loop. Signed-off-by: Amit Virdi --- drivers/usb/dwc3/gadget.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 0eec2e917994..8f65ab3a3b92 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -900,6 +900,9 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool starting) if (last_one) break; } + + if (last_one) + break; } else { dma = req->request.dma; length = req->request.length; -- 1.8.0 -- 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
[PATCH 0/4] usb: dwc3: Fixes and code cleanup
The first two patches are bug fixes in TRB preparation when scatter gather is used. The next two patches are basically trivial and part of code cleanup. The patches are rebased on Balbi's testing/next branch. Amit Virdi (4): usb: dwc3: gadget: Fix TRB preparation during SG usb: dwc3: gadget: Stop TRB preparation after limit is reached usb: dwc3: gadget: Remove redundant check usb: dwc3: Remove current_trb as it is unused drivers/usb/dwc3/core.h | 3 --- drivers/usb/dwc3/gadget.c | 9 - 2 files changed, 4 insertions(+), 8 deletions(-) -- 1.8.0 -- 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
[PATCH 1/4] usb: dwc3: gadget: Fix TRB preparation during SG
When scatter gather is used, multiple TRBs are prepared from one DWC3 request. Hence, we must set the 'last' flag when the SG is last as well as the TRB is last. The current implementation uses list_is_last to check if the dwc3_request is the last request in the request_list. This doesn't work when SG is used. This is because, when it is the last request, the first TRB preparation (in dwc3_prepare_one_trb) modifies the dwc3_request list's next and prev pointers while moving the URB to req_queued. Hence, list_is_last always return false no matter what. The correct way is not to access the modified pointers of dwc3_request but to use list_empty macro instead. Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 ("usb: dwc3: gadget: fix scatter gather implementation" Signed-off-by: Amit Virdi --- drivers/usb/dwc3/gadget.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f03b136ecfce..0eec2e917994 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -882,8 +882,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool starting) if (i == (request->num_mapped_sgs - 1) || sg_is_last(s)) { - if (list_is_last(&req->list, - &dep->request_list)) + if (list_empty(&dep->request_list)) last_one = true; chain = false; } -- 1.8.0 -- 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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Roger, On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote: > Fixing up Paul's email id. > > cheers, > -roger > > On 18/12/14 17:49, Roger Quadros wrote: >> There are quite a few hwmods that don't have sysconfig register and so >> _find_mpu_rt_port(oh) will return NULL thus preventing ready state check >> on those modules after the module is enabled. >> >> This can potentially cause a bus access error if the module is accessed >> before the module is ready. >> >> Get rid of the redundant _find_mpu_rt_port() check from the >> _wait_target_ready() >> funcion for all the SoCs. The following PRCM register access that checks the >> module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. Yes, makes sense. This patch looks good to me. Tested this on AM437x-gp-evm. Tested-by: Lokesh Vutla May be good idea to warn every time if enabling of module is failed? Unrelated to this patch though. diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 4c6b7b2..db67b66 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2243,7 +2243,7 @@ static int _enable(struct omap_hwmod *oh) if (soc_ops.disable_module) soc_ops.disable_module(oh); _disable_clocks(oh); - pr_debug("omap_hwmod: %s: _wait_target_ready: %d\n", + pr_warn("omap_hwmod: %s: _wait_target_ready failed : %d\n", oh->name, r); if (oh->clkdm) Thanks and regards, Lokesh >> >> e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. >> >> [ 16.672978] [ cut here ] >> [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 >> l3_interrupt_handler+0x234/0x35c() >> [ 16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET >> L4_PER_0 (Read): Data Access in User mode during Functional access >> [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 >> videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf >> industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x >> pixcir_i2c_ts c_can dc >> [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted >> 3.14.26-02561-gf733aa036398 #180 >> [ 16.739747] Backtrace: >> [ 16.742336] [] (dump_backtrace) from [] >> (show_stack+0x18/0x1c) >> [ 16.750285] r6:0093 r5:0009 r4:eab5b8a8 r3: >> [ 16.756252] [] (show_stack) from [] >> (dump_stack+0x20/0x28) >> [ 16.763870] [] (dump_stack) from [] >> (warn_slowpath_common+0x6c/0x8c) >> [ 16.772408] [] (warn_slowpath_common) from [] >> (warn_slowpath_fmt+0x38/0x40) >> [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210 >> [ 16.788626] [] (warn_slowpath_fmt) from [] >> (l3_interrupt_handler+0x234/0x35c) >> [ 16.797968] r3:ed0cd480 r2:c0730508 >> [ 16.801747] [] (l3_interrupt_handler) from [] >> (handle_irq_event_percpu+0x54/0x1bc) >> [ 16.811533] r10:ed005600 r9:c084855b r8:002a r7: r6: >> r5:002a >> [ 16.819780] r4:ed0e6d80 >> [ 16.822453] [] (handle_irq_event_percpu) from [] >> (handle_irq_event+0x30/0x40) >> [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: >> r5:002a >> [ 16.840052] r4:ed005600 >> [ 16.842744] [] (handle_irq_event) from [] >> (handle_fasteoi_irq+0x74/0x128) >> [ 16.851702] r4:ed005600 r3: >> [ 16.855479] [] (handle_fasteoi_irq) from [] >> (generic_handle_irq+0x28/0x38) >> [ 16.864523] r4:002a r3:c0066164 >> [ 16.868294] [] (generic_handle_irq) from [] >> (handle_IRQ+0x38/0x8c) >> [ 16.876612] r4:c081c640 r3:0202 >> [ 16.880380] [] (handle_IRQ) from [] >> (gic_handle_irq+0x30/0x5c) >> [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100 >> [ 16.894303] [] (gic_handle_irq) from [] >> (__irq_svc+0x40/0x50) >> [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80) >> [ 16.907499] ba20: >> 0006 >> [ 16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 >> bf011420 eb2b6960 >> [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c >> 600f0013 >> [ 16.933317] r7:eab5ba6c r6: r5:600f0013 r4:bf07702c >> [ 16.939317] [] (c_can_plat_read_reg_aligned_to_16bit >> [c_can_platform]) from [] (c_can_get_berr_counter+0x38/0x64 >> [c_can]) >> [ 16.952696] [] (c_can_get_berr_counter [c_can]) from >> [] (can_fill_info+0x124/0x15c [can_dev]) >> [ 16.963480] r5:ec8c9740 r4:ed3d3000 >> [ 16.967253] [] (can_fill_info [can_dev]) from [] >> (rtnl_fill_ifinfo+0x58c/0x8fc) >> [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780 >> [ 16.981613] [] (rtnl_fill_ifinfo) from [] >> (rtnl_dump_ifinfo+0xf0/0x1dc) >> [ 16.990401] r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 >> r5:ed3d3000 >> [ 16.998671] r4
Re: regression: Clock changes in next-20141205 break at least omap4
On Thu, 18 Dec 2014, Mike Turquette wrote: > Quoting Paul Walmsley (2014-12-18 11:23:07) > > > Flipping over from hardware to software, in the Linux clock tree, there's > > usually not much point to modeling the VCO/DCO directly because it tends > > not to be under the direct control of the OS, and it is usually tightly > > integrated into the PLLs from a hardware point of view. But unlike most > > of the Linux clock tree nodes that are downstream from clock sources, > > which use clocks that are electrically driven by the clock source, the > > clock signal that PLLs and PLL-like clocks generate is not directly driven > > by the reference clock. > > Hi Paul, Hi Mike, > This is debatable given that the formula to determine the OMAP DPLL > output rate directly depends upon the rate of the input clock (osc, > 32Khz, hsd, bypass, etc). I'm not speaking for all PLLs, just for the > OMAP ones that I am familiar with. The frequency and phase noise characteristics of the PLL's output signal are partially a function of the reference clock. But that's only because the reference clock is used to steer the VCO. It's not because the reference clock itself appears on the PLL output. Even if the reference clock dividers and VCO loop dividers were both set to divide-by-one, the reference clock still would not appear on the PLL output - merely a simulacrum of it, originating by the VCO. The PLL's output clock is, electrically, directly driven by the VCO. Page 5 of this PDF has a nice frequency synthesis PLL block diagram with integer dividers: http://www.ti.com/lit/an/swra029/swra029.pdf To rephrase, if, in the block diagram above, one were to remove everything from the TCXO reference clock on the left to the triangle to the left of the VCO, and to replace all that with a constant voltage input to the VCO, you'd still get a clock signal out of the IP block, even though the reference clock would no longer exist. > > So why is a reference clock listed as a Linux parent clock of an OMAP PLL? > > At least for OMAP, it was sort of shoehorned in to represent a gating > > dependency. It was a way of stating that the reference clock had to be > > enabled for the PLL to generate an output clock. (The off-chip crystal > > oscillator that drives most of the PLL reference clocks could be disabled > > when all of its users were idle, to save energy.) But this type of gating > > dependency is equally true for, say, a separate functional clock that the > > clock source requires in order to operate. (OMAP PLLs didn't have a > > separate functional clock, at least not that I was aware of; but that's > > not true for some similar clock sources used in other SoCs.) > > Using your terminology above, it is possible to do what you want to do > today without any change to the clock framework. Simply make each DPLL a > device. That device calls clk_get, clk_prepare_enable on the input > reference clock. I think I did something like that with the Tegra DFLL driver last year. Except the clock provider device was the DFLL IP block itself, with its own registers, etc., and not an additional abstraction, if I recall correctly. My interest is mostly to determine whether some of that special-case code can be converted into data that the CCF core can operate on, in a consistent manner that would be useful across platforms, and in a way that several people could potentially agree on. > Coincidentally these new DPLL device are clock providers themselves and > they provide root clocks of their own which are the DPLLs and > corresponding Mx outputs. This model would treat the reference clock as > something that drives the DPLL device's logic, but not as a part of the > clock signal chain. > > I don't personally agree with the idea that the reference clock is not a > parent of the DPLL, I'd be interested to know how you would define a parent clock, if it differs from the electrical "source clock" definition that I mentioned. The Linux clock tree is a software abstraction. So one could define "parent clock" however one wishes. (That's not to say that all definitions are equally useful...) One could state, for example, that a parent clock is any clock that has some effect on the output of the child clock. That would be one definition which might be consistent with your comments. The problem with that is that it means that a clock can have multiple simultaneously-active parents, which I'd naïvely think we'd want to avoid, if we could. I also have to admit that my bias is towards definitions with some kind of relationship to the hardware, which helps avoid the "utter relativism" problem that you mention below. > but I don't oppose any change to the OMAP clock driver along those lines > so long as it is done in a sane way. It seems there is never just one > correct way to look at these things. I'd say that to the extent that one could come up with concrete definitions for
Re: regression: Clock changes in next-20141205 break at least omap4
Quoting Paul Walmsley (2014-12-18 11:23:07) > On Wed, 17 Dec 2014, Lucas Stach wrote: > > > Maybe I'm thinking about this too lightly, but I think we already have > > the right abstractions in place. > > > > The clock tree in Linux is always modeled along the flow of reference > > clocks. So typically the root of the tree is something like an > > oscillator and everything spreads out from this in a parent/child > > relation. So clearly the reference clock of a PLL is the PLLs parent. If > > the PLL is running in open-loop mode (isn't this rather direct frequency > > synthesis?) is has no parent and is the root of a tree itself. > > > > If a PLL needs a functional clock to drive some internal logic, that > > doesn't directly influence the clock synthesis from reference to > > resulting clock, that clock would be no parent to the PLL. The PLL is > > merely a consumer of this clock just like every other device in the > > system. > > I suspect we're using different terminology. > > From my point of view, a reference clock is an input clock signal that is > used by another clock generator IP block or clock measurement IP block. > The use is to measure and (optionally) discipline another oscillator. > Thus the clock generator/measurement IP block generally does not > electrically propagate the reference clock outside of the block. > (Although some of the reference clock's characteristics, like phase noise > or frequency stability, may be propagated indirectly.) Only a small > number of clock tree entities makes use of reference clocks. > > By contrast, we could use the term "source clock" in the SoC context to > mean a clock signal that directly drives a downstream IP block, in an > electrical sense. These clocks are directly propagated through dividers > and muxes. > > If you're willing to play along with this terminology, then a PLL's > "source clock" would be its internal VCO/DCO, which thus would be the root > clock of the PLL. > > Flipping over from hardware to software, in the Linux clock tree, there's > usually not much point to modeling the VCO/DCO directly because it tends > not to be under the direct control of the OS, and it is usually tightly > integrated into the PLLs from a hardware point of view. But unlike most > of the Linux clock tree nodes that are downstream from clock sources, > which use clocks that are electrically driven by the clock source, the > clock signal that PLLs and PLL-like clocks generate is not directly driven > by the reference clock. Hi Paul, This is debatable given that the formula to determine the OMAP DPLL output rate directly depends upon the rate of the input clock (osc, 32Khz, hsd, bypass, etc). I'm not speaking for all PLLs, just for the OMAP ones that I am familiar with. > > So why is a reference clock listed as a Linux parent clock of an OMAP PLL? > At least for OMAP, it was sort of shoehorned in to represent a gating > dependency. It was a way of stating that the reference clock had to be > enabled for the PLL to generate an output clock. (The off-chip crystal > oscillator that drives most of the PLL reference clocks could be disabled > when all of its users were idle, to save energy.) But this type of gating > dependency is equally true for, say, a separate functional clock that the > clock source requires in order to operate. (OMAP PLLs didn't have a > separate functional clock, at least not that I was aware of; but that's > not true for some similar clock sources used in other SoCs.) Using your terminology above, it is possible to do what you want to do today without any change to the clock framework. Simply make each DPLL a device. That device calls clk_get, clk_prepare_enable on the input reference clock. Coincidentally these new DPLL device are clock providers themselves and they provide root clocks of their own which are the DPLLs and corresponding Mx outputs. This model would treat the reference clock as something that drives the DPLL device's logic, but not as a part of the clock signal chain. I don't personally agree with the idea that the reference clock is not a parent of the DPLL, but I don't oppose any change to the OMAP clock driver along those lines so long as it is done in a sane way. It seems there is never just one correct way to look at these things. > > The clock framework wasn't re-entrant back then, and we wanted to avoid > implementing re-entrancy because we were worried that it could turn into a > mess. So we just wound up listing the reference clock as the PLL's Linux > parent clock. > > My original comment was just intended to be a reflection on what it means > to be a "parent clock" in the Linux clock tree sense. If it's intended to > represent "source clocks" as they are defined above, then PLLs and > PLL-like clocks should be root nodes, except for the few cases where it's > useful to add a node for the underlying source oscillator directly (for > example, if open-loop
Re: GPMC clock question
On 12/18/2014 06:06 PM, Tony Lindgren wrote: > * Ezequiel Garcia [141218 12:49]: >> Tony, Roger: >> >> As far as I can see, the GPMC interface clock (GPMC_FCLK) is not >> properly modeled in the devicetree. Instead, hwmod magic seems to be used. > > I guess you mean the functional clock not interface clock? > >> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c: >> struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = { >> .master = &am33xx_l3_s_hwmod, >> .slave = &am33xx_gpmc_hwmod, >> .clk= "l3s_gclk", >> .addr = am33xx_gpmc_addr_space, >> .user = OCP_USER_MPU, >> }; >> >> I'd like to know what would be the appropriate DT model for this clock. >> Perhaps, as child of CORE_M4_CLK, divided by 2: >> >> gpmc_fclk: gpmc_fclk { >> #clock-cells = <0>; >> compatible = "fixed-factor-clock"; >> clocks = <&dpll_core_m4_ck>; >> clock-mult = <1>; >> clock-div = <2>; >> }; >> >> How does it look? Also, I'm wondering if this works OK when used with >> the hwmod stuff. > > Hmm we do have clocks or aliases for l3s_gclk, so it's there as otherwise > the GPMC would not work at all :) Sure with device tree only systems we > should have the clock phandle directly available though. > Right. > Note that the hwmod code takes care of runtime PM clock gating for the > drivers. Not entirely sure how that works, but I'll take a look. > But the clock entry for am33xx_l3_s__gpmc should be coming > from .dts. Right. > Please also check out the hwmod dts related changes Felipe > posted last week, that might allow populating .clk from .dts already. > Ah, nice. I'll take a look. Thanks Tony! -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)
On Thu, Dec 18, 2014 at 2:37 PM, Nishanth Menon wrote: > script download fail does imply my farm has still issues to resolve.. > but anyways.. more or less we are back operational again since it was > broken by next-20141216 I'm not seeing any more failures in next-20141218 either. Kevin -- 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: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)
On 12/17/2014 08:01 PM, Viresh Kumar wrote: > On 17 December 2014 at 22:46, Kevin Hilman wrote: >> So this looks like a bug that has been hiding, but just exposed >> because cpufreq-cpu0 (now cpufreq-dt) was not getting built-in since >> before v3.18. >> >> On omap4-panda-es, v3.18 with multi_v7_defconfig + CPUFREQ_DT enabled, >> I see this: >> >> [2.062103] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted >> freq: 699977 KHz >> [2.070404] cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial >> frequency changed to: 70 KHz >> >> No BUG. But, in next-20141216, >> >> [2.083953] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted >> freq: 699977 KHz >> [2.091949] cpu cpu0: failed to set clock rate: -22 >> [2.097045] cpufreq: __target_index: Failed to change cpu frequency: -22 >> >> And then the BUG. >> >> So the BUG() itself isn't the problem with this regression. There's >> been a fair amount of changes in the OMAP clk driver (including some >> other regressions), so I suspect the culprit to be lying somewhere in >> the recent OMAP clock changes. > > Yeah. I agree.. > https://git.linaro.org/people/mike.turquette/linux.git/commit/6f8e853d18a98ee95832ffebfaa288d42ae28cd5 Finally makes it work. build warnings actually did give an indication of the issue at hand.. > next-20141216 > arch/arm/mach-omap2/cclock3xxx_data.c:262:2: warning: initialization from > incompatible pointer type [enabled by default] > arch/arm/mach-omap2/cclock3xxx_data.c:262:2: warning: (near initialization > for ‘dpll1_ck_ops.determine_rate’) [enabled by default] > arch/arm/mach-omap2/cclock3xxx_data.c:375:2: warning: initialization from > incompatible pointer type [enabled by default] > arch/arm/mach-omap2/cclock3xxx_data.c:375:2: warning: (near initialization > for ‘dpll4_ck_ops.determine_rate’) [enabled by default] > drivers/clk/ti/dpll.c:38:2: warning: initialization from incompatible pointer > type [enabled by default] > drivers/clk/ti/dpll.c:38:2: warning: (near initialization for > ‘dpll_m4xen_ck_ops.determine_rate’) [enabled by default] > drivers/clk/ti/dpll.c:61:2: warning: initialization from incompatible pointer > type [enabled by default] > drivers/clk/ti/dpll.c:61:2: warning: (near initialization for > ‘dpll_ck_ops.determine_rate’) [enabled by default] > drivers/clk/ti/dpll.c:72:2: warning: initialization from incompatible pointer > type [enabled by default] > drivers/clk/ti/dpll.c:72:2: warning: (near initialization for > ‘dpll_no_gate_ck_ops.determine_rate’) [enabled by default] > drivers/clk/ti/dpll.c:111:2: warning: initialization from incompatible > pointer type [enabled by default] > drivers/clk/ti/dpll.c:111:2: warning: (near initialization for > ‘omap3_dpll_ck_ops.determine_rate’) [enabled by default] > drivers/clk/ti/dpll.c:123:2: warning: initialization from incompatible > pointer type [enabled by default] > drivers/clk/ti/dpll.c:123:2: warning: (near initialization for > ‘omap3_dpll_per_ck_ops.determine_rate’) [enabled by default] As of next-20141218 things seem to have settled down a bit. next-20141218 + https://patchwork.kernel.org/patch/5484401/ Various platforms I have access to looks like the following: it is a pretty simple script, and I am still getting my remote farm to work properly when scripts are downloaded over serial port.. but anyways.. > next-20141218 > 1: am335x-evm: BOOT: PASS: err=10 warn=25, CPUFreq: > PASS, CPUIdle: N/A: http://slexy.org/raw/s2BvPhDIrP > 2: am335x-sk: BOOT: PASS: err=9 warn=26, CPUFreq: PASS, > CPUIdle: N/A: http://slexy.org/raw/s21kzAb5L3 > 3: am3517-evm: BOOT: FAIL: > http://slexy.org/raw/s202ZptHTS (script download failed + a warning has > popped up for OPP) > 4: am37x-evm: BOOT: FAIL: > http://slexy.org/raw/s20pvU2Nl2 (script download fail) > 5: am437x-sk: BOOT: PASS: crit=2 err=13 warn=57, > CPUFreq: N/A, CPUIdle: N/A: http://slexy.org/raw/s2hKPxe9YG > 6:am43xx-epos: BOOT: PASS: crit=2 err=16 warn=58, > CPUFreq: N/A, CPUIdle: N/A: http://slexy.org/raw/s2R6OoHCBj > 7: am43xx-gpevm: BOOT: PASS: crit=2 err=13 warn=57, > CPUFreq: N/A, CPUIdle: N/A: http://slexy.org/raw/s20fG9U1ZL > 8:BeagleBoard-X15(am57xx-evm): BOOT: PASS: err=20 warn=24, CPUFreq: > PASS, CPUIdle: N/A: http://slexy.org/raw/s2qzlorZWB > 9: BeagleBoard-XM: BOOT: PASS: err=9 warn=19, CPUFreq: PASS, > CPUIdle: FAIL: http://slexy.org/raw/s2OzLVwqPy > 10:beagleboard-vanilla: BOOT: PASS: err=9 warn=25, CPUFreq: PASS, > CPUIdle: FAIL: http://slexy.org/raw/
Re: GPMC clock question
* Ezequiel Garcia [141218 12:49]: > Tony, Roger: > > As far as I can see, the GPMC interface clock (GPMC_FCLK) is not > properly modeled in the devicetree. Instead, hwmod magic seems to be used. I guess you mean the functional clock not interface clock? > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c: > struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = { > .master = &am33xx_l3_s_hwmod, > .slave = &am33xx_gpmc_hwmod, > .clk= "l3s_gclk", > .addr = am33xx_gpmc_addr_space, > .user = OCP_USER_MPU, > }; > > I'd like to know what would be the appropriate DT model for this clock. > Perhaps, as child of CORE_M4_CLK, divided by 2: > > gpmc_fclk: gpmc_fclk { > #clock-cells = <0>; > compatible = "fixed-factor-clock"; > clocks = <&dpll_core_m4_ck>; > clock-mult = <1>; > clock-div = <2>; > }; > > How does it look? Also, I'm wondering if this works OK when used with > the hwmod stuff. Hmm we do have clocks or aliases for l3s_gclk, so it's there as otherwise the GPMC would not work at all :) Sure with device tree only systems we should have the clock phandle directly available though. Note that the hwmod code takes care of runtime PM clock gating for the drivers. But the clock entry for am33xx_l3_s__gpmc should be coming from .dts. Please also check out the hwmod dts related changes Felipe posted last week, that might allow populating .clk from .dts already. 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
GPMC clock question
Tony, Roger: As far as I can see, the GPMC interface clock (GPMC_FCLK) is not properly modeled in the devicetree. Instead, hwmod magic seems to be used. arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c: struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = { .master = &am33xx_l3_s_hwmod, .slave = &am33xx_gpmc_hwmod, .clk= "l3s_gclk", .addr = am33xx_gpmc_addr_space, .user = OCP_USER_MPU, }; I'd like to know what would be the appropriate DT model for this clock. Perhaps, as child of CORE_M4_CLK, divided by 2: gpmc_fclk: gpmc_fclk { #clock-cells = <0>; compatible = "fixed-factor-clock"; clocks = <&dpll_core_m4_ck>; clock-mult = <1>; clock-div = <2>; }; How does it look? Also, I'm wondering if this works OK when used with the hwmod stuff. Thanks a lot in advance! -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: bluetooth: Add hci_h4p driver
Hi! On Thu 2014-12-18 20:31:53, Pavel Machek wrote: > Hi! > > > > + h4p_simple_send_frame(info, skb); > > > + > > > + if (!wait_for_completion_interruptible_timeout(&info->init_completion, > > > +msecs_to_jiffies(1000))) > > > { > > > + printk("h4p: negotiation did not return\n"); > > > > Memory leak in the error case > > And memory leak in the normal case, too, no? Fixed. Actually, no, h4p_simple_send_frame passes skb to network stack, and it should free it as neccessary. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: bluetooth: Add hci_h4p driver
Hi! > > + h4p_simple_send_frame(info, skb); > > + > > + if (!wait_for_completion_interruptible_timeout(&info->init_completion, > > + msecs_to_jiffies(1000))) > > { > > + printk("h4p: negotiation did not return\n"); > > Memory leak in the error case And memory leak in the normal case, too, no? Fixed. > > + case H4_ACL_PKT: > > + acl_hdr = (struct hci_acl_hdr *)skb->data; > > + retval = le16_to_cpu(acl_hdr->dlen); > > Could you explain, why only this needs endianness converted? This one is 16 bit, the others I checked are 8 bit. > > +static void h4p_rx_tasklet(unsigned long data) > > +{ > > + u8 byte; > > + struct h4p_info *info = (struct h4p_info *)data; > > + > > + BT_DBG("tasklet woke up"); > > + BT_DBG("rx_tasklet woke up"); > > Isn't this a bit redundant? Fixed. > > + struct sk_buff *skb; > > + struct h4p_info *info = (struct h4p_info *)data; > > + > > + BT_DBG("tasklet woke up"); > > + BT_DBG("tx_tasklet woke up"); > > Doubled? Fixed. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: regression: Clock changes in next-20141205 break at least omap4
On Wed, 17 Dec 2014, Lucas Stach wrote: > Maybe I'm thinking about this too lightly, but I think we already have > the right abstractions in place. > > The clock tree in Linux is always modeled along the flow of reference > clocks. So typically the root of the tree is something like an > oscillator and everything spreads out from this in a parent/child > relation. So clearly the reference clock of a PLL is the PLLs parent. If > the PLL is running in open-loop mode (isn't this rather direct frequency > synthesis?) is has no parent and is the root of a tree itself. > > If a PLL needs a functional clock to drive some internal logic, that > doesn't directly influence the clock synthesis from reference to > resulting clock, that clock would be no parent to the PLL. The PLL is > merely a consumer of this clock just like every other device in the > system. I suspect we're using different terminology. >From my point of view, a reference clock is an input clock signal that is used by another clock generator IP block or clock measurement IP block. The use is to measure and (optionally) discipline another oscillator. Thus the clock generator/measurement IP block generally does not electrically propagate the reference clock outside of the block. (Although some of the reference clock's characteristics, like phase noise or frequency stability, may be propagated indirectly.) Only a small number of clock tree entities makes use of reference clocks. By contrast, we could use the term "source clock" in the SoC context to mean a clock signal that directly drives a downstream IP block, in an electrical sense. These clocks are directly propagated through dividers and muxes. If you're willing to play along with this terminology, then a PLL's "source clock" would be its internal VCO/DCO, which thus would be the root clock of the PLL. Flipping over from hardware to software, in the Linux clock tree, there's usually not much point to modeling the VCO/DCO directly because it tends not to be under the direct control of the OS, and it is usually tightly integrated into the PLLs from a hardware point of view. But unlike most of the Linux clock tree nodes that are downstream from clock sources, which use clocks that are electrically driven by the clock source, the clock signal that PLLs and PLL-like clocks generate is not directly driven by the reference clock. So why is a reference clock listed as a Linux parent clock of an OMAP PLL? At least for OMAP, it was sort of shoehorned in to represent a gating dependency. It was a way of stating that the reference clock had to be enabled for the PLL to generate an output clock. (The off-chip crystal oscillator that drives most of the PLL reference clocks could be disabled when all of its users were idle, to save energy.) But this type of gating dependency is equally true for, say, a separate functional clock that the clock source requires in order to operate. (OMAP PLLs didn't have a separate functional clock, at least not that I was aware of; but that's not true for some similar clock sources used in other SoCs.) The clock framework wasn't re-entrant back then, and we wanted to avoid implementing re-entrancy because we were worried that it could turn into a mess. So we just wound up listing the reference clock as the PLL's Linux parent clock. My original comment was just intended to be a reflection on what it means to be a "parent clock" in the Linux clock tree sense. If it's intended to represent "source clocks" as they are defined above, then PLLs and PLL-like clocks should be root nodes, except for the few cases where it's useful to add a node for the underlying source oscillator directly (for example, if open-loop mode is supported). This might be the right way forward for the time being, and I like the idea of stating that Linux parent clocks should represent electrical "source clock" relationships. That raises the question of what to do about the additional gating relationships. At the moment, the clock type code needs to be responsible for calling clk_enable() etc. on all of the reference and functional clocks that need to be ungated for the clock source to work. But it has always seemed preferable to me to represent fundamental hardware structural constraints in data. If the data structures are well-defined, then the data should be relatively easy to analyze, reason about, generate, validate, share across platforms, and operate upon iteratively; unlike custom per-clocktype code, which often isn't. - 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
[PATCH] tty: serial: 8250: omap: add ttySx console if the user didn't
This patch invokes add_preferred_console() with ttyS based on ttyO arguments if the user didn't specify it on its own. This ensures that the user will see the kernel booting on his serial console in case he forgot to update the command line. Signed-off-by: Sebastian Andrzej Siewior --- While trying to to make a proxy driver like Alan suggested I wasn't sure how to obtain the ttyS console via "official" API. Then I stumbled upon update_console_cmdline() and then add_preferred_console(). drivers/tty/serial/8250/8250_omap.c | 40 + drivers/tty/serial/8250/Kconfig | 19 ++ 2 files changed, 59 insertions(+) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index 336602eb453e..78401fbc823b 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -1248,6 +1248,46 @@ static int omap8250_runtime_resume(struct device *dev) } #endif +#ifdef CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP +static int __init omap8250_console_fixup(void) +{ + char *omap_str; + char *options; + u8 idx; + + if (strstr(boot_command_line, "console=ttyS")) + /* user set a ttyS based name for the console */ + return 0; + + omap_str = strstr(boot_command_line, "console=ttyO"); + if (!omap_str) + /* user did not set ttyO based console, so we don't care */ + return 0; + + omap_str += 12; + if ('0' <= *omap_str && *omap_str <= '9') + idx = *omap_str - '0'; + else + return 0; + + omap_str++; + if (omap_str[0] == ',') { + omap_str++; + options = omap_str; + } else { + options = NULL; + } + + add_preferred_console("ttyS", idx, options); + pr_err("WARNING: Your 'console=ttyO%d' has been replaced by 'ttyS%d'\n", + idx, idx); + pr_err("This ensures that you still see kernel messages. Please\n"); + pr_err("update your kernel commandline.\n"); + return 0; +} +console_initcall(omap8250_console_fixup); +#endif + static const struct dev_pm_ops omap8250_dev_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(omap8250_suspend, omap8250_resume) SET_RUNTIME_PM_OPS(omap8250_runtime_suspend, diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig index 0fcbcd29502f..87adf08b9b6b 100644 --- a/drivers/tty/serial/8250/Kconfig +++ b/drivers/tty/serial/8250/Kconfig @@ -308,6 +308,25 @@ config SERIAL_8250_OMAP This driver uses ttyS instead of ttyO. +config SERIAL_8250_OMAP_TTYO_FIXUP + bool "Replace ttyO with ttyS" + depends on SERIAL_8250_OMAP=y && SERIAL_8250_CONSOLE + default y + help + This option replaces the "console=ttyO" argument with the matching + ttyS argument if the user did not specified it on the command line. + This ensures that the user can see the kernel output during boot + which he wouldn't see otherwise. The getty has still to be configured + for ttyS instead of ttyO regardless of this option. + This option is intended for people who "automatically" enable this + driver without knowing that this driver requires a different console= + argument. If you read this, please keep this option disabled and + instead update your kernel command line. If you prepare a kernel for a + distribution or other kind of larger user base then you probably want + to keep this option enabled. Otherwise people might complain about a + not booting kernel because the serial console remains silent in case + they forgot to update the command line. + config SERIAL_8250_FINTEK tristate "Support for Fintek F81216A LPC to 4 UART" depends on SERIAL_8250 && PNP -- 2.1.3 -- 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 4430 SDP: rather sick with recent kernels
* Tony Lindgren [141217 09:28]: > > And then there are these too in the current mainline that are > clock related: > > omap4xxx_dt_clk_init: failed to configure ABE DPLL! > ... > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > [ cut here ] > WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30() > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699 > Hardware name: Generic OMAP4 (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x80/0x9c) > [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) > [] (warn_slowpath_common) from [] (warn_slowpath_null+ > 0x1c/0x24) > [] (warn_slowpath_null) from [] (clk_disable+0x24/0x30) > [] (clk_disable) from [] (_disable_clocks+0x18/0x68) > [] (_disable_clocks) from [] (_idle+0x15c/0x240) > [] (_idle) from [] (_setup+0x174/0x22c) > [] (_setup) from [] (omap_hwmod_for_each+0x30/0x5c) > [] (omap_hwmod_for_each) from [] > (__omap_hwmod_setup_all+0x30/0x40) > [] (__omap_hwmod_setup_all) from [] > (do_one_initcall+0x80/0x1d8) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x1f4/0x2cc) > [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) > [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) > ---[ end trace f0d1b75165d8ef11 ]--- > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > ... > > Tero & Tomi, can you please look into these clock issues above? FYI, looks like merging Mike's pending clk-next to current mainline somehow fixes the clock issues above. It seems the audio changes depended on changes in clk-next? 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
[PATCH 2/5] ARM: dts: am4372: add VPFE DT node entries
From: Benoit Parrot Add Video Processing Front End (VPFE) device tree nodes for AM34xx family of devices. Signed-off-by: Benoit Parrot Signed-off-by: Darren Etheridge Signed-off-by: Felipe Balbi Signed-off-by: Lad, Prabhakar --- arch/arm/boot/dts/am4372.dtsi | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 46660ff..dbd52fd 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -896,6 +896,22 @@ compatible = "mmio-sram"; reg = <0x4030 0x4>; /* 256k */ }; + + vpfe0: vpfe@48326000 { + compatible = "ti,am437x-vpfe"; + reg = <0x48326000 0x2000>; + interrupts = ; + ti,hwmods = "vpfe0"; + status = "disabled"; + }; + + vpfe1: vpfe@48328000 { + compatible = "ti,am437x-vpfe"; + reg = <0x48328000 0x2000>; + interrupts = ; + ti,hwmods = "vpfe1"; + status = "disabled"; + }; }; }; -- 1.9.1 -- 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
[PATCH 5/5] ARM: dts: am437x-gp-evm: add VPFE device tree data
From: Benoit Parrot Add device tree nodes and pinmux entries for Video Processing Front End (VPFE) on am437x gp evm. Signed-off-by: Benoit Parrot Signed-off-by: Lad, Prabhakar --- arch/arm/boot/dts/am437x-gp-evm.dts | 106 1 file changed, 106 insertions(+) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index e7ac47f..be2d285 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -254,6 +254,78 @@ 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7) >; }; + + vpfe0_pins_default: vpfe0_pins_default { + pinctrl-single,pins = < + 0x1B0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_hd mode 0*/ + 0x1B4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_vd mode 0*/ + 0x1C0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_pclk mode 0*/ + 0x1C4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data8 mode 0*/ + 0x1C8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data9 mode 0*/ + 0x208 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data0 mode 0*/ + 0x20C (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data1 mode 0*/ + 0x210 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data2 mode 0*/ + 0x214 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data3 mode 0*/ + 0x218 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data4 mode 0*/ + 0x21C (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data5 mode 0*/ + 0x220 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data6 mode 0*/ + 0x224 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data7 mode 0*/ + >; + }; + + vpfe0_pins_sleep: vpfe0_pins_sleep { + pinctrl-single,pins = < + 0x1B0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_hd mode 0*/ + 0x1B4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_vd mode 0*/ + 0x1C0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_pclk mode 0*/ + 0x1C4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data8 mode 0*/ + 0x1C8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data9 mode 0*/ + 0x208 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data0 mode 0*/ + 0x20C (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data1 mode 0*/ + 0x210 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data2 mode 0*/ + 0x214 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data3 mode 0*/ + 0x218 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data4 mode 0*/ + 0x21C (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data5 mode 0*/ + 0x220 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data6 mode 0*/ + 0x224 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam0_data7 mode 0*/ + >; + }; + + vpfe1_pins_default: vpfe1_pins_default { + pinctrl-single,pins = < + 0x1CC (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data9 mode 0*/ + 0x1D0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data8 mode 0*/ + 0x1D4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_hd mode 0*/ + 0x1D8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_vd mode 0*/ + 0x1DC (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_pclk mode 0*/ + 0x1E8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data0 mode 0*/ + 0x1EC (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data1 mode 0*/ + 0x1F0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data2 mode 0*/ + 0x1F4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data3 mode 0*/ + 0x1F8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data4 mode 0*/ + 0x1FC (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data5 mode 0*/ + 0x200 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data6 mode 0*/ + 0x204 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data7 mode 0*/ + >; + }; + + vpfe1_pins_sleep: vpfe1_pins_sleep { + pinctrl-single,pins = < + 0x1CC (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam1_data9 mode 0*/ + 0x1D0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam1_data8 mode 0*/ + 0x1D4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam1_hd mode 0*/ + 0x1D8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) /* cam1_vd mode 0*/ + 0x1D
[PATCH 4/5] ARM: dts: am437x-sk-evm: add VPFE device tree data
From: Darren Etheridge Add device tree nodes and pinmux entries for Video Processing Front End (VPFE) on am437x sk evm. Signed-off-by: Darren Etheridge Signed-off-by: Felipe Balbi Signed-off-by: Lad, Prabhakar --- arch/arm/boot/dts/am437x-sk-evm.dts | 58 + 1 file changed, 58 insertions(+) diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts index 859ff3d..2f4898b 100644 --- a/arch/arm/boot/dts/am437x-sk-evm.dts +++ b/arch/arm/boot/dts/am437x-sk-evm.dts @@ -184,6 +184,46 @@ >; }; + vpfe0_pins_default: vpfe0_pins_default { + pinctrl-single,pins = < + 0x1b0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_hd mode 0*/ + 0x1b4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_vd mode 0*/ + 0x1b8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_field mode 0*/ + 0x1bc (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_wen mode 0*/ + 0x1c0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_pclk mode 0*/ + 0x1c4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data8 mode 0*/ + 0x1c8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data9 mode 0*/ + 0x208 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data0 mode 0*/ + 0x20c (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data1 mode 0*/ + 0x210 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data2 mode 0*/ + 0x214 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data3 mode 0*/ + 0x218 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data4 mode 0*/ + 0x21c (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data5 mode 0*/ + 0x220 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data6 mode 0*/ + 0x224 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam0_data7 mode 0*/ + >; + }; + + vpfe0_pins_sleep: vpfe0_pins_sleep { + pinctrl-single,pins = < + 0x1b0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1b4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1b8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1bc (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1c0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1c4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1c8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x208 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x20c (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x210 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x214 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x218 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x21c (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x220 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x224 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + >; + }; + cpsw_default: cpsw_default { pinctrl-single,pins = < /* Slave 1 */ @@ -611,3 +651,21 @@ &wdt { status = "okay"; }; + +&vpfe0 { + status = "okay"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&vpfe0_pins_default>; + pinctrl-1 = <&vpfe0_pins_sleep>; + + /* Camera port */ + port { + vpfe0_ep: endpoint { + /* remote-endpoint = <&sensor>; add once we have it */ + ti,am437x-vpfe-interface = <0>; + bus-width = <8>; + hsync-active = <0>; + vsync-active = <0>; + }; + }; +}; -- 1.9.1 -- 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
[PATCH 1/5] ARM: AM43xx: hwmod: add VPFE hwmod entries
From: Benoit Parrot this patch adds VPFE HWMOD data for AM43xx. Signed-off-by: Benoit Parrot Signed-off-by: Darren Etheridge Signed-off-by: Felipe Balbi Signed-off-by: Lad, Prabhakar --- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56 ++ arch/arm/mach-omap2/prcm43xx.h | 3 +- 2 files changed, 58 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c index fea01aa..bd9067e 100644 --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c @@ -483,6 +483,44 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = { }, }; +static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = { + .rev_offs = 0x0, + .sysc_offs = 0x104, + .sysc_flags = SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE, + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + MSTANDBY_FORCE | MSTANDBY_SMART | MSTANDBY_NO), + .sysc_fields= &omap_hwmod_sysc_type2, +}; + +static struct omap_hwmod_class am43xx_vpfe_hwmod_class = { + .name = "vpfe", + .sysc = &am43xx_vpfe_sysc, +}; + +static struct omap_hwmod am43xx_vpfe0_hwmod = { + .name = "vpfe0", + .class = &am43xx_vpfe_hwmod_class, + .clkdm_name = "l3s_clkdm", + .prcm = { + .omap4 = { + .modulemode = MODULEMODE_SWCTRL, + .clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET, + }, + }, +}; + +static struct omap_hwmod am43xx_vpfe1_hwmod = { + .name = "vpfe1", + .class = &am43xx_vpfe_hwmod_class, + .clkdm_name = "l3s_clkdm", + .prcm = { + .omap4 = { + .modulemode = MODULEMODE_SWCTRL, + .clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET, + }, + }, +}; + /* Interfaces */ static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = { .master = &am33xx_l3_main_hwmod, @@ -750,6 +788,22 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = { + .master = &am33xx_l3_main_hwmod, + .slave = &am43xx_vpfe0_hwmod, + .clk= "l3_gclk", + .flags = OCPIF_SWSUP_IDLE, + .user = OCP_USER_MPU, +}; + +static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = { + .master = &am33xx_l3_main_hwmod, + .slave = &am43xx_vpfe1_hwmod, + .clk= "l3_gclk", + .flags = OCPIF_SWSUP_IDLE, + .user = OCP_USER_MPU, +}; + static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = { &am33xx_l4_wkup__synctimer, &am43xx_l4_ls__timer8, @@ -848,6 +902,8 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = { &am43xx_l4_ls__dss, &am43xx_l4_ls__dss_dispc, &am43xx_l4_ls__dss_rfbi, + &am43xx_l3__vpfe0, + &am43xx_l3__vpfe1, NULL, }; diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h index ad7b3e9..8aa4c2c 100644 --- a/arch/arm/mach-omap2/prcm43xx.h +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -143,5 +143,6 @@ #define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268 #define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET0x05C0 #define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20 - +#define AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET 0x0068 +#define AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET 0x0070 #endif -- 1.9.1 -- 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
[PATCH 0/5] ARM: am43xx: enable VPFE
From: Benoit Parrot This patch series adds hwmods and VPFE DT node entries for am43xx devices. The sensor driver is not allowed to release so the remote endpoint for vpfe dt nodes are commented at the moment. Benoit Parrot (4): ARM: AM43xx: hwmod: add VPFE hwmod entries ARM: dts: am4372: add VPFE DT node entries ARM: dts: am43x-epos-evm: add VPFE device tree data ARM: dts: am437x-gp-evm: add VPFE device tree data Darren Etheridge (1): ARM: dts: am437x-sk-evm: add VPFE device tree data arch/arm/boot/dts/am4372.dtsi | 16 + arch/arm/boot/dts/am437x-gp-evm.dts| 106 + arch/arm/boot/dts/am437x-sk-evm.dts| 58 arch/arm/boot/dts/am43x-epos-evm.dts | 53 +++ arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56 +++ arch/arm/mach-omap2/prcm43xx.h | 3 +- 6 files changed, 291 insertions(+), 1 deletion(-) -- 1.9.1 -- 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
[PATCH 3/5] ARM: dts: am43x-epos-evm: add VPFE device tree data
From: Benoit Parrot Add device tree nodes and pinmux entries for Video Processing Front End (VPFE) on am43x epos evm. Signed-off-by: Benoit Parrot Signed-off-by: Darren Etheridge Signed-off-by: Felipe Balbi Signed-off-by: Lad, Prabhakar --- arch/arm/boot/dts/am43x-epos-evm.dts | 53 1 file changed, 53 insertions(+) diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index ac3e485..6a43801 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -243,6 +243,42 @@ 0x08C (PIN_OUTPUT_PULLUP | MUX_MODE7) >; }; + + vpfe1_pins_default: vpfe1_pins_default { + pinctrl-single,pins = < + 0x1cc (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data9 mode 0 */ + 0x1d0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data8 mode 0 */ + 0x1d4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_hd mode 0 */ + 0x1d8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_vd mode 0 */ + 0x1dc (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_pclk mode 0 */ + 0x1e8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data0 mode 0 */ + 0x1ec (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data1 mode 0 */ + 0x1f0 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data2 mode 0 */ + 0x1f4 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data3 mode 0 */ + 0x1f8 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data4 mode 0 */ + 0x1fc (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data5 mode 0 */ + 0x200 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data6 mode 0 */ + 0x204 (PIN_INPUT_PULLUP | MUX_MODE0) /* cam1_data7 mode 0 */ + >; + }; + + vpfe1_pins_sleep: vpfe1_pins_sleep { + pinctrl-single,pins = < + 0x1cc (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1d0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1d4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1d8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1dc (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1e8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1ec (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1f0 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1f4 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1f8 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x1fc (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x200 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + 0x204 (DS0_PULL_UP_DOWN_EN | INPUT_EN | MUX_MODE7) + >; + }; }; matrix_keypad: matrix_keypad@0 { @@ -626,3 +662,20 @@ }; }; }; + +&vpfe1 { + status = "okay"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&vpfe1_pins_default>; + pinctrl-1 = <&vpfe1_pins_sleep>; + + port { + vpfe1_ep: endpoint { + /* remote-endpoint = <&sensor>; add once we have it */ + ti,am437x-vpfe-interface = <0>; + bus-width = <8>; + hsync-active = <0>; + vsync-active = <0>; + }; + }; +}; -- 1.9.1 -- 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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Fixing up Paul's email id. cheers, -roger On 18/12/14 17:49, Roger Quadros wrote: > There are quite a few hwmods that don't have sysconfig register and so > _find_mpu_rt_port(oh) will return NULL thus preventing ready state check > on those modules after the module is enabled. > > This can potentially cause a bus access error if the module is accessed > before the module is ready. > > Get rid of the redundant _find_mpu_rt_port() check from the > _wait_target_ready() > funcion for all the SoCs. The following PRCM register access that checks the > module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. > > e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. > > [ 16.672978] [ cut here ] > [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 > l3_interrupt_handler+0x234/0x35c() > [ 16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET > L4_PER_0 (Read): Data Access in User mode during Functional access > [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 > videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf > industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x > pixcir_i2c_ts c_can dc > [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted > 3.14.26-02561-gf733aa036398 #180 > [ 16.739747] Backtrace: > [ 16.742336] [] (dump_backtrace) from [] > (show_stack+0x18/0x1c) > [ 16.750285] r6:0093 r5:0009 r4:eab5b8a8 r3: > [ 16.756252] [] (show_stack) from [] > (dump_stack+0x20/0x28) > [ 16.763870] [] (dump_stack) from [] > (warn_slowpath_common+0x6c/0x8c) > [ 16.772408] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x38/0x40) > [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210 > [ 16.788626] [] (warn_slowpath_fmt) from [] > (l3_interrupt_handler+0x234/0x35c) > [ 16.797968] r3:ed0cd480 r2:c0730508 > [ 16.801747] [] (l3_interrupt_handler) from [] > (handle_irq_event_percpu+0x54/0x1bc) > [ 16.811533] r10:ed005600 r9:c084855b r8:002a r7: r6: > r5:002a > [ 16.819780] r4:ed0e6d80 > [ 16.822453] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x30/0x40) > [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: > r5:002a > [ 16.840052] r4:ed005600 > [ 16.842744] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0x74/0x128) > [ 16.851702] r4:ed005600 r3: > [ 16.855479] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x28/0x38) > [ 16.864523] r4:002a r3:c0066164 > [ 16.868294] [] (generic_handle_irq) from [] > (handle_IRQ+0x38/0x8c) > [ 16.876612] r4:c081c640 r3:0202 > [ 16.880380] [] (handle_IRQ) from [] > (gic_handle_irq+0x30/0x5c) > [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100 > [ 16.894303] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x50) > [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80) > [ 16.907499] ba20: > 0006 > [ 16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 > bf011420 eb2b6960 > [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c > 600f0013 > [ 16.933317] r7:eab5ba6c r6: r5:600f0013 r4:bf07702c > [ 16.939317] [] (c_can_plat_read_reg_aligned_to_16bit > [c_can_platform]) from [] (c_can_get_berr_counter+0x38/0x64 [c_can]) > [ 16.952696] [] (c_can_get_berr_counter [c_can]) from > [] (can_fill_info+0x124/0x15c [can_dev]) > [ 16.963480] r5:ec8c9740 r4:ed3d3000 > [ 16.967253] [] (can_fill_info [can_dev]) from [] > (rtnl_fill_ifinfo+0x58c/0x8fc) > [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780 > [ 16.981613] [] (rtnl_fill_ifinfo) from [] > (rtnl_dump_ifinfo+0xf0/0x1dc) > [ 16.990401] r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 > r5:ed3d3000 > [ 16.998671] r4: > [ 17.001342] [] (rtnl_dump_ifinfo) from [] > (netlink_dump+0xa8/0x1e0) > [ 17.009772] r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 > r5:ec8c9740 > [ 17.018050] r4:ebd4d000 > [ 17.020714] [] (netlink_dump) from [] > (__netlink_dump_start+0x104/0x154) > [ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000 > [ 17.034454] [] (__netlink_dump_start) from [] > (rtnetlink_rcv_msg+0x110/0x1f4) > [ 17.043778] r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0 > [ 17.049743] [] (rtnetlink_rcv_msg) from [] > (netlink_rcv_skb+0xb4/0xc8) > [ 17.058449] r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0 > [ 17.065534] [] (netlink_rcv_skb) from [] > (rtnetlink_rcv+0x24/0x2c) > [ 17.073854] r6:ebd4d000 r5:0014 r4:ec8c9980 r3:c0504110 > [ 17.079846] [] (rtnetlink_rcv) from [] > (netlink_unicast+0x180/0x1ec) > [ 17.088363] r4:ed0c6800 r3:c0504110 > [ 17.092113] [] (netlink_unicast) from [] > (netlink_sendmsg+0x2ac/0x380) > [ 17.100
[PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
There are quite a few hwmods that don't have sysconfig register and so _find_mpu_rt_port(oh) will return NULL thus preventing ready state check on those modules after the module is enabled. This can potentially cause a bus access error if the module is accessed before the module is ready. Get rid of the redundant _find_mpu_rt_port() check from the _wait_target_ready() funcion for all the SoCs. The following PRCM register access that checks the module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. [ 16.672978] [ cut here ] [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c() [ 16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180 [ 16.739747] Backtrace: [ 16.742336] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 16.750285] r6:0093 r5:0009 r4:eab5b8a8 r3: [ 16.756252] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 16.763870] [] (dump_stack) from [] (warn_slowpath_common+0x6c/0x8c) [ 16.772408] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40) [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210 [ 16.788626] [] (warn_slowpath_fmt) from [] (l3_interrupt_handler+0x234/0x35c) [ 16.797968] r3:ed0cd480 r2:c0730508 [ 16.801747] [] (l3_interrupt_handler) from [] (handle_irq_event_percpu+0x54/0x1bc) [ 16.811533] r10:ed005600 r9:c084855b r8:002a r7: r6: r5:002a [ 16.819780] r4:ed0e6d80 [ 16.822453] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x30/0x40) [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: r5:002a [ 16.840052] r4:ed005600 [ 16.842744] [] (handle_irq_event) from [] (handle_fasteoi_irq+0x74/0x128) [ 16.851702] r4:ed005600 r3: [ 16.855479] [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) [ 16.864523] r4:002a r3:c0066164 [ 16.868294] [] (generic_handle_irq) from [] (handle_IRQ+0x38/0x8c) [ 16.876612] r4:c081c640 r3:0202 [ 16.880380] [] (handle_IRQ) from [] (gic_handle_irq+0x30/0x5c) [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100 [ 16.894303] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x50) [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80) [ 16.907499] ba20: 0006 [ 16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960 [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 [ 16.933317] r7:eab5ba6c r6: r5:600f0013 r4:bf07702c [ 16.939317] [] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [] (c_can_get_berr_counter+0x38/0x64 [c_can]) [ 16.952696] [] (c_can_get_berr_counter [c_can]) from [] (can_fill_info+0x124/0x15c [can_dev]) [ 16.963480] r5:ec8c9740 r4:ed3d3000 [ 16.967253] [] (can_fill_info [can_dev]) from [] (rtnl_fill_ifinfo+0x58c/0x8fc) [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780 [ 16.981613] [] (rtnl_fill_ifinfo) from [] (rtnl_dump_ifinfo+0xf0/0x1dc) [ 16.990401] r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 r5:ed3d3000 [ 16.998671] r4: [ 17.001342] [] (rtnl_dump_ifinfo) from [] (netlink_dump+0xa8/0x1e0) [ 17.009772] r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740 [ 17.018050] r4:ebd4d000 [ 17.020714] [] (netlink_dump) from [] (__netlink_dump_start+0x104/0x154) [ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000 [ 17.034454] [] (__netlink_dump_start) from [] (rtnetlink_rcv_msg+0x110/0x1f4) [ 17.043778] r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0 [ 17.049743] [] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xb4/0xc8) [ 17.058449] r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0 [ 17.065534] [] (netlink_rcv_skb) from [] (rtnetlink_rcv+0x24/0x2c) [ 17.073854] r6:ebd4d000 r5:0014 r4:ec8c9980 r3:c0504110 [ 17.079846] [] (rtnetlink_rcv) from [] (netlink_unicast+0x180/0x1ec) [ 17.088363] r4:ed0c6800 r3:c0504110 [ 17.092113] [] (netlink_unicast) from [] (netlink_sendmsg+0x2ac/0x380) [ 17.100813] r10: r8:0008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4 [ 17.109083] [] (netlink_sendmsg) from [] (sock_sendmsg+0x90/0xb0) [ 17.117305] r10: r9:eab5a000 r8:becdda3c r7:000c r6:ea978400 r5:eab5be70 [ 17.125563] r4:c05103c4 [ 17.128225] [] (sock_sendmsg
Re: [PATCH] gpio: pcf857x: restore the initial line state of all pcf lines
On 12/18/2014 12:18 AM, Kishon Vijay Abraham I wrote: > > > On Tuesday 16 December 2014 02:20 AM, Nishanth Menon wrote: >> On 12/12/2014 02:06 AM, Kishon Vijay Abraham I wrote: >>> The reset values for all the PCF lines are high and hence on shutdown >>> we should drive all the lines high in order to bring it to the reset state. >>> >>> This is actually required since pcf doesn't have a reset line and even after >>> warm reset (by invoking "reboot" in prompt) the pcf lines maintains it's >>> previous programmed state. This becomes a problem if the boards are designed >>> to work with the default initial state. >>> >>> DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD and >>> this line should be driven high in order for the MMC/SD to be detected. >>> This line is modelled as regulator and the hsmmc driver takes care of >>> enabling >>> and disabling it. In the case of 'reboot', during shutdown path as part of >>> it's >>> cleanup process the hsmmc driver disables this regulator. This makes MMC >>> boot >>> not functional. >>> >>> Fixed it by driving high all the pcf lines. >>> >>> Signed-off-by: Kishon Vijay Abraham I >>> --- >>> drivers/gpio/gpio-pcf857x.c |9 + >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c >>> index 236708a..00b15b2 100644 >>> --- a/drivers/gpio/gpio-pcf857x.c >>> +++ b/drivers/gpio/gpio-pcf857x.c >>> @@ -448,6 +448,14 @@ static int pcf857x_remove(struct i2c_client *client) >>> return status; >>> } >>> >>> +static void pcf857x_shutdown(struct i2c_client *client) >>> +{ >>> + struct pcf857x *gpio = i2c_get_clientdata(client); >>> + >>> + /* Drive all the I/O lines high */ >>> + gpio->write(gpio->client, BIT(gpio->chip.ngpio) - 1); >> >> you might force a contention here - depending on System configuration. >> example: >> +---+ >> | | >> | U1 | +--+ +---+ >> | +-> | | | >> +---+ | | | | >> | Switch<-+SoC| >> +---+ | | | | >> | | | | | | >> | U2<-+--^---+ +---+ >> | || >> | || >> +---+| >> +--+--+ >> | | >> | PCF | >> | | >> +-+ >> >> At low, SoC pin is connected to U2 as drive. when reset to high, you >> now have U1 driving to the same pin that SoC has, potentially >> resulting in contention. >> >> >> Unfortunately, at this level, you do not know what the state of the >> system is, blindly forcing a pin level will potentially cause >> contention risk depending on pin configuration. > > Assume we are doing a reset when the system is powered on, irrespective of the > state of the system, we'll be forcing the pin level to the default state. Yes, I dont deny that system will be fine *after* reset sequence is started or completed. However there is a duration between the pcf shutdown handler is called and the final reset handler is invoked - that is the duration when the contention might cause device behavior. Essentially ignoring the state various drivers have asked PCF to setup the pins and doing a hands down configuration may have side effects we cant properly expect. > > The same thing happens here so I don't think this would be a problem. > > Thanks > Kishon > -- Regards, Nishanth Menon -- 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 4430 SDP: rather sick with recent kernels
On 12/18/2014 01:48 PM, Peter Rosin wrote: Russel King wrote: *snip* Now, we have this call to snd_soc_of_parse_audio_routing(), which allocates some memory, copies the old routes into it, and then adds to them from DT. That explains why the pointer and number of routes are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. So that doesn't work - but importantly, it does point towards a possible culpret - snd_soc_of_parse_audio_routing(). This is obvious when you stop and think about what it's doing, this is truely where this bug lies, and it /is/ in generic ASoC code. The problem is that this function doesn't consider the implications of deferred probing. Let's see what happens if we defer, and re-do the ABE initialisation, including calling this function: 17 + 19 = 36. - first probe 17 + 19 + 19 = 55. - second probe Oh - that works in terms of the number, and it would also explain why the table has been screwed - because the second time we memcpy(), we're memcpy()ing from data which was allocated via devm_kzalloc(), and thus would have been freed after the first failed probe. Mark - this is a core ASoC problem. Sorry about this, I wasn't even aware of deferred probing when I wrote f8781db8aeb1. From my point of view, it is certainly possible to solve this in the card driver which needs to add card dapm routes instead. So, a revert is fine by me, if no better solution comes up. Looks to me that for this feature we would need a separate function, something like: int snd_soc_of_parse_audio_routing_append(struct snd_soc_card *card, const char *propname); even if the implementation behind would be the same. But I guess it is little late for new designs at this phase. Best regards, Jyri -- 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 4430 SDP: rather sick with recent kernels
Russel King wrote: *snip* > Now, we have this call to snd_soc_of_parse_audio_routing(), which > allocates some memory, copies the old routes into it, and then adds > to them from DT. That explains why the pointer and number of routes > are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. > So that doesn't work - but importantly, it does point towards a > possible culpret - snd_soc_of_parse_audio_routing(). > > This is obvious when you stop and think about what it's doing, this is > truely where this bug lies, and it /is/ in generic ASoC code. > > The problem is that this function doesn't consider the implications of > deferred probing. Let's see what happens if we defer, and re-do the > ABE initialisation, including calling this function: > > 17 + 19 = 36. - first probe > 17 + 19 + 19 = 55. - second probe > > Oh - that works in terms of the number, and it would also explain why > the table has been screwed - because the second time we memcpy(), we're > memcpy()ing from data which was allocated via devm_kzalloc(), and thus > would have been freed after the first failed probe. > > Mark - this is a core ASoC problem. Sorry about this, I wasn't even aware of deferred probing when I wrote f8781db8aeb1. From my point of view, it is certainly possible to solve this in the card driver which needs to add card dapm routes instead. So, a revert is fine by me, if no better solution comes up. Cheers, Peter -- 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 4430 SDP: rather sick with recent kernels
On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote: > So that doesn't work - but importantly, it does point towards a > possible culpret - snd_soc_of_parse_audio_routing(). > This is obvious when you stop and think about what it's doing, this is > truely where this bug lies, and it /is/ in generic ASoC code. > The problem is that this function doesn't consider the implications of > deferred probing. Let's see what happens if we defer, and re-do the > ABE initialisation, including calling this function: Right, spot on - I'll send a revert for that upstream. Thanks for tracking this down. signature.asc Description: Digital signature
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 11:08:06PM +0200, Jyri Sarha wrote: > I tried booting my 4460 Panda - which is the closest thing to 4430SDP that > I've got - on next-20141217, but I could not get it to the point where the > omap-abe-twl6040 probed. It probably is the problem you are talking about as > the hang does not happen if I disable ASoC ABE all together, right? > > I'll take a deeper look at it tomorrow, as Peter is not working ATM. Digging into this at my end: [] (snd_soc_instantiate_card) from [] (snd_soc_register_card+0x344/0x424) r10:005c r9: r8:0620 r7:ce437630 r6:ce437630 r5:0002 r4:c05cae58 c02c95e8: e1a4mov r0, r4 c02c95ec: ebfffc29bl c02c8698 So 'card' is 0xc05cae58, which is correct: c05cae58 d omap_abe_card [] (snd_soc_dapm_add_routes) from [] (snd_soc_instantiate_card+0x8a8/0xc14) r10: r9: r8:ce437010 r7:ce437630 r6:0002 r5:c05cb0bc r4:c05cae58 c02c8f28: e594110cldr r1, [r4, #268] ; 0x10c c02c8f2c: e351cmp r1, #0 c02c8f30: 0a02beq c02c8f40 c02c8f34: e51b0044ldr r0, [fp, #-68] ; 0x44 c02c8f38: e5942110ldr r2, [r4, #272] ; 0x110 c02c8f3c: eb000c6abl c02cc0ec This corresponds with: if (card->dapm_routes) snd_soc_dapm_add_routes(&card->dapm, card->dapm_routes, card->num_dapm_routes); Again, we see r4 is the omap_abe_card, and the code is loading dapm_routes and num_dapm_routes. The dump of this in the vmlinux file gives: c05cae58 : ... c05caf5c: c045d098umaalgt sp, r5, r8, r0 c05caf60: 000aandeq r0, r0, sl c05caf64: c045d6a4subgt sp, r5, r4, lsr #13 c05caf68: 0011andeq r0, r0, r1, lsl r0 and 0x10c/0x110 gives 0xc045d6a4 / 17. c045d6a4 r audio_map So that looks fine. [] (snd_soc_dapm_add_route) from [] (snd_soc_dapm_add_routes+0x48/0xac) r10:c0458801 r9: r8:0037 r7: r6: r5:c05cafb8 r4:ce57b420 c02cc0ec : c02cc0fc: e1a05000mov r5, r0 c02cc104: e1a04001mov r4, r1 c02cc108: e3a07000mov r7, #0 c02cc114: e1a08002mov r8, r2 c02cc118: e2844010add r4, r4, #16 c02cc120: e1a06007mov r6, r7 c02cc128: ea0fb c02cc16c c02cc12c: e1a5mov r0, r5 c02cc130: eb74bl c02cbf08 c02cc134: e2509000subsr9, r0, #0 c02cc138: aa09bge c02cc164 ... c02cc168: e2844010add r4, r4, #16 c02cc16c: e1560008cmp r6, r8 c02cc170: e2441010sub r1, r4, #16 c02cc174: baecblt c02cc12c Here, r5 is &card->dapm. r4 should be card->dapm_routes, possibly incremented by 16 up to 17 times, which should be in the range of 0xc045d6a4 - 0xc045d7b4, but it isn't, it's 0xce57b420. Also, r8 is card->num_dapm_routes, which should be 17, but it's 0x37 (55). The index is r6, and at least that's sensibly at zero. Now, we have this call to snd_soc_of_parse_audio_routing(), which allocates some memory, copies the old routes into it, and then adds to them from DT. That explains why the pointer and number of routes are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. So that doesn't work - but importantly, it does point towards a possible culpret - snd_soc_of_parse_audio_routing(). This is obvious when you stop and think about what it's doing, this is truely where this bug lies, and it /is/ in generic ASoC code. The problem is that this function doesn't consider the implications of deferred probing. Let's see what happens if we defer, and re-do the ABE initialisation, including calling this function: 17 + 19 = 36. - first probe 17 + 19 + 19 = 55. - second probe Oh - that works in terms of the number, and it would also explain why the table has been screwed - because the second time we memcpy(), we're memcpy()ing from data which was allocated via devm_kzalloc(), and thus would have been freed after the first failed probe. Mark - this is a core ASoC problem. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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