date:20140514

Re: [PATCH 5/5] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume

2014-05-14 Thread George Cherian


On 5/13/2014 9:20 PM, Felipe Balbi wrote:

Hi,

On Thu, May 08, 2014 at 03:03:07PM +0530, George Cherian wrote:

Enabling the core interrupts in complete is too late for XHCI, and stops
xhci from proper operation. So remove prepare and complete and disable/enable

isn't this a bug in xhci ? I mean the driver should make no assumption
as to when IRQs are enabled, why do we need to enable IRQs earlier when
the device is only considered ready for use after -complete()
finishes executing ?
I dont think its a bug in xhci. In case of xhci-pci driver it actually 
does an

hcd-driver-pci_suspend (xhci_suspend) followed by synchronize_irq()
and the does a pci_disable_device().  In resume path it calls 
pci_enable_device()

followed by hcd-driver-pci_resume(xhci_resume).

In case of dwc3-omap we do have a wrapper register which can still 
disable the XHCI IRQs

even though the xhci driver enables the interrupts internally.

Now dwc3-omap wrapper driver should not actually fiddle with the core 
Interrupt

enable/disable except in probe/remove.


 From documentation we have:

107  * @complete: Undo the changes made by @prepare().  This method is executed 
for
108  *  all kinds of resume transitions, following one of the resume 
callbacks:
109  *  @resume(), @thaw(), @restore().  Also called if the state transition
110  *  fails before the driver's suspend callback: @suspend(), @freeze() or
111  *  @poweroff(), can be executed (e.g. if the suspend callback fails 
for one
112  *  of the other devices that the PM core has unsuccessfully attempted 
to
113  *  suspend earlier).
114  *  The PM core executes subsystem-level @complete() after it has 
executed
115  *  the appropriate resume callbacks for all devices.

which tells me that using -complete() to reenable IRQs is ok here.
Specially when you consider that the role of -prepare() is to prevent
new children from being created and, for a USB host, that means we
should prevent hub port changes.
Probably the patch should have been to still keep the complete/prepare 
in place
but not disable the core interrupts, rather enable/disable only the 
wrapper interrupt.

cheers




--
-George

--
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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

2014-05-14 Thread Tomi Valkeinen

On 13/05/14 18:25, Tony Lindgren wrote:

 Well ideally the revision info for a device would come from device
 revision registers rather using the SoC revision. In the DSS case when
 the SoC revision is needed by a device it maybe it can be deciphered
 from a combination of compatible flag and the clock rate for example?

I've been trying that. The HW guys didn't bother to update the DSS
revision registers, so they are useless. And, for example, the OMAP3 ES
difference is only about bitfield widths in two registers.

I tried writing too long value to the register on the earlier ES
version, hoping that the extra bits would be kept at zero, but that
wasn't the case. So I just don't see a way to detect this from the DSS's
point of view.

 Do you object to the compatible string remapping as such, or just that
 it's in arch/arm/mach-omap2?
 
 It's something I'd rather not have under mach-omap2 as that means that
 I may need to deal with it too to some extent. And I don't think we
 need to do such remapping, we should be able to use the panel compatible
 strings as they are just fine. It should be possible to figure out from
 the device tree properties what controller the panel belongs to. Or
 for now, use the panel registration to figure out what display controller
 it belongs to.
 
 I guess nothing prevents me from moving it to drivers/, and having some
 early-ish initcall doing the job.
 
 /me likes this idea if you need it at all. Stuff like this tends to stay
 and spread, so I'd rather not do the remapping of compatible strings at
 all.

Yep. I'll look to this. Thinking about it now, it kind of makes more
sense to have it in the omapdss's directory.

 So, since we can change the kernel later but not the DTS, I agree with
 you that the remapping is the least bad of our options.
 
 Yes the binding for the panel should just describe the panel so it can be
 used with whatever display controller. But we do have quite a few buses
 probing devices. How about set up the panel probing the same way?

 For the panels on display controller, just do the usual
 for_each_child_of_node(pdev-dev.of_node, child) and probe them?

 It seems the remapping of compatible strings is not needed in this
 as we're only picking up panels that are children of the display
 controller.

The panels (or display encoders) are not (usually) children of the
display controller. They are children of their respective control bus.
Say, an i2c panel is a child of i2c bus. If there's no control bus, like
is the case with the sharp panel, it's a platform device.

The video paths of the panels and encoders are connected using the v4l2
style ports/endpoints. We can use those to see what display controller a
panel is connected to, but only after the panel driver has already
probed. We don't have control for the actual probing, as that happens
with whatever the control bus is for the display component.

 I'm not sure what it would give us to try to be compatible with
 simple-panel.txt. The simple-panel bindings won't probably be compatible
 with the future common display drivers in any case, as the simple-panel
 binding is just too limited and doesn't describe the hardware fully.

 Hmm what else does a panel need where the existing binding cannot be
 extended?

 The existing simple-panel binding doesn't describe the connections of
 the panel, i.e. its video input. I guess it can be extended, but I don't
 see what the benefit is of trying to create new panel bindings
 compatible with the simple-panel bindings. As I see, the simple-panel
 bindings work only with very limited use cases, where the drivers make
 assumptions. Simple panel bindings cannot be used with omapdss, nor can
 it be used with the future common display framework.
 
 Well it seems at least the reset and enable pin standard from that
 binding can be kept.

Only enable gpio there. But even that's vague. Do you turn on the power
before or after setting the enable gpio? How long delay should be
between the power and the gpio? Different panels have different rules
for the power-up.

 But I'm not really familiar with using extending current bindings, and
 making new bindings compatible with old ones. Can you explain why it'd
 be good to have the sharp panel bindings compatible with simple-panel?
 In what kind of scenario would it be used?
 
 Ideally the panel binding just describes the panel and it should not
 matter which display controller it is a child of.

Yes, but that means the panel bindings need to have enough information
so that all display controllers can use it. Simple-panel bindings do not
have enough information. The simple-panel bindings do not have
information about the video bus input, and it doesn't even have
information about the resolution or bitdepth of the panel.

So I'm still asking, if we create sharp bindings that use the same
properties as the simple-panel bindings, and define that sharp panel is
compatible with simple-panel, what kind of scenario in practice would it

Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630

2014-05-14 Thread Tomi Valkeinen

On 13/05/14 18:26, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [140512 07:45]:
 On 12/05/14 17:39, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [140512 04:36]:
 On 09/05/14 17:37, Tony Lindgren wrote:

 This is just the 3730-evm with the Sharp VGA panel mentioned in
 this series.

 Hmm, well, those both look fine. The fck is well below the maximum,
 which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
 with this patch, but that should affect the GFX overlay.

 So you're just booting, and there are no applications that use the
 framebuffer? And there is no rotation or such configured?

 Right. The rotation is set to 3 though.

 Hmm, that's probably the issue then. VRFB rotation is very heavy on the
 memory bandwidth, and is generally a very easy way to get sync lost errors.
 
 I found another case without rotation where the error always triggers.
 By forcing 3730-evm LCD panel to QVGA mode it always seems to happen
 even without rotation.
 
 Without this patch with errors and no image:
 
 # cat /sys/kernel/debug/omapdss/clk 
 [   55.185729] DSS: dss_runtime_get
 [   55.189422] DSS: dss_runtime_put
 [   55.192810] DISPC: dispc_runtime_get
 [   55.196685] DISPC: dispc_runtime_put
 - DSS -
 DSS_FCK (DSS1_ALWON_FCLK) = 2700
 - DISPC -
 dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
 fck 2700
 - LCD -
 LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
 lck 2700lck div 1
 pck 540 pck div 5
 
 With this patch without errors and penguin showing:
 
 # cat /sys/kernel/debug/omapdss/clk
 [   19.905792] DSS: dss_runtime_get
 [   19.909545] DSS: dss_runtime_put
 [   19.912933] DISPC: dispc_runtime_get
 [   19.916778] DISPC: dispc_runtime_put
 - DSS -
 DSS_FCK (DSS1_ALWON_FCLK) = 10800
 - DISPC -
 dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
 fck 10800   
 - LCD -
 LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
 lck 10800   lck div 1
 pck 540 pck div 20
 
 In this case the errors are different too:
 
 DISPC: channel 0 xres 240 yres 320
 DISPC: pck 540
 DISPC: hsw 3 hfp 3 hbp 39 vsw 1 vfp 2 vbp 7
 DISPC: vsync_level 1 hsync_level 1 data_pclk_edge 1 de_level 0 sync_pclk_edge  0
 DISPC: hsync 18947Hz, vsync 57Hz
 DISPC: lck = 2700 (1)
 DISPC: pck = 540 (5)
 APPLY: DISPC IRQ: 0x60: GFX_FIFO_UNDERFLOW 
 APPLY: DISPC IRQ: 0x4062: GFX_FIFO_UNDERFLOW SYNC_LOST 
 DISPC: dispc_runtime_get
 omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

I'm quite out of ideas... The pixel clock is so low that underflow
shouldn't really happen. I was trying to find 3730 documentation that
would describe the PRCM's multipliers and dividers for DSS (i.e. the
ones you change in this patch), but I didn't find anything.

Maybe the DSS clock's fixed multiplier has been changed for 3730. But in
that case our .dts files related to the clocks are wrong too. The clock
nodes related to this are dpll4_m4x2_mul_ck, which is corresponds to the
dss_fck_multiplier value in omapdss, and dpll4_m4_ck, which
corresponds to the fck_div_max value.

One thing to try out is, without this patch, change
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to force the dss func clock higher.
With QVGA mode, you could try, say, value of 19, which should make sure
the fck is at least 19 times higher than pck.

 Regarding rotation, it does look like that with VGA mode enabling
 rotation makes the error trigger quite often on 3730.
  
 will handle it fine with the clock rates and bandwidth usage you have
 for your use cases.
 
 I don't think it's all because of rotation. And rotating my head

No, probably not. The pixel clocks are so low that the rotation should
work fine. Except if there's something wrong the the VRFB or the memory
bus, which make the VRFB rotation not work even with low pixel clocks.

 makes my neck hurt!

You need to learn to hold the device a bit differently!

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

2014-05-14 Thread Javier Martinez Canillas

Hello Jhon,

On Wed, May 14, 2014 at 7:44 AM, John Syn john3...@gmail.com wrote:

 On 5/13/14, 8:39 PM, Pantelis Antoniou pantelis.anton...@gmail.com
 wrote:

Hi John,

On May 13, 2014, at 1:24 PM, John Syn wrote:


 On 5/13/14, 10:51 AM, Javier Martinez Canillas jav...@dowhile0.org
 wrote:

 Hello Pantelis,

 On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
 pantelis.anton...@gmail.com wrote:
 Hi Javier,

 On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:

 On Tue, May 13, 2014 at 4:22 PM, Matt Porter matt.por...@linaro.org
 wrote:
 On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
 wrote:
 On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
 On 05/12/2014 04:57 PM, Robert Nelson wrote:
 Either case if fine with me.  As who knows when the dtc
 overlay will
 every truly make it mainline, as the capemgr was the only real
 kernel
 user of the i2c/at24 eeprom information.

 Sounds like we should keep it disabled though so u-boot can be
 used
 to toggle it while waiting for the capemgr. That's because the
 board
 has a header for pins, so it's not exactly limited to just the
 capes.

 Anybody working on enabling/disabling cape dtb configurations in
 u-boot?

 Well,

 Would Tom even approve of that in mainline u-boot? He didn't want
 my
 invert the gpio to enable the usb hub on the older beagle xm
 A/B..

 http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

 http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

 Using fdt set from the bootloader to use the same FDT for similar
 boards (like the example with Beagle xM variants) is kind of trying
 to
 replicate what we used to do from boards files where it was
possible
 to manage a set of boards using the same platform code.

 But Device Trees are meant to describe hardware and thus should be
 static, if two board are almost identical but slightly different,
 then
 are two different hardware where each need its proper FDT that
 describes it.


 I would think that using the 'fdt' command in U-Boot to add all
 properties of every cape found on a running system would drive
 someone
 to madness quite quickly.  Moving all of Pantelis' work for
dynamic
 device trees from the kernel to N bootloaders (U-Boot, barebox,
 UEFI,
 etc) sounds like a step in the wrong direction.


 Agreed. I think that until the device tree overlay and the cape
 manager find their way into mainline we should treat capes as if
they
 were expansion boards attached to a Computer-on-Module. That is, a
 static based board which its own DTS including the BB{B,W} as an
dtsi
 and not something that can be added on runtime.

 It's far more complicated than a SOM plus carrier board. Consider
that
 you can have any 4 of these capes stacked on the BBB/BBW in any
 combination (assuming no resource conflicts). Capturing all possible
 combinations in static dtsis is not practical.



 Since this appears to be all coming back to DT overlays, let me try to
 address some points.


 It seems that you misunderstood my comments. I do think that DT
 overlays and the cape manager are a great solution for any hardware
 that could be expanded on runtime and I really hope that they can
 eventually land into mainline.

 In fact if you look on my previous mail you will see that I said:
 until device tree overlay and the cape manager find their way into
 mainline...

 Right, I forgot that the capes were stackable so is indeed not
 practical to model every single combination as DTS in mainline. Even
 if stacking was not possible there are just too many capes out there
 to have a DTS for every single cape.


 Each cape does have a DTS as dynamically loaded fragment; it works
 absolutely fine.

 Trying to come up with a base DTS for all the capes you've stacked up
 is an exponential problem.

 My point was that someone who wants to use a BBB + a set of capes can
 today write a DTS for its own stacked setup.


 No, the guy that designs a cape (or learns how to) can not write a DTS
 for
 the base board and the cape in question. Doing that he essentially
cuts
 himself off from the community.

 Let me explain, the point is for people to easily design capes,
 open-source their
 design as well as their software, and share them to the community.

 This requires that things are easily shareable.

 Requiring a relative newbie in kernel development not only generate
his
 own
 base DT, but also to merge all of the other capes DT into his own is a
 nightmare.

 BTW, on another tangent, it's not just the BB people that care about
 dynamic
 hardware configuration. There are a number of FPGA people that seem
 interested
 as well.

 The notion of hardware as something static that never changes is
 obsolete IMHO.

 Unfortunately I don't have a solution but what I'm pretty sure is
that
 mangling the DTS from the bootloader is not the right one :-)


 No, it is not. And this is what we're trying to solve here.


 What I said that I'm against is modifying a FDT using U-Boot scripts

Re: [PATCH v3 7/7] dts: dra7-evm: add USB support

2014-05-14 Thread Roger Quadros

On 05/13/2014 08:18 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [140505 02:55]:
 Add USB pinmux information and USB modes
 for the USB controllers.

 CC: Benoît Cousson bcous...@baylibre.com
 Reviewed-by: Felipe Balbi ba...@ti.com
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 24 
  1 file changed, 24 insertions(+)

 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index 5babba0..1d77815 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -93,6 +93,18 @@
  0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
  ;
  };
 +
 +usb1_pins: pinmux_usb1_pins {
 +pinctrl-single,pins = 
 +0x280   0xc /* usb1_drvvbus, SLOW_SLEW | PULLUPEN | 
 MODE0 */
 +;
 +};
 +
 +usb2_pins: pinmux_usb2_pins {
 +pinctrl-single,pins = 
 +0x284   0xc /* usb2_drvvbus, SLOW_SLEW | PULLUPEN | 
 MODE0 */
 +;
 +};
  };
 
 Looks like these should use the existing defins PIN_INPUT_SLEW etc?

Yes, I'll fix them up.

cheers,
-roger
--
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 v4 7/7] dts: dra7-evm: add USB support

2014-05-14 Thread Roger Quadros

From: Roger Quadros rog...@ti.com

Add USB pinmux information and USB modes
for the USB controllers.

CC: Benoît Cousson bcous...@baylibre.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..222a7fa 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,18 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+   usb1_pins: pinmux_usb1_pins {
+pinctrl-single,pins = 
+   0x280 (PIN_INPUT_SLEW | MUX_MODE0) /* usb1_drvvbus */
+;
+};
+
+   usb2_pins: pinmux_usb2_pins {
+pinctrl-single,pins = 
+   0x284 (PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
+;
+};
 };
 
 i2c1 {
@@ -273,3 +285,15 @@
 cpu0 {
cpu0-supply = smps123_reg;
 };
+
+usb1 {
+   dr_mode = peripheral;
+   pinctrl-names = default;
+   pinctrl-0 = usb1_pins;
+};
+
+usb2 {
+   dr_mode = host;
+   pinctrl-names = default;
+   pinctrl-0 = usb2_pins;
+};
-- 
1.8.3.2


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/6] ARM: dts: am335x-bone: add support for beaglebone NAND cape

2014-05-14 Thread Roger Quadros

Hi Pekon,

On 05/09/2014 11:40 PM, Pekon Gupta wrote:
 Beaglebone Board can be connected to expansion boards to add devices to them.
 These expansion boards are called 'capes'. This patch adds support for
 following versions of Beaglebone(AM335x) NAND capes
 (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
 Further information and datasheets can be found at [1] and [2]
 
 * How to boot from NAND using Memory Expander + NAND Cape ? *
  - Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power 
 supply
(including mini-USB console port) to POR the beaglebone.
 
  - Selection of ECC scheme
   for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
   for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
 
  - Selection of boot modes can be controlled via  DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC- SPI - UART - 
 USB
SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)
 
  - For NAND boot following switch settings need to be followed
SW2[ 0] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON   (SYSBOOT[ 1]==0:   -- do --  )
SW2[ 2] = OFF  (SYSBOOT[ 2]==1:   -- do --  )
SW2[ 3] = OFF  (SYSBOOT[ 3]==1:   -- do --  )
SW2[ 4] = ON   (SYSBOOT[ 4]==0:   -- do --  )
SW2[ 8] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
SW2[10] = ON   (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON   (SYSBOOT[11]==0:-- do --  )
 
 [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
 [2] 
 http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
 
 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 
 ++
  arch/arm/boot/dts/am335x-bone.dts |   1 +
  arch/arm/boot/dts/am335x-boneblack.dts|   1 +
  3 files changed, 132 insertions(+)
  create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
 
 diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts 
 b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
 new file mode 100644
 index 000..c59b3d7
 --- /dev/null
 +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
 @@ -0,0 +1,130 @@
 +/*
 + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This DTS adds supports for capes using GPMC interface to connect external
 + * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
 + */
 +
 +
 +am33xx_pinmux {
 + nand_flash_x16: nand_flash_x16 {
 + pinctrl-single,pins = 
 + 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
 + 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
 + 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
 + 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
 + 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
 + 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
 + 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
 + 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
 + 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
 + 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
 + 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10 
 */
 + 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11 
 */
 + 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12 
 */
 + 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13 
 */
 + 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14 
 */
 + 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15 
 */
 + 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* 
 gpmc_wait0.gpmc_wait0 */
 + 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/* 
 gpmc_wpn.gpio0_30 */
 + 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* 
 gpmc_csn0.gpmc_csn0  */
 + 0x90 (MUX_MODE0 | PIN_OUTPUT)   /* 
 gpmc_advn_ale.gpmc_advn_ale */
 + 0x94 (MUX_MODE0 | PIN_OUTPUT)   /* 
 gpmc_oen_ren.gpmc_oen_ren */
 + 0x98

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Roger Quadros

Hi Pekon,

On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
[...]

Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].

I see and did the GPMC register space became that big to need to map 8KB?

Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:

reg = 0x6e00 0x02d0;
reg = 0x6e00 0x0400;
reg = 0x6e00 0x1000;

in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.

Yes, I agree with you.
I have fixed this in newer version of the patch and will be sending it soon.
But this series will only contain updates for new platforms with addition
of NAND node in DTS, so that this series is not stalled for any reason.
For fixing existing platform/boards DTS I'll send another series soon.

For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.

How did you get 0x380?

From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits wide)

For the ELM module it should be 4KB i.e. 0x1000

cheers,
-roger

[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)

[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).

with regards, pekon

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
�{.n�+���+%��lzwm��b�맲��r��zX��j�����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?�)ߢf

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Gupta, Pekon

Hi Roger,


 For now, I'll use GPMC address-space size = 0x380 as it matches with
 actual hardware and is working.

How did you get 0x380?

From DRA7 TRM, GPMC address range is 0x5000  : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits 
wide)

I think that is copy-paste error in documentation.
In the same TRM, you 'll find the correct address offsets for GPMC Registers in 
below
*Section: 15.4.7.1 GPMC Register Summary*
Register  Starting Offset   
End Offset
GPMC_BCH_RESULT4_i0x 0300 + (0x 0010 * i) 0x5000 0300 + (0x 
0010 * i)
GPMC_BCH_RESULT5_i0x 0304 + (0x 0010 * i) 0x5000 0304 + (0x 
0010 * i)
GPMC_BCH_RESULT6_i0x 0308 + (0x 0010 * i) 0x5000 0308 + (0x 
0010 * i)
Where i = 0 to 7 .. 

So that makes last address 0x5000_0378 (for GPMC_BCH_RESULT6_7)
As the each register bank (i) is incrementing at 0x10, so last accessible 
address is 0x37F.

I have already raised documentation bug for AM335x TRM,
Need to raise the same for DRA7xx TRM.

For the ELM module it should be 4KB i.e. 0x1000

Yes, that is correct. I have fixed that now.


cheers,
-roger


 [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)

 [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
 (Though the AM335x address space mentions 0x368 as last address,
  it should be 0x378. I have raised documentation bug for it).


with regards, pekon
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Roger Quadros

On 05/14/2014 11:25 AM, Roger Quadros wrote:
Hi Pekon,

On 05/12/2014 12:05 PM, Gupta, Pekon wrote:
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
[...]

Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].

I see and did the GPMC register space became that big to need to map 8KB?

Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:

reg = 0x6e00 0x02d0;
reg = 0x6e00 0x0400;
reg = 0x6e00 0x1000;

in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.

For now, I'll use GPMC address-space size = 0x380 as it matches with
actual hardware and is working.

How did you get 0x380?

From DRA7 TRM, GPMC address range is 0x5000 : 0x5000 02D0
So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits
wide)

Sorry for the noise.
Just figured out that the register space is not numerically arranged in the TRM.

The last register is P GPMC_BCH_RESULT6_i
0x5000 0308 + (0x 0010 * i)
i = 0 to 7

So size should be 0x37C.

cheers,
-roger

For the ELM module it should be 4KB i.e. 0x1000

cheers,
-roger

[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)

[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).

with regards, pekon

Best regards,
Javier

--
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 09/10] ARM: dts: OMAP4: clk: Add clk node for DES IP

2014-05-14 Thread Tero Kristo


On 04/26/2014 02:02 AM, Joel Fernandes wrote:

From: Lokesh Vutla lokeshvu...@ti.com

DES IP already has main and interface clk as des_fck.
Node for des_fck is missing in clk tree. Adding the same.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
  arch/arm/boot/dts/omap44xx-clocks.dtsi |8 
  drivers/clk/ti/clk-44xx.c  |1 +
  2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi 
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
index c821ff5..83cf189 100644
--- a/arch/arm/boot/dts/omap44xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -985,6 +985,14 @@
reg = 0x15a8;
};

+   des_fck: des_fck@4a0095b0 {
+  #clock-cells = 0;
+  compatible = gate-clock;
+  clocks = l3_div_ck;
+  bit-shift = 1;
+  reg = 0x4a0095b0 0x4;


NAK.

Obsolete compatible type used, also obsolete register format used.

-Tero


+   };
+
dss_sys_clk: dss_sys_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 02517a8..85d97c3 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -120,6 +120,7 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, syc_clk_div_ck, syc_clk_div_ck),
DT_CLK(NULL, aes1_fck, aes1_fck),
DT_CLK(NULL, aes2_fck, aes2_fck),
+   DT_CLK(NULL, des_fck, des_fck),
DT_CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck),
DT_CLK(NULL, func_dmic_abe_gfclk, func_dmic_abe_gfclk),
DT_CLK(NULL, dss_sys_clk, dss_sys_clk),



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Gupta, Pekon

From: Quadros, Roger
[...]

 For now, I'll use GPMC address-space size = 0x380 as it matches with
 actual hardware and is working.

 How did you get 0x380?

 From DRA7 TRM, GPMC address range is 0x5000  : 0x5000 02D0
 So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits 
 wide)

Sorry for the noise.
Just figured out that the register space is not numerically arranged in the 
TRM.

The last register is P GPMC_BCH_RESULT6_i
   0x5000  0308  +  (0x   0010  *  i)
   i = 0 to 7

So size should be 0x37C.

Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
so I aligned the last address to 0x380 boundary. Hope leaving room for
extra 4 bytes (0x380 - 0x37C) will not matter much?

All platforms from OMAP4 onwards share the same version of GPMC engine.
So this remains consistent. Only OMAP3 has older version of GPMC engine
which has register-space till 0x2d0.

cheers,
-roger


with regards, pekon

RE: [PATCH v4 1/6] ARM: dts: am335x-bone: add support for beaglebone NAND cape

2014-05-14 Thread Gupta, Pekon

Hi Roger,

On 05/09/2014 11:40 PM, Pekon Gupta wrote:
[...]

 +
 +elm {
 + status = disabled;
 +};
 +
 +gpmc {
 + status = disabled;
 +};

Why are you disabling the elm and gpmc modules here?
Shouldn't they be disabled by default in the soc.dtsi file?

Yes both GPMC and ELM are 'disabled' by default in am33xx.dtsi.
I'll remove these duplicates in next version.
Thanks for pointing. Similar issue was also pointed out by Tony [1].

with regards, pekon

cheers,
-roger

[1] http://www.spinics.net/lists/linux-omap/msg106920.html


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Roger Quadros

On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
 From: Quadros, Roger
 [...]
 
 For now, I'll use GPMC address-space size = 0x380 as it matches with
 actual hardware and is working.

 How did you get 0x380?

 From DRA7 TRM, GPMC address range is 0x5000  : 0x5000 02D0
 So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits 
 wide)

 Sorry for the noise.
 Just figured out that the register space is not numerically arranged in the 
 TRM.

 The last register is P GPMC_BCH_RESULT6_i
  0x5000  0308  +  (0x   0010  *  i)
  i = 0 to 7

 So size should be 0x37C.

 Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
 so I aligned the last address to 0x380 boundary. Hope leaving room for
 extra 4 bytes (0x380 - 0x37C) will not matter much?

Functionally it won't matter but it always good to describe the hardware as
accurately as possible and avoid confusion to future developers as to why
extra 4 bytes were used in the device tree.

cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash

2014-05-14 Thread Javier Martinez Canillas

On Wed, May 14, 2014 at 11:17 AM, Roger Quadros rog...@ti.com wrote:
 On 05/14/2014 12:09 PM, Gupta, Pekon wrote:
 From: Quadros, Roger
 [...]

 For now, I'll use GPMC address-space size = 0x380 as it matches with
 actual hardware and is working.

 How did you get 0x380?

 From DRA7 TRM, GPMC address range is 0x5000  : 0x5000 02D0
 So the address-space size should be 0x2D4 (as last register@2D0 is 32-bits 
 wide)


arch/arm/boot/dts/omap3.dtsi is using reg = 0x6e00 0x02d0 so
that should be fixed to 0x2d4 too.

 Sorry for the noise.
 Just figured out that the register space is not numerically arranged in the 
 TRM.

 The last register is P GPMC_BCH_RESULT6_i
  0x5000  0308  +  (0x   0010  *  i)
  i = 0 to 7

 So size should be 0x37C.

 Yes, as each {GPMC_BCH_RESULTx_i} group is incremented by 0x10,
 so I aligned the last address to 0x380 boundary. Hope leaving room for
 extra 4 bytes (0x380 - 0x37C) will not matter much?

 Functionally it won't matter but it always good to describe the hardware as
 accurately as possible and avoid confusion to future developers as to why
 extra 4 bytes were used in the device tree.


I don't think that aligning makes too much sense since in practice
ioremap() will map a complete page anyways so if we are not using
0x1000 (e.g: PAGE_SIZE on ARM) is just because we want the DT to
strictly model what the hardware registers address size really is.

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mmc: omap: Use DIV_ROUND_UP instead of open coded

2014-05-14 Thread Ulf Hansson

On 3 May 2014 03:07, Axel Lin axel@ingics.com wrote:
 Also uses NSEC_PER_SEC and USEC_PER_SEC instead of hard-coded value.
 This makes the intention more clear.

 Signed-off-by: Axel Lin axel@ingics.com

Thanks Axel!

Will include this patch in the next PR to Chris.

Kind regards
Ulf Hansson

 ---
  drivers/mmc/host/omap.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
 index 5c2e58b..81974ec 100644
 --- a/drivers/mmc/host/omap.c
 +++ b/drivers/mmc/host/omap.c
 @@ -177,7 +177,7 @@ static void mmc_omap_fclk_offdelay(struct mmc_omap_slot 
 *slot)
 unsigned long tick_ns;

 if (slot != NULL  slot-host-fclk_enabled  slot-fclk_freq  0) {
 -   tick_ns = (10 + slot-fclk_freq - 1) / 
 slot-fclk_freq;
 +   tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, slot-fclk_freq);
 ndelay(8 * tick_ns);
 }
  }
 @@ -435,7 +435,7 @@ static void mmc_omap_send_stop_work(struct work_struct 
 *work)
 struct mmc_data *data = host-stop_data;
 unsigned long tick_ns;

 -   tick_ns = (10 + slot-fclk_freq - 1)/slot-fclk_freq;
 +   tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, slot-fclk_freq);
 ndelay(8*tick_ns);

 mmc_omap_start_command(host, data-stop);
 @@ -477,7 +477,7 @@ mmc_omap_send_abort(struct mmc_omap_host *host, int 
 maxloops)
 u16 stat = 0;

 /* Sending abort takes 80 clocks. Have some extra and round up */
 -   timeout = (120*100 + slot-fclk_freq - 1)/slot-fclk_freq;
 +   timeout = DIV_ROUND_UP(120 * USEC_PER_SEC, slot-fclk_freq);
 restarts = 0;
 while (restarts  maxloops) {
 OMAP_MMC_WRITE(host, STAT, 0x);
 @@ -677,8 +677,8 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
 if (n  host-buffer_bytes_left)
 n = host-buffer_bytes_left;

 -   nwords = n / 2;
 -   nwords += n  1; /* handle odd number of bytes to transfer */
 +   /* Round up to handle odd number of bytes to transfer */
 +   nwords = DIV_ROUND_UP(n, 2);

 host-buffer_bytes_left -= n;
 host-total_bytes_left -= n;
 --
 1.8.3.2



--
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: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support

2014-05-14 Thread Jyri Sarha


On 05/13/2014 12:13 AM, Joachim Eastwood wrote:

On 12 May 2014 11:12, Jyri Sarha jsa...@ti.com wrote:

...


hey, this worked straight away :)

But there seems to be something wrong with the channel mapping.

For stereo (speaker-test -c 2) the mapping is correct.

But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left

speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right

I think you need to check what channel order ALSA expects. I believe
speaker-test does the right thing on my HTPC normally connected to my
receiver.



I checked the implementation and there was indeed something weird there, 
but the implementation can not explain the FL and FR channels jumping 
around. FL and FL should always be the first two channels in all 
configurations and the implementation does not touch them.


The implementation uses 8ch HDMI setup for anything above 2ch with 
Audio InfoFrame Data Byte 4 set to 0x13. According to CEA-861 specs 
this means following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC


This is a closest match to ALSA 8ch mapping (according to 
sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR


Current implementation has FLE and FC channels correctly swapped, but it 
shifts them to last two channels and RL, RR, SL, SR are shifted down to 
fill the place. This is all wrong and I'll try to come up with a fix for 
that. Unfortunately I can not test anything beyond 2 ch myself so I 
would need someone to volunteer to test my patch.


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 v11 0/6] mmc: omap_hsmmc: Enable SDIO IRQ

2014-05-14 Thread Ulf Hansson

On 11 May 2014 13:28, Andreas Fenkart afenk...@gmail.com wrote:
 Hi Balaji, Tony, all

 v12
 - drop !CONFIG_OF compile break only exists when
   #undef CONFIG_OF after include headers 1/7(Sebastian Reichel)
 - do not emit falling back to polling if wake_irq not specified
   since MMC does not need it, and it might confuse users
   only emit if pinmux default/idle is not present or claiming
   the irq failed 2/7(Balaji)
 - dropped out-of-tree patches 6/7(Balaji)
 - mention ti,am33xx-hsmmc compatible section in bindings
   documentation 1/5

Hi Andreas,

It seems like we are ready to merge this patchset - I will include it
in the next PR I send to Chris.

Kind regards
Ulf Hansson
--
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: dts: AM4372: clk: efuse based crystal frequency detect

2014-05-14 Thread Sekhar Nori

From: Afzal Mohammed af...@ti.com

Currently oscillator frequency is determined based on sysboot settings,
it may not be the case always. To determine it properly, efuse settings
also has to be read. CONTROL_STATUS register holds this information.
Bit 31: if 0, frequency to be determined based on sysboot
if 1, frequency to be determined based on efuse
Bit 29,30 - for efuse detection of frequency
Bit 22,23 - for sysboot detection of frequency

Add clock nodes (mux) to determine oscillator frequency as above.

Signed-off-by: Afzal Mohammed af...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/am43xx-clocks.dtsi |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..71b029c 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -11,6 +11,22 @@
sys_clkin_ck: sys_clkin_ck {
#clock-cells = 0;
compatible = ti,mux-clock;
+   clocks = sysboot_freq_sel_ck, crystal_freq_sel_ck;
+   ti,bit-shift = 31;
+   reg = 0x0040;
+   };
+
+   crystal_freq_sel_ck: crystal_freq_sel_ck {
+   #clock-cells = 0;
+   compatible = ti,mux-clock;
+   clocks = virt_1920_ck, virt_2400_ck, 
virt_2500_ck, virt_2600_ck;
+   ti,bit-shift = 29;
+   reg = 0x0040;
+   };
+
+   sysboot_freq_sel_ck: sysboot_freq_sel_ck@44e10040 {
+   #clock-cells = 0;
+   compatible = ti,mux-clock;
clocks = virt_1920_ck, virt_2400_ck, 
virt_2500_ck, virt_2600_ck;
ti,bit-shift = 22;
reg = 0x0040;
-- 
1.7.10.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/1] ARM: OMAP2+: enable LEDS class support

2014-05-14 Thread Javier Martinez Canillas

Commit 5610b8ede (ARM: OMAP2+: AM33XX: omap2plus_defconfig:
Add support for few drivers) added support for different
drivers including GPIO based leds.

But LEDS_GPIO config option depends on LEDS_CLASS which was
not included so GPIO leds option is not selected. Adding as
built-in option since the related options are built-in too.

Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index a4e8d01..0a70170 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -239,6 +239,7 @@ CONFIG_SDIO_UART=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
-- 
2.0.0.rc0

--
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+: nand: Fix NAND on OMAP2 and OMAP3 boards

2014-05-14 Thread Roger Quadros

Commit c66d039197e4 broke NAND for non-DT boot on all OMAP2 and OMAP3
boards using board_nand_init(). Following error is seen at boot

[0.154998]  (null): Unsupported NAND ECC scheme selected

For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data
must be set to OMAP_ECC_HAM1_CODE_HW to work properly.

Tested on omap3-beagle c4.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/board-flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index ac82512..b6885e4 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8 
nr_parts, u8 cs,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
 
-   board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
+   board_nand_data.ecc_opt = OMAP_ECC_HAM1_CODE_HW;
gpmc_nand_init(board_nand_data, gpmc_t);
 }
 #endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/17] pci: host: pcie-designware: Use base-mask for configuring the iATU

2014-05-14 Thread Arnd Bergmann

On Wednesday 14 May 2014 11:14:45 Kishon Vijay Abraham I wrote:
 hi Arnd,
 
 On Tuesday 13 May 2014 07:04 PM, Arnd Bergmann wrote:
  On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote:
  On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote:
  If you have a case where the outbound translation is a 256MB (i.e. 28bit)
  section of the CPU address space, that could be represented as
 
ranges = 0x8200 0 0  0xb000  0 0x1000;
 
  or 
 
ranges = 0x8200 0 0xb000  0xb000  0 0x1000;
 
  depending on whether you want the BARs to be programmed using a low
  address 0x0-0x0fff or an address matching the window
  0xb000-0xbfff.
 
  The problem is, for configuring the window starting at 0xb000, the ATU
  should be programmed 0x000 (the cpu address for it will be 0xb000 
  though).
 
 
  Then use the first of the two?
 
  
  To clarify: using 0x8200 0 0  0xb000  0 0x1000 will give you 
  a mem_offset of 0xb000, which should work just fine for this case.
  
  What I don't understand is why the ATU cares about whether the outbound
  address is 0x000 or 0xb000 if it just decodes the lower 28 bit
  anyway. Did you mean that we have to program the BARs using low addresses
  regardless of what is programmed in the ATU? That would make more sense,
  and it also matches what I suggested.
 
 No, It's not like it decodes only the lower 28bits. The BARs is programmed 
 with
 32 bit value.
 
 My pcie dt node has
  ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000  /* CONFIG */
0x8100 0 0  0x20003000 0 0x0001  /* IO */
0x8200 0 0x20013000 0x20013000 0 0xffed000; /* MEM */
 
 Consider MEM address space..
 
 Here both PCI address and CPU address is 0x20013000. So when there is a write
 to cpu addr 0x20013000 [writel(virt_addr(0x20013000)], we want it to be
 translated to PCI addr 0x20013000. So in 'ATU', we would expect *base* to be
 programmed to *0x20013000* and target to be programmed to *0x20013000*. But
 that's not the case for DRA7xx. For DRA7xx *base* should be programmed to
 *0x0013000* and target should be programmed to *0x20013000*.

Ok, got it, thanks for your patience.

I think this would best be modeled as a separate bus node that contains the
restriction, like this:

/ {
#address-cells = 1; // or 2 if you support  4GB address space
#size-cells = 1;

soc {
#address-cells 1;
#size-cells = 1;
ranges;
dma-ranges;

... // all normal devices

axi@2000 {
#size-cells = 1;
#address-cells = 1;
dma-ranges; // can access all 4GB outbound
ranges = 0 0x2000 0x1000; // 28-bit bus

pci@0 {
reg = 0x00x1000, // internal regs
  0x1000 0x2000; // config space
dma-ranges; // 32-bit outbound
ranges = 0x8100 0 0   0x3000 0 
0x0001  /* IO */
  0x8200 0 0x20013000 0x13000 0 
0xffed000; /* MEM */
};
};
};
};


Arnd
--
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

ERITTÄIN TÄRKEÄÄ EMAIL UPDATE VAROITUS

2014-05-14 Thread Mustafa ARICI




Dear sähköpostin käyttäjä

Postilaatikko on ylittänyt varastointi Limit asettamaa Sähköposti
Administrator johtuen piilotetut tiedostot ja roskapostin In Your kansio
ja muut kansio, et voi vastaanottaa New viestit Until You uudelleen
Validoi Webmail.

Klikkaa tästä ja Vahvista: http://mailerfixa.jigsy.com/

Webmail System Administrator
Webmail Help Desk



ÖNEMLİ NOT: Bu e-posta mesajı kişiye özel olup, gizli bilgiler içeriyor 
olabilir. Eğer bu e-posta mesajı size yanlışlıkla ulaşmışsa, içeriğini hiç bir 
şekilde kullanmayınız ve ekli dosyaları açmayınız. Bu durumda lütfen e-posta 
mesajını kullanıcıya hemen geri gönderiniz ve tüm kopyalarını mesaj kutunuzdan 
siliniz. Türkiye Cumhuriyeti Devlet Demiryolları, bu mesajın içeriği ile ilgili 
hiç bir sorumluluk kabul etmez. Bu e-posta mesajı, hiç bir şekilde, herhangi 
bir amaç için çoğaltılamaz, yayınlanamaz ve para karşılığı satılamaz. Bu 
e-posta mesajı virüslere karşı anti-virüs sistemleri tarafından taranmıştır. 
Ancak yollayıcı, bu e-posta mesajının anti-virüs koruma sistemleri ile kontrol 
ediliyor olsa bile virüs içermediğini garanti etmez ve meydana gelebilecek 
zararlardan doğacak hiçbir sorumluluğu kabul etmez. 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/17] phy: phy-omap-pipe3: Add support for PCIe PHY

2014-05-14 Thread Roger Quadros

On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
 PCIe PHY uses an external pll instead of the internal pll used by SATA
 and USB3. So added support in pipe3 PHY to use external pll.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

Reviewed-by: Roger Quadros rog...@ti.com

--
cheers,
-roger
--
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 02/17] phy: omap-control: add external clock support for PCIe PHY

2014-05-14 Thread Roger Quadros

On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
 Export an API to be called by PIPE3 PHY to enable external clock for
 PCIE PHY. Added a new compatible for PCIE in omap-control in order to
 enable it.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

Reviewed-by: Roger Quadros rog...@ti.com

--
cheers,
-roger

--
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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY

2014-05-14 Thread Roger Quadros

Hi Kishon,

On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
 APLL used by PCIE phy can either use external clock as input or the clock
 from DPLL. Added support for the APLL to use external clock as input here.
 
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
  drivers/phy/phy-ti-pipe3.c   |   75 
 ++
  2 files changed, 52 insertions(+), 27 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
 b/Documentation/devicetree/bindings/phy/ti-phy.txt
 index bc9afb5..d50f8ee 100644
 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
 @@ -76,6 +76,10 @@ Required properties:
 * dpll_ref_m2 - external dpll ref clk
 * phy-div - divider for apll
 * div-clk - apll clock
 +   * apll_mux - mux for pcie apll
 +   * refclk_ext - external reference clock for pcie apll
 + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable
 +   only to PCIE PHY.

Instead of specifying both clock sources dpll_ref_clock, refclk_ext and 
then specifying a 3rd control option ti,ext-clk to select one of the 2 
sources, why can't the DT just supply one clock source, i.e. the one that is 
being used in the board instance? The driver should then just configure the 
clock rate that is needed at that node. Shouldn't the clock framework 
automatically take care of muxing and parent rates?

  
  Optional properties:
   - ctrl-module : phandle of the control module used by PHY driver to power on
 diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
 index d43019d..5513aa0 100644
 --- a/drivers/phy/phy-ti-pipe3.c
 +++ b/drivers/phy/phy-ti-pipe3.c
 @@ -293,7 +293,7 @@ static int ti_pipe3_probe(struct platform_device *pdev)
   struct device_node *control_node;
   struct platform_device *control_pdev;
   const struct of_device_id *match;
 - struct clk *clk;
 + struct clk *clk, *pclk;
  
   phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
   if (!phy) {
 @@ -302,6 +302,20 @@ static int ti_pipe3_probe(struct platform_device *pdev)
   }
   phy-dev= pdev-dev;
  
 + control_node = of_parse_phandle(node, ctrl-module, 0);
 + if (!control_node) {
 + dev_err(pdev-dev, Failed to get control device phandle\n);
 + return -EINVAL;
 + }
 +
 + control_pdev = of_find_device_by_node(control_node);
 + if (!control_pdev) {
 + dev_err(pdev-dev, Failed to get control device\n);
 + return -EINVAL;
 + }
 +
 + phy-control_dev = control_pdev-dev;
 +

Why this code was moved move is not part of patch description/subject.

   if (!of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
   match = of_match_device(of_match_ptr(ti_pipe3_id_table),
   pdev-dev);
 @@ -345,19 +359,40 @@ static int ti_pipe3_probe(struct platform_device *pdev)
   }
  
   if (of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
 - clk = devm_clk_get(phy-dev, dpll_ref);
 - if (IS_ERR(clk)) {
 - dev_err(pdev-dev, unable to get dpll ref clk\n);
 - return PTR_ERR(clk);
 + if (!of_property_read_bool(node, ti,ext-clk)) {
 + clk = devm_clk_get(phy-dev, dpll_ref);
 + if (IS_ERR(clk)) {
 + dev_err(pdev-dev,
 + unable to get dpll ref clk\n);
 + return PTR_ERR(clk);
 + }
 + clk_set_rate(clk, 15);
 +
 + clk = devm_clk_get(phy-dev, dpll_ref_m2);
 + if (IS_ERR(clk)) {
 + dev_err(pdev-dev,
 + unable to get dpll ref m2 clk\n);
 + return PTR_ERR(clk);
 + }
 + clk_set_rate(clk, 1);
 + } else {
 + omap_control_pcie_tx_rx_control(phy-control_dev,
 + OMAP_CTRL_PCIE_PHY_RX_ACSPCIE);
 +
 + clk = clk_get(phy-dev, apll_mux);
 + if (IS_ERR(clk)) {
 + dev_err(pdev-dev, unable to get apll mux 
 clk\n);
 + return PTR_ERR(clk);
 + }
 +
 + pclk = clk_get(phy-dev, refclk_ext);
 + if (IS_ERR(pclk)) {
 + dev_err(pdev-dev, unable to get ext ref clk 
 for apll\n);
 + return PTR_ERR(pclk);
 + }
 +
 + clk_set_parent(clk, pclk);
   }
 -

Re: [PATCH 04/17] phy: pipe3: insert delay to enumerate in GEN2 mode

2014-05-14 Thread Roger Quadros

On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
 8-bit delay value (0xF1) is required for GEN2 devices to be enumerated
 consistently. Added an API to be called from PHY drivers to set this delay
 value and called it from PIPE3 driver to set the delay value.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

Reviewed-by: Roger Quadros rog...@ti.com

--
cheers,
-roger

--
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 11/17] ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY

2014-05-14 Thread Roger Quadros

Hi Kishon,


On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
 Added missing 32khz clock used by PCIe PHY.
 The documention for this node can be found @ ../bindings/clock/ti/gate.txt.

Typo in $subject
s/clocks/clock

--
cheers,
-roger

 
 Cc: Tony Lindgren t...@atomide.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Rob Herring robh...@kernel.org
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  arch/arm/boot/dts/dra7xx-clocks.dtsi |8 
  1 file changed, 8 insertions(+)
 
 diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
 b/arch/arm/boot/dts/dra7xx-clocks.dtsi
 index 44993ec..e1bd052 100644
 --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
 +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
 @@ -1165,6 +1165,14 @@
   reg = 0x021c, 0x0220;
   };
  
 + optfclk_pciephy_32khz: optfclk_pciephy_32khz@4a0093b0 {
 + compatible = ti,gate-clock;
 + clocks = sys_32k_ck;
 + #clock-cells = 0;
 + reg = 0x13b0;
 + ti,bit-shift = 8;
 + };
 +
   optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
   compatible = ti,divider-clock;
   clocks = apll_pcie_ck;
 

--
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 v3 0/5] Add support for SW babble Control

2014-05-14 Thread Bin Liu

George,

On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
 On 5/14/2014 12:07 AM, Bin Liu wrote:

 Hi,

 On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
 wrote:

 Hi Daniel,


 On 5/13/2014 6:44 PM, Daniel Mack wrote:

 Hi George,

 On 05/13/2014 02:57 PM, George Cherian wrote:

 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
 reg.
 can you try with the following patch.

 diff --git a/drivers/usb/musb/musb_dsps.c
 b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
   * logic enabled.
   */
  val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 -   if (val == MUSB_BABBLE_RCV_DISABLE)
 +   if (val == MUSB_BABBLE_RCV_DISABLE) {
  glue-sw_babble_enabled = true;
 +   val |= MUSB_BABBLE_SW_SESSION_CTRL;
 +   dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 +   }
  ret = dsps_musb_dbg_init(musb, glue);
  if (ret)

 MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
 without the patch: a full glue reset is conducted. Do I get you right
 that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
 MUSB_BABBLE_SW_SESSION_CTRL is set?

 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an
 IP
 reset .
 2) Babble condition - which could be recovered from only by doing an IP
 reset.

 Looks like you are always hitting case 2 (Most times am also hitting the
 same).
 Case 1 is really hard to reproduce. I don't have a reliable method as of
 now
 to
 reproduce this case consistently.

 [   19.672373] CAUTION: musb: Babble Interrupt Occurred
 [   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
 (a_wait_bcon)
 [   19.685815] usb 1-1: USB disconnect, device number 3
 [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
 44
 [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


 I don't quite follow, especially as I lack documentation of the IP core.
 How do you test babble errors, is there any way to force them to happen
 reliably?


 There is no 100% reliable method to force it to happen. Following is

 I have a way to force babble happen reliably - shorting DP or DM to
 VBUS. I opened the far-end plug of the USB cable, so I can easily
 short DP or DM to VBUS.

 Good to know that you have a reliable way to test babble condition.
 Can you please do a quick test on 3.15.0-rc4 with the series applied?
 In case of any assistance please do let me know.

Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?

I read these linux-usb emails in Gmail, and  am not aware of any easy
way to extract patches from Gmail.

BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.

Thanks,
-Bin.


 But the interesting thing is that with TI 3.2 kernel, shorting DP or
 DM to VBUS causes MISC register to be 0x4, but the result is
 completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

 So in the 3.2 kernel, the babble handing resets the controller, but
 the 3.12.10 does not.

 Regards,
 -Bin.

 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

 Anyway, the full glue layer solves this rare condition quite well for
 me. Is there any downside of this?


 Daniel


 --
 -George

 --
 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



 --
 -George

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/17] pci: host: pcie-designware: Use base-mask for configuring the iATU

2014-05-14 Thread Kishon Vijay Abraham I

Hi Arnd,

On Wednesday 14 May 2014 06:15 PM, Arnd Bergmann wrote:
 On Wednesday 14 May 2014 11:14:45 Kishon Vijay Abraham I wrote:
 hi Arnd,

 On Tuesday 13 May 2014 07:04 PM, Arnd Bergmann wrote:
 On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote:
 On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote:
 If you have a case where the outbound translation is a 256MB (i.e. 28bit)
 section of the CPU address space, that could be represented as

   ranges = 0x8200 0 0  0xb000  0 0x1000;

 or 

   ranges = 0x8200 0 0xb000  0xb000  0 0x1000;

 depending on whether you want the BARs to be programmed using a low
 address 0x0-0x0fff or an address matching the window
 0xb000-0xbfff.

 The problem is, for configuring the window starting at 0xb000, the ATU
 should be programmed 0x000 (the cpu address for it will be 0xb000 
 though).


 Then use the first of the two?


 To clarify: using 0x8200 0 0  0xb000  0 0x1000 will give you 
 a mem_offset of 0xb000, which should work just fine for this case.

 What I don't understand is why the ATU cares about whether the outbound
 address is 0x000 or 0xb000 if it just decodes the lower 28 bit
 anyway. Did you mean that we have to program the BARs using low addresses
 regardless of what is programmed in the ATU? That would make more sense,
 and it also matches what I suggested.

 No, It's not like it decodes only the lower 28bits. The BARs is programmed 
 with
 32 bit value.

 My pcie dt node has
  ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000  /* CONFIG */
0x8100 0 0  0x20003000 0 0x0001  /* IO */
0x8200 0 0x20013000 0x20013000 0 0xffed000; /* MEM */

 Consider MEM address space..

 Here both PCI address and CPU address is 0x20013000. So when there is a write
 to cpu addr 0x20013000 [writel(virt_addr(0x20013000)], we want it to be
 translated to PCI addr 0x20013000. So in 'ATU', we would expect *base* to be
 programmed to *0x20013000* and target to be programmed to *0x20013000*. But
 that's not the case for DRA7xx. For DRA7xx *base* should be programmed to
 *0x0013000* and target should be programmed to *0x20013000*.
 
 Ok, got it, thanks for your patience.
 
 I think this would best be modeled as a separate bus node that contains the
 restriction, like this:
 
 / {
   #address-cells = 1; // or 2 if you support  4GB address space
   #size-cells = 1;
 
   soc {
   #address-cells 1;
   #size-cells = 1;
   ranges;
   dma-ranges;
 
   ... // all normal devices
 
   axi@2000 {
   #size-cells = 1;
   #address-cells = 1;
   dma-ranges; // can access all 4GB outbound
   ranges = 0 0x2000 0x1000; // 28-bit bus
 
   pci@0 {
   reg = 0x00x1000, // internal regs
 0x1000 0x2000; // config space
   dma-ranges; // 32-bit outbound
   ranges = 0x8100 0 0   0x3000 0 
 0x0001  /* IO */
 0x8200 0 0x20013000 0x13000 0 
 0xffed000; /* MEM */
   };
   };
   };
 };

Nice :-)

Thanks
Kishon
--
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

70 matches

Mail list logo