Re: OMAP 4430 SDP: rather sick with recent kernels

2014-12-18 Thread Russell King - ARM Linux 
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:

[c02c8698] (snd_soc_instantiate_card) from [c02c95f0] 
(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 snd_soc_instantiate_card

So 'card' is 0xc05cae58, which is correct: c05cae58 d omap_abe_card

[c02cc0ec] (snd_soc_dapm_add_routes) from [c02c8f40] 
(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 
snd_soc_instantiate_card+0x8a8
c02c8f34:   e51b0044ldr r0, [fp, #-68]  ; 0x44
c02c8f38:   e5942110ldr r2, [r4, #272]  ; 0x110
c02c8f3c:   eb000c6abl  c02cc0ec snd_soc_dapm_add_routes

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 omap_abe_card:
...
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.

[c02cbf08] (snd_soc_dapm_add_route) from [c02cc134] 
(snd_soc_dapm_add_routes+0x48/0xac)
 r10:c0458801 r9: r8:0037 r7: r6: r5:c05cafb8
 r4:ce57b420

c02cc0ec snd_soc_dapm_add_routes:
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 snd_soc_dapm_add_routes+0x80

c02cc12c:   e1a5mov r0, r5
c02cc130:   eb74bl  c02cbf08 snd_soc_dapm_add_route
c02cc134:   e2509000subsr9, r0, #0
c02cc138:   aa09bge c02cc164 snd_soc_dapm_add_routes+0x78
...
c02cc168:   e2844010add r4, r4, #16
c02cc16c:   e1560008cmp r6, r8
c02cc170:   e2441010sub r1, r4, #16
c02cc174:   baecblt c02cc12c snd_soc_dapm_add_routes+0x40

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

Re: OMAP 4430 SDP: rather sick with recent kernels

2014-12-18 Thread Mark Brown 
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

2014-12-18 Thread Peter Rosin 
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

2014-12-18 Thread Jyri Sarha 

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: [PATCH] gpio: pcf857x: restore the initial line state of all pcf lines

2014-12-18 Thread Nishanth Menon 
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 kis...@ti.com
 ---
  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

[PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

2014-12-18 Thread Roger Quadros 
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] [c0011108] (dump_backtrace) from [c00112a4] 
(show_stack+0x18/0x1c)
[   16.750285]  r6:0093 r5:0009 r4:eab5b8a8 r3:
[   16.756252] [c001128c] (show_stack) from [c05a4418] 
(dump_stack+0x20/0x28)
[   16.763870] [c05a43f8] (dump_stack) from [c0037120] 
(warn_slowpath_common+0x6c/0x8c)
[   16.772408] [c00370b4] (warn_slowpath_common) from [c00371e4] 
(warn_slowpath_fmt+0x38/0x40)
[   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
[   16.788626] [c00371b0] (warn_slowpath_fmt) from [c027fa94] 
(l3_interrupt_handler+0x234/0x35c)
[   16.797968]  r3:ed0cd480 r2:c0730508
[   16.801747] [c027f860] (l3_interrupt_handler) from [c0063758] 
(handle_irq_event_percpu+0x54/0x1bc)
[   16.811533]  r10:ed005600 r9:c084855b r8:002a r7: r6: 
r5:002a
[   16.819780]  r4:ed0e6d80
[   16.822453] [c0063704] (handle_irq_event_percpu) from [c00638f0] 
(handle_irq_event+0x30/0x40)
[   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: 
r5:002a
[   16.840052]  r4:ed005600
[   16.842744] [c00638c0] (handle_irq_event) from [c00661d8] 
(handle_fasteoi_irq+0x74/0x128)
[   16.851702]  r4:ed005600 r3:
[   16.855479] [c0066164] (handle_fasteoi_irq) from [c0063068] 
(generic_handle_irq+0x28/0x38)
[   16.864523]  r4:002a r3:c0066164
[   16.868294] [c0063040] (generic_handle_irq) from [c000ef60] 
(handle_IRQ+0x38/0x8c)
[   16.876612]  r4:c081c640 r3:0202
[   16.880380] [c000ef28] (handle_IRQ) from [c00084f0] 
(gic_handle_irq+0x30/0x5c)
[   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
[   16.894303] [c00084c0] (gic_handle_irq) from [c05a8d80] 
(__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] [bf077000] (c_can_plat_read_reg_aligned_to_16bit 
[c_can_platform]) from [bf035220] (c_can_get_berr_counter+0x38/0x64 [c_can])
[   16.952696] [bf0351e8] (c_can_get_berr_counter [c_can]) from [bf010294] 
(can_fill_info+0x124/0x15c [can_dev])
[   16.963480]  r5:ec8c9740 r4:ed3d3000
[   16.967253] [bf010170] (can_fill_info [can_dev]) from [c0502fa8] 
(rtnl_fill_ifinfo+0x58c/0x8fc)
[   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
[   16.981613] [c0502a1c] (rtnl_fill_ifinfo) from [c0503408] 
(rtnl_dump_ifinfo+0xf0/0x1dc)
[   16.990401]  r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 
r5:ed3d3000
[   16.998671]  r4:
[   17.001342] [c0503318] (rtnl_dump_ifinfo) from [c050e6e4] 
(netlink_dump+0xa8/0x1e0)
[   17.009772]  r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 
r5:ec8c9740
[   17.018050]  r4:ebd4d000
[   17.020714] [c050e63c] (netlink_dump) from [c050ec10] 
(__netlink_dump_start+0x104/0x154)
[   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
[   17.034454] [c050eb0c] (__netlink_dump_start) from [c0505604] 
(rtnetlink_rcv_msg+0x110/0x1f4)
[   17.043778]  r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0
[   17.049743] [c05054f4] (rtnetlink_rcv_msg) from [c05108e8] 
(netlink_rcv_skb+0xb4/0xc8)
[   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
[   17.065534] [c0510834] (netlink_rcv_skb) from [c0504134] 
(rtnetlink_rcv+0x24/0x2c)
[   17.073854]  r6:ebd4d000 r5:0014 r4:ec8c9980 r3:c0504110
[   17.079846] [c0504110] (rtnetlink_rcv) from [c05102ac] 
(netlink_unicast+0x180/0x1ec)
[   17.088363]  r4:ed0c6800 r3:c0504110
[   17.092113] [c051012c]

Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

2014-12-18 Thread Roger Quadros 
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] [c0011108] (dump_backtrace) from [c00112a4] 
 (show_stack+0x18/0x1c)
 [   16.750285]  r6:0093 r5:0009 r4:eab5b8a8 r3:
 [   16.756252] [c001128c] (show_stack) from [c05a4418] 
 (dump_stack+0x20/0x28)
 [   16.763870] [c05a43f8] (dump_stack) from [c0037120] 
 (warn_slowpath_common+0x6c/0x8c)
 [   16.772408] [c00370b4] (warn_slowpath_common) from [c00371e4] 
 (warn_slowpath_fmt+0x38/0x40)
 [   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
 [   16.788626] [c00371b0] (warn_slowpath_fmt) from [c027fa94] 
 (l3_interrupt_handler+0x234/0x35c)
 [   16.797968]  r3:ed0cd480 r2:c0730508
 [   16.801747] [c027f860] (l3_interrupt_handler) from [c0063758] 
 (handle_irq_event_percpu+0x54/0x1bc)
 [   16.811533]  r10:ed005600 r9:c084855b r8:002a r7: r6: 
 r5:002a
 [   16.819780]  r4:ed0e6d80
 [   16.822453] [c0063704] (handle_irq_event_percpu) from [c00638f0] 
 (handle_irq_event+0x30/0x40)
 [   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: 
 r5:002a
 [   16.840052]  r4:ed005600
 [   16.842744] [c00638c0] (handle_irq_event) from [c00661d8] 
 (handle_fasteoi_irq+0x74/0x128)
 [   16.851702]  r4:ed005600 r3:
 [   16.855479] [c0066164] (handle_fasteoi_irq) from [c0063068] 
 (generic_handle_irq+0x28/0x38)
 [   16.864523]  r4:002a r3:c0066164
 [   16.868294] [c0063040] (generic_handle_irq) from [c000ef60] 
 (handle_IRQ+0x38/0x8c)
 [   16.876612]  r4:c081c640 r3:0202
 [   16.880380] [c000ef28] (handle_IRQ) from [c00084f0] 
 (gic_handle_irq+0x30/0x5c)
 [   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
 [   16.894303] [c00084c0] (gic_handle_irq) from [c05a8d80] 
 (__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] [bf077000] (c_can_plat_read_reg_aligned_to_16bit 
 [c_can_platform]) from [bf035220] (c_can_get_berr_counter+0x38/0x64 [c_can])
 [   16.952696] [bf0351e8] (c_can_get_berr_counter [c_can]) from 
 [bf010294] (can_fill_info+0x124/0x15c [can_dev])
 [   16.963480]  r5:ec8c9740 r4:ed3d3000
 [   16.967253] [bf010170] (can_fill_info [can_dev]) from [c0502fa8] 
 (rtnl_fill_ifinfo+0x58c/0x8fc)
 [   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
 [   16.981613] [c0502a1c] (rtnl_fill_ifinfo) from [c0503408] 
 (rtnl_dump_ifinfo+0xf0/0x1dc)
 [   16.990401]  r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 
 r5:ed3d3000
 [   16.998671]  r4:
 [   17.001342] [c0503318] (rtnl_dump_ifinfo) from [c050e6e4] 
 (netlink_dump+0xa8/0x1e0)
 [   17.009772]  r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 
 r5:ec8c9740
 [   17.018050]  r4:ebd4d000
 [   17.020714] [c050e63c] (netlink_dump) from [c050ec10] 
 (__netlink_dump_start+0x104/0x154)
 [   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
 [   17.034454] [c050eb0c] (__netlink_dump_start) from [c0505604] 
 (rtnetlink_rcv_msg+0x110/0x1f4)
 [   17.043778]  r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0
 [   17.049743] [c05054f4] (rtnetlink_rcv_msg) from [c05108e8] 
 (netlink_rcv_skb+0xb4/0xc8)
 [   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
 [   17.065534] [c0510834] (netlink_rcv_skb) from [c0504134] 
 (rtnetlink_rcv+0x24/0x2c)
 [   17.073854]  r6:ebd4d000

[PATCH 0/5] ARM: am43xx: enable VPFE

2014-12-18 Thread Lad, Prabhakar 
From: Benoit Parrot bpar...@ti.com

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

2014-12-18 Thread Lad, Prabhakar 
From: Benoit Parrot bpar...@ti.com

Add device tree nodes and pinmux entries for Video Processing
Front End (VPFE) on am43x epos evm.

Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 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

[PATCH 1/5] ARM: AM43xx: hwmod: add VPFE hwmod entries

2014-12-18 Thread Lad, Prabhakar 
From: Benoit Parrot bpar...@ti.com

this patch adds VPFE HWMOD data for AM43xx.

Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 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 4/5] ARM: dts: am437x-sk-evm: add VPFE device tree data

2014-12-18 Thread Lad, Prabhakar 
From: Darren Etheridge detheri...@ti.com

Add device tree nodes and pinmux entries for Video Processing
Front End (VPFE) on am437x sk evm.

Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 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 2/5] ARM: dts: am4372: add VPFE DT node entries

2014-12-18 Thread Lad, Prabhakar 
From: Benoit Parrot bpar...@ti.com

Add Video Processing Front End (VPFE) device tree
nodes for AM34xx family of devices.

Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 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 = GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH;
+   ti,hwmods = vpfe0;
+   status = disabled;
+   };
+
+   vpfe1: vpfe@48328000 {
+   compatible = ti,am437x-vpfe;
+   reg = 0x48328000 0x2000;
+   interrupts = GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH;
+   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

2014-12-18 Thread Lad, Prabhakar 
From: Benoit Parrot bpar...@ti.com

Add device tree nodes and pinmux entries for Video Processing
Front End (VPFE) on am437x gp evm.

Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 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)  /*

Re: OMAP 4430 SDP: rather sick with recent kernels

2014-12-18 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [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)
 [c00154b4] (unwind_backtrace) from [c0011b7c] (show_stack+0x10/0x14)
 [c0011b7c] (show_stack) from [c05d5068] (dump_stack+0x80/0x9c)
 [c05d5068] (dump_stack) from [c003e104] (warn_slowpath_common+0x78/0xb4)
 [c003e104] (warn_slowpath_common) from [c003e15c] (warn_slowpath_null+ 
 0x1c/0x24)
 [c003e15c] (warn_slowpath_null) from [c04dfc1c] (clk_disable+0x24/0x30)
 [c04dfc1c] (clk_disable) from [c0024ea0] (_disable_clocks+0x18/0x68)
 [c0024ea0] (_disable_clocks) from [c0026410] (_idle+0x15c/0x240)
 [c0026410] (_idle) from [c086fc48] (_setup+0x174/0x22c)
 [c086fc48] (_setup) from [c002684c] (omap_hwmod_for_each+0x30/0x5c)
 [c002684c] (omap_hwmod_for_each) from [c0870054] 
 (__omap_hwmod_setup_all+0x30/0x40)
 [c0870054] (__omap_hwmod_setup_all) from [c00089e4] 
 (do_one_initcall+0x80/0x1d8)
 [c00089e4] (do_one_initcall) from [c0862ea4] 
 (kernel_init_freeable+0x1f4/0x2cc)
 [c0862ea4] (kernel_init_freeable) from [c05cf184] (kernel_init+0x8/0xe4)
 [c05cf184] (kernel_init) from [c000e8e8] (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] tty: serial: 8250: omap: add ttySx console if the user didn't

2014-12-18 Thread Sebastian Andrzej Siewior 
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 bige...@linutronix.de
---

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: regression: Clock changes in next-20141205 break at least omap4

2014-12-18 Thread Paul Walmsley 
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

Re: bluetooth: Add hci_h4p driver

2014-12-18 Thread Pavel Machek 
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: bluetooth: Add hci_h4p driver

2014-12-18 Thread Pavel Machek 
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

GPMC clock question

2014-12-18 Thread Ezequiel Garcia 
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: GPMC clock question

2014-12-18 Thread Tony Lindgren 
* Ezequiel Garcia ezequ...@vanguardiasur.com.ar [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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-18 Thread Nishanth Menon 
On 12/17/2014 08:01 PM, Viresh Kumar wrote:
 On 17 December 2014 at 22:46, Kevin Hilman khil...@kernel.org 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/s21EMHNZVl
 11:   beaglebone-black: BOOT: PASS: err=8 warn=25, CPUFreq: PASS, 
 CPUIdle: N/A: http://slexy.org/raw/s2quawv4Qe
 12: beaglebone: BOOT: PASS: err=9 warn=20, CPUFreq: PASS, 
 CPUIdle: N/A: http://slexy.org/raw/s2iCPBeBSA
 13: craneboard: BOOT: PASS: err=21 warn=93, CPUFreq: N/A, 
 CPUIdle: N/A: http://slexy.org/raw/s21Mshl31r
 14

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-18 Thread Kevin Hilman 
On Thu, Dec 18, 2014 at 2:37 PM, Nishanth Menon n...@ti.com 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: GPMC clock question

2014-12-18 Thread Ezequiel Garcia 


On 12/18/2014 06:06 PM, Tony Lindgren wrote:
 * Ezequiel Garcia ezequ...@vanguardiasur.com.ar [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: regression: Clock changes in next-20141205 break at least omap4

2014-12-18 Thread Mike Turquette 
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 mode is supported).
 
 This might be the right way forward for the time being, and I like

Re: regression: Clock changes in next-20141205 break at least omap4

2014-12-18 Thread Paul Walmsley 
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 terms like parent clocks, it allows others to reason 
about how

Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

2014-12-18 Thread Lokesh Vutla 
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 lokeshvu...@ti.com

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] [c0011108] (dump_backtrace) from [c00112a4] 
 (show_stack+0x18/0x1c)
 [   16.750285]  r6:0093 r5:0009 r4:eab5b8a8 r3:
 [   16.756252] [c001128c] (show_stack) from [c05a4418] 
 (dump_stack+0x20/0x28)
 [   16.763870] [c05a43f8] (dump_stack) from [c0037120] 
 (warn_slowpath_common+0x6c/0x8c)
 [   16.772408] [c00370b4] (warn_slowpath_common) from [c00371e4] 
 (warn_slowpath_fmt+0x38/0x40)
 [   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
 [   16.788626] [c00371b0] (warn_slowpath_fmt) from [c027fa94] 
 (l3_interrupt_handler+0x234/0x35c)
 [   16.797968]  r3:ed0cd480 r2:c0730508
 [   16.801747] [c027f860] (l3_interrupt_handler) from [c0063758] 
 (handle_irq_event_percpu+0x54/0x1bc)
 [   16.811533]  r10:ed005600 r9:c084855b r8:002a r7: r6: 
 r5:002a
 [   16.819780]  r4:ed0e6d80
 [   16.822453] [c0063704] (handle_irq_event_percpu) from [c00638f0] 
 (handle_irq_event+0x30/0x40)
 [   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: 
 r5:002a
 [   16.840052]  r4:ed005600
 [   16.842744] [c00638c0] (handle_irq_event) from [c00661d8] 
 (handle_fasteoi_irq+0x74/0x128)
 [   16.851702]  r4:ed005600 r3:
 [   16.855479] [c0066164] (handle_fasteoi_irq) from [c0063068] 
 (generic_handle_irq+0x28/0x38)
 [   16.864523]  r4:002a r3:c0066164
 [   16.868294] [c0063040] (generic_handle_irq) from [c000ef60] 
 (handle_IRQ+0x38/0x8c)
 [   16.876612]  r4:c081c640 r3:0202
 [   16.880380] [c000ef28] (handle_IRQ) from [c00084f0] 
 (gic_handle_irq+0x30/0x5c)
 [   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
 [   16.894303] [c00084c0] (gic_handle_irq) from [c05a8d80] 
 (__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] [bf077000] (c_can_plat_read_reg_aligned_to_16bit 
 [c_can_platform]) from [bf035220] (c_can_get_berr_counter+0x38/0x64 
 [c_can])
 [   16.952696] [bf0351e8] (c_can_get_berr_counter [c_can]) from 
 [bf010294] (can_fill_info+0x124/0x15c [can_dev])
 [   16.963480]  r5:ec8c9740 r4:ed3d3000
 [   16.967253] [bf010170] (can_fill_info [can_dev]) from [c0502fa8] 
 (rtnl_fill_ifinfo+0x58c/0x8fc)
 [   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
 [   16.981613] [c0502a1c] (rtnl_fill_ifinfo) from [c0503408] 
 (rtnl_dump_ifinfo+0xf0/0x1dc)
 [   16.990401]

[PATCH 0/4] usb: dwc3: Fixes and code cleanup

2014-12-18 Thread Amit Virdi 
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

2014-12-18 Thread Amit Virdi 
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 amit.vi...@st.com
---
 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

[PATCH 3/4] usb: dwc3: gadget: Remove redundant check

2014-12-18 Thread Amit Virdi 
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 amit.vi...@st.com
---
 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

2014-12-18 Thread Amit Virdi 
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 amit.vi...@st.com
---
 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 4/4] usb: dwc3: Remove current_trb as it is unused

2014-12-18 Thread Amit Virdi 
This field was introduced but never used. So, remove it.

Signed-off-by: Amit Virdi amit.vi...@st.com
---
 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