Re: [GIT PULL] omap dts changes for v3.17 merge window, part1

[Tony Lindgren]

* Olof Johansson o...@lixom.net [140718 22:17]:
 On Wed, Jul 16, 2014 at 05:55:58AM -0700, Tony Lindgren wrote:
  The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
  
Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
  
  are available in the git repository at:
  
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
  tags/omap-for-v3.17/dt-part1
  
  for you to fetch changes up to 3c9464ed75d6c15ee864da6d8f6a4cd3b0f2c934:
  
ARM: DTS: omap5-uevm: Enable basic audio (McPDM - twl6040) (2014-07-15 
  00:21:25 -0700)
  
  
  First set of .dts changes for omaps for v3.17 merge
  window:
  
  - Enable irqchip crossbar interrupt mapping. These changes
are based on an immutable irqchip branch set up by Jason
Cooper to make it easier to merge the related .dts changes.
  
  - Removal of omap2 related static clock data that now comes
from device tree.
  
  - Enabling of PHY regulators for various omaps
  
  - Enabling of PCIe for dra7
  
  - Add support for am437x starterkit
  
  - Enable audio for for omap5
  
  - Enable display and am335x-evmsk
 
 Merged, but:
 
 1) There was a conflict in the qspi node of dra7.dtsi due to a fix to
remove the interrupts property. It'd be nice to get these branches
based on the fixes so that we don't see these conflicts (or at least
get told about them). Besides, if we happen to have an older base in
our branch than what had the fix, it'll bubble all the way up to Linus.
 
 2) There was an add/add conflict in the dra7.dtsi file, due to new
entries just being appended. Please keep these sorted on address to
avoid that.

OK thanks. This was still based on -rc1, I'll use a later base
in the future if needed to avoid pointless merge conflicts.

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: [v3 PATCH 2/6] dt: TI: Describe the ti reset DT entries

[Tony Lindgren]

* Dan Murphy dmur...@ti.com [140717 09:47]:
 +
 +example:
 + prm: prm@4ae06000 {
 + compatible = ti,omap5-prm;
 + reg = 0x4ae06000 0x3000;
 +
 + prm_resets: resets {
 + #address-cells = 1;
 + #size-cells = 1;
 + #reset-cells = 1;
 + };
 + };

Probably the way to go with mapping various PRCM registers to separate
drivers is to provide one or more syscon entries like we already have
for the SCM. You may want to coordinate this with Tero.

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: AM3517 fails to boot 3.16-rc5 device tree kernel

[Tony Lindgren]

* Michael Welling mwell...@emacinc.com [140718 07:42]:
 On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote:
 
  Hmm maybe double check your're booting device tree based kernel
  instead of legacy machine ID based kernel? The legacy booting should
  still work just fine and no changes has been made to it, but it will
  get removed shortly.

 I downloaded the version from the test results and it did boot.

OK that's good to hear.

 These are combining the uImage and dtb. How do you accomplish this?

You need to make sure you have the appended DTB support enabled like
we do in omap2plus_defconfig:

CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

Then just cat zImage board.dtb  /tmp/zImage-dtba and run
mkimage to convert it to a uImage:

$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
-n Linux -d /tmp/zImage-dtba /tmp/uImage

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: AM3517 fails to boot 3.16-rc5 device tree kernel

[Tony Lindgren]

* Michael Welling mwell...@emacinc.com [140718 08:05]:
 On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote:
  On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote:
  
   Can you please enable debug_ll + earlyprintk and pass also earlyprintk
   in the kernel cmdline?
  I will try this.
 
 Adding the earlyprintk did not work. It still hangs without any
 messages.

If you have it enabled for the wrong UART it will always hang..
Maybe check you have the right port? 

   Hmm maybe double check your're booting device tree based kernel
   instead of legacy machine ID based kernel? The legacy booting should
   still work just fine and no changes has been made to it, but it will
   get removed shortly.
 
 How do you determine which you are booting?

Looking at the dmesg, the earliest point you'll see it is from
Machine model:  line, that's most likely different than for
legacy booting :)

And later on you'll see some DT only drivers get initialized
properly like pinctrl-single:

pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568
...

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: AM3517 fails to boot 3.16-rc5 device tree kernel

[Tony Lindgren]

* Michael Welling mwell...@emacinc.com [140718 09:15]:
 On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote:
  On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote:
   * mwelling mwell...@emacinc.com [140717 16:42]:
   I am in the process of porting a device tree compatible version of the
   linux kernel to a AM3517 based device.
  
   First I tried 3.10.x and the device tree port appeared to be incomplete.
   Neither the LCD or Ethernet were supported.
  
   Next I tried 3.14.x and the Ethernet driver appeared to work but still
   no LCD support.
  
   Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot
   without any messages from the serial COM.
  
   For device tree based booting on omap3 I would user v.16-rc4 or later.
   There have been multiple issues fixed over past year and PM is working
   finally at least for 36xx/37xx. And we do have the DSS panels finally
   working too.
  
   I was using the omap2plus_defconfig and the am3517-evm.dtb from each
   kernel build. Is there any reason why the kernel would start hanging
   with the newest release?
  
   No reason that I can think of. AFAIK 3517 has been booting in the test
   farms just fine?
  
   Can you please enable debug_ll + earlyprintk and pass also earlyprintk
   in the kernel cmdline?
  I will try this.
  
   Are there any versions where the LCD output works?
  
   Starting with v3.16-rc1 you should get the LCD working for panel-dpi
   based devices. Most of them actually are actually ls037v3dw01, so
   see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi
   variants if you have similar setup.
  
   Looking at the 3.16-rc5 test results just posted it is supposed to be 
   working
   but I have not been able to replicate this.
  
   Any suggestions would be greatly appreciated.
  
   Hmm maybe double check your're booting device tree based kernel
   instead of legacy machine ID based kernel? The legacy booting should
   still work just fine and no changes has been made to it, but it will
   get removed shortly.
  I downloaded the version from the test results and it did boot.
  These are combining the uImage and dtb. How do you accomplish this?
 
 It should be noted that when you try to boot the seperate zImage and dtb from
 the test build it fails. This replicates my issue.
 
 Here are the two binaries that I used:
 http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/build_z/omap2plus_defconfig/zImage
 http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/dtbs/am3517-evm.dtb
 
 Here is the boot attempt:
 U-Boot dhcp;set serverip 10.0.2.168;tftp 0x8200 zImage; tftp 0x8000 
 am3517-evm.dtb;bootz 0x8200 - 0x8000
 BOOTP broadcast 1
 DHCP client bound to address 10.0.3.33
 Using DaVinci-EMAC device
 TFTP from server 10.0.2.168; our IP address is 10.0.3.33
 Filename 'zImage'.
 Load address: 0x8200
 Loading: #
  #
  #
  #
  ##
  2 MiB/s
 done
 Bytes transferred = 4360800 (428a60 hex)
 Using DaVinci-EMAC device
 TFTP from server 10.0.2.168; our IP address is 10.0.3.33
 Filename 'am3517-evm.dtb'.
 Load address: 0x8000
 Loading: 
  1.8 MiB/s
 done
 Bytes transferred = 50145 (c3e1 hex)
 Kernel image @ 0x8200 [ 0x00 - 0x428a60 ]
 ## Flattened Device Tree blob at 8000
Booting using the fdt blob at 0x8000
Loading Device Tree to 9ff05000, end 9ff143e0 ... OK
 
 Starting kernel ...
 
 Using the exact same boot sequence worked for 3.10 and 3.14.

Hmm maybe we still have some relocation issues left and the kernel
or the .dtb size has changed enough to cause trouble. Can you
try with .dtb at a different address?

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: [GIT PULL] ARM: OMAP2+: clock cleanup for 3.17

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [140717 11:20]:
 Hi Tony,
 
 The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
 
   Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/for-v3.17/omap-clock-a
 
 for you to fetch changes up to acd052bb8119dd9117e0af48ff0ac6e56e61b6b4:
 
   ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file 
 (2014-07-15 14:09:24 -0600)
 
 
 An OMAP clock cleanup series for 3.17 from Tero Kristo.
 This is in preparation for moving this code into drivers/clk/ti.
 
 Basic build, boot, and PM test logs are here:
 
 http://www.pwsan.com/omap/testlogs/clock-a-v3.17/20140717034329/

Thanks pulling into omap-for-v3.17/soc.

Regards,

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

Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver

[Tony Lindgren]

* Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]:
 Hi Suman, Joerg and Tony,
 
 On Friday 18 July 2014 11:53:56 Suman Anna wrote:
  On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
   Hello,
   
   The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is
   has been ported to the DMA API, remove the unused virtual memory manager.
   
   The removal is split in three patches to ease upstream merge. The first
   patch removes the omap-iovmm driver, the second patch removes setting of
   now unused platform data fields from arch code, and the last patch cleans
   up the platform data structure.
  
  Thanks for the revised series, it looks good. I have also tested the
  series on OMAP3, OMAP4 and OMAP5.
  
  For the changes in the entire series,
  Acked-by: Suman Anna s-a...@ti.com
 
 Thank you.
 
   I'd like to get at least the first patch merged in v3.17. To avoid
   splitting the series across three kernel versions, it would be nice to
   also merge at least the second patch for v3.17. If there's no risk of
   conflict everything could be merged in one go through the ARM SoC tree.
   Otherwise a stable branch with patch 1/3 will be needed to base the arch
   change on.
   
   Joerg, Tony, how would you like to proceed ?
 
 The v3.17 merge window is getting close, it's probably too late to merge 
 patch 
 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3 and 3/3 
 would then get in v3.18. Tony, how would you like to proceed for those ?

How about Joerg maybe do an immutable branch against v3.16-rc1
with just these three patches and merge it into your tree?

That way I too can merge the minimal branch in if there are conflics.
If that works for Joerg, then for arch/arm/*omap* changes:

Acked-by: Tony Lindgren t...@atomide.com

If the above is too complicated, then how about Laurent resend patches
2 - 3 once the dependencies have cleared so I can pick them up. This
is assuming nothing breaks with patchs 2 - 3 missing naturally :)

Regards,

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

Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [140717 23:28]:
 * Sebastian Andrzej Siewior bige...@linutronix.de [140717 03:09]:
  On 07/17/2014 10:12 AM, Tony Lindgren wrote:
   Hmm it could be that it works for a while because the clocks are on
   from the bootloader and pm_runtime calls won't do anything. This
   could happen if the interconnect data based on the ti,hwmods entry
   is not getting matched to the new driver. This gets initialized when
   the device entry gets created in omap_device_build_from_dt().
   
   Or maybe something now affects the clock aliases? It seems that we
   are still missing the clocks entries in the .dtsi files, see the
   mappings with $ git grep uart drivers/clk/ti/
  
  I've been looking for something completely different while I noticed
  this:
  
  in drivers/tty/serial/omap-serial.c
  | static struct platform_driver serial_omap_driver = {
  | .driver = {
  | .name   = DRIVER_NAME,
  | },
  | };
  |
  
  and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h
  Looking further, I've found arch/arm/mach-omap2/serial.c:
  | void __init omap_serial_init_port(struct omap_board_data *bdata,
  | struct omap_uart_port_info *info)
  | {
  | char *name
  …
  |   name = DRIVER_NAME;
  …
  |   pdev = omap_device_build(name, uart-num, oh, pdata, pdata_size);
  …
  |
  
  Would this explain it?
 
 That would explain it for legacy booting, but not for device tree
 based booting. I can try to debug it further on Monday.

Looks like the following is needed to avoid the error, no idea why..
But this is what we also do in omap-serial.c. It may be needed in
other places too?

Also, no luck yet on runtime PM. If the console is enabled omap won't
idle, and if no serial console is enabled, it just hangs. Will try
to debug this part further, it may be also related to the above.

Regards,

Tony

--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2066,8 +2066,8 @@ int serial8250_do_startup(struct uart_port *port)
/*
 * Clear the interrupt registers.
 */
-   serial_port_in(port, UART_LSR);
-   serial_port_in(port, UART_RX);
+   if (serial_port_in(port, UART_LSR)  UART_LSR_DR)
+   serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
 
@@ -2228,8 +2228,8 @@ dont_test_tx_en:
 * saved flags to avoid getting false values from polling
 * routines or the previous session.
 */
-   serial_port_in(port, UART_LSR);
-   serial_port_in(port, UART_RX);
+   if (serial_port_in(port, UART_LSR)  UART_LSR_DR)
+   serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
up-lsr_saved_flags = 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 3/7] ARM: OMAP4+: PRM: remove wkup event

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140605 20:37]:
 wkup event at bit offset 0 exists only on OMAP3.
 OMAP4430/60 PRM_IRQSTATUS_A9, OMAP5/DRA7 PRM_IRQSTATUS_MPU
 
 register bit 0 is DPLL_CORE_RECAL_ST not wakeup event like OMAP3.

Hmm so why was it added originally then?

Do the PRM_IRQSTATUS line and the following line belong together
or is it missing something?

Regards,

Tony
 
 The same applies to AM437x as well.
 
 Remove the wrong definition.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/prm44xx.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
 index d4d745e..1ecf244 100644
 --- a/arch/arm/mach-omap2/prm44xx.c
 +++ b/arch/arm/mach-omap2/prm44xx.c
 @@ -32,7 +32,6 @@
  /* Static data */
  
  static const struct omap_prcm_irq omap4_prcm_irqs[] = {
 - OMAP_PRCM_IRQ(wkup,   0,  0),
   OMAP_PRCM_IRQ(io, 9,  1),
  };
  
 -- 
 1.7.9.5
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140605 20:37]:
 Allow the PRM interrupt information to be picked up from device tree.
 the only exception is for OMAP4 which uses values pre-populated and allows
 compatibility with older dtb.
 
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  arch/arm/mach-omap2/prm44xx.c |   41 
 +
  1 file changed, 41 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
 index 1ecf244..784b3e1 100644
 --- a/arch/arm/mach-omap2/prm44xx.c
 +++ b/arch/arm/mach-omap2/prm44xx.c
 @@ -17,6 +17,7 @@
  #include linux/errno.h
  #include linux/err.h
  #include linux/io.h
 +#include linux/of_irq.h
  
  
  #include soc.h
 @@ -698,11 +699,51 @@ int __init omap44xx_prm_init(void)
   return prm_register(omap44xx_prm_ll_data);
  }
  
 +static struct of_device_id omap_prm_dt_match_table[] = {
 + { .compatible = ti,omap4-prm },
 + { .compatible = ti,omap5-prm },
 + { .compatible = ti,dra7-prm },
 + { }
 +};
 +

I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?

Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?

That would allow further work later on to remove the auxdata
dependencies possibly.

Regards,

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

Re: [PATCH 1/8] ARM: OMAP2+: timer: Add a powerup function

[Tony Lindgren]

* Joel Fernandes jo...@ti.com [140422 18:27]:
 In an effort to isolate the time power initialization for future purposes, add
 a function to do the same. This primarily involves a hwmod lookup, setup and
 enable.

No users yet for this function? Can you remove the same code from
somewhere else in this patch?

Regards,

Tony
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/timer.c |   25 +
  1 file changed, 25 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index dfb19df..ec427e6 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -210,6 +210,31 @@ static void __init omap_dmtimer_init(void)
   }
  }
  
 +int __init omap_dmtimer_powerup(struct device_node *np)
 +{
 + struct omap_hwmod *oh;
 + const char *oh_name = NULL;
 + int ret;
 +
 + of_property_read_string_index(np, ti,hwmods, 0, oh_name);
 + if (!oh_name)
 + return -ENODEV;
 +
 + oh = omap_hwmod_lookup(oh_name);
 + if (!oh)
 + return -ENODEV;
 +
 + ret = omap_hwmod_setup_one(oh_name);
 + if (ret)
 + return ret;
 +
 + ret = omap_hwmod_enable(oh);
 + if (ret)
 + return ret;
 +
 + return 0;
 +}
 +
  /**
   * omap_dm_timer_get_errata - get errata flags for a timer
   *
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] ARM: OMAP2+: timer: Simplify clock event/source name setting

[Tony Lindgren]

* Joel Fernandes jo...@ti.com [140422 18:27]:
 For the OMAPs, we're setting up only one clockevent and clocksource. Further,
 for DT boot there's no easy way to get the timer name and currently this is
 done in an ugly way by reading a hwmod entry. So let's just set it to a 
 simpler
 name like timer_clkev and timer_clksrc.
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/timer.c |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index ec427e6..f192a41 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -251,7 +251,6 @@ static u32 __init omap_dm_timer_get_errata(void)
  static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
const char *fck_source,
const char *property,
 -  const char **timer_name,
int posted)
  {
   char name[10]; /* 10 = sizeof(gptXX_Xck0) */
 @@ -290,8 +289,6 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
   if (!oh)
   return -ENODEV;
  
 - *timer_name = oh-name;
 -
   if (!of_have_populated_dt()) {
   r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
  irq);
 @@ -365,8 +362,10 @@ static void __init omap2_gp_clockevent_init(int 
 gptimer_id,
*/
   __omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
  
 + clockevent_gpt.name = timer_clkev;
 +
   res = omap_dm_timer_init_one(clkev, fck_source, property,
 -  clockevent_gpt.name, OMAP_TIMER_POSTED);
 +  OMAP_TIMER_POSTED);
   BUG_ON(res);
  
   omap2_gp_timer_irq.dev_id = clkev;
 @@ -489,10 +488,11 @@ static void __init omap2_gptimer_clocksource_init(int 
 gptimer_id,
   clksrc.errata = omap_dm_timer_get_errata();
  
   res = omap_dm_timer_init_one(clksrc, fck_source, property,
 -  clocksource_gpt.name,
OMAP_TIMER_NONPOSTED);
   BUG_ON(res);
  
 + clocksource_gpt.name = timer_clksrc;
 +
   __omap_dm_timer_load_start(clksrc,
  OMAP_TIMER_CTRL_AR, 0,
  OMAP_TIMER_NONPOSTED);

Hmm aren't we losing information now about which timer we are using?

Might be worth checking if these new names are getting copied somewhere
or what happens after init?

Regards,

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

Re: [PATCH 3/8] ARM: OMAP2+: timer: Add comment on timer clk parenting

[Tony Lindgren]

* Joel Fernandes jo...@ti.com [140422 18:27]:
 Add a comment describing the state of system timer clock parenting.  The code
 following the comment should be deleted once all platforms can do DT boot, and
 specially should not be executed for DT platforms once we can specify default
 clock parents through DT.

I think we can do it already for DT based booting?

Regards,

Tony
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/timer.c |4 
  1 file changed, 4 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index f192a41..9fdff5b 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -313,6 +313,10 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
   if (IS_ERR(timer-fclk))
   return PTR_ERR(timer-fclk);
  
 + /*
 +  * Clock reparenting code, goes away for DT-boot atleast,
 +  * once clock layer can do it through DT.
 +  */
   src = clk_get(NULL, fck_source);
   if (IS_ERR(src))
   return PTR_ERR(src);
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/8] ARM: OMAP2+: timer: Fix error message to not use hwmod structure

[Tony Lindgren]

* Joel Fernandes jo...@ti.com [140422 18:27]:
 oh-name is no longer used, correct the error message.

I guess this error is created by one of the patchs in this
series? So maybe fold it into the patch creating this error?

Regards,

Tony
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/timer.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 4fcfd7a..519ccfd 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -331,8 +331,8 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
   if (clk_get_parent(timer-fclk) != src) {
   r = clk_set_parent(timer-fclk, src);
   if (r  0) {
 - pr_warn(%s: %s cannot set source\n, __func__,
 - oh-name);
 + pr_warn(%s: cannot set timer's source\n, __func__);
 + WARN_ON(1);
   clk_put(src);
   return r;
   }
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/8] ARM: OMAP2+: timer: Add fallback for of_clk_get

[Tony Lindgren]

* Joel Fernandes jo...@ti.com [140422 18:27]:
 Not all platforms currently will support of_clk_get on timer
 because they may not have clock property in their DT nodes. Add
 code to handle this case so that things are kept working. Finally
 we can delete this code once all system timer nodes have a clock
 property.

I think this needs updating now too? Might be best to fix the
platforms that don't have clocks available yet via DT instead :)

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: [RFC PATCH 3/7] ARM: OMAP4+: PRM: remove wkup event

[Nishanth Menon]

On Mon, Jul 21, 2014 at 5:44 AM, Tony Lindgren t...@atomide.com wrote:

 Hmm so why was it added originally then?

 Do the PRM_IRQSTATUS line and the following line belong together
 or is it missing something?


Seems like to have been a copy paste from OMAP3 code which did have
wakeup event at bit 0.

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

Re: [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

[Nishanth Menon]

On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren t...@atomide.com wrote:

 +static struct of_device_id omap_prm_dt_match_table[] = {
 + { .compatible = ti,omap4-prm },
 + { .compatible = ti,omap5-prm },
 + { .compatible = ti,dra7-prm },
 + { }
 +};
 +

 I'd like to avoid adding more driver like stuff to mach-omap2
 and parsing compatible flags and dealing with interupts sounds
 very driver like.. But maybe just the handling can be moved
 out?

I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.

 Would a simple driver be doable that parses the compatible
 flags, takes care of the IRQ chaining, and gets some SoC specific
 function pointers as auxdata?

Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.


 That would allow further work later on to remove the auxdata
 dependencies possibly.




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

Re: [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140721 04:24]:
 On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren t...@atomide.com wrote:
 
  +static struct of_device_id omap_prm_dt_match_table[] = {
  + { .compatible = ti,omap4-prm },
  + { .compatible = ti,omap5-prm },
  + { .compatible = ti,dra7-prm },
  + { }
  +};
  +
 
  I'd like to avoid adding more driver like stuff to mach-omap2
  and parsing compatible flags and dealing with interupts sounds
  very driver like.. But maybe just the handling can be moved
  out?
 
 I understand your view, but, Handling of interrupts is already in
 place even now in mach-omap2. Currently the prm devices are handled by
 mach-omap2 and all this does it to prevent hardcoding of irq numbers
 within the current code.

Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.

  Would a simple driver be doable that parses the compatible
  flags, takes care of the IRQ chaining, and gets some SoC specific
  function pointers as auxdata?
 
 Tero has been trying to move PRM/CM stuff to a separate drivers of
 thier own. With that there wont be a need for auxdata even. - this
 current logic will get merged with that driver - if and when that is
 ready. I am not actually adding any driver logic here - just reusing
 the logic and providing glue for using dt description instead of
 hardcoded logic that the current mach-omap2 driver does.

Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?

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: [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

[Nishanth Menon]

On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren t...@atomide.com wrote:
 * Nishanth Menon n...@ti.com [140721 04:24]:
 On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren t...@atomide.com wrote:
 
  +static struct of_device_id omap_prm_dt_match_table[] = {
  + { .compatible = ti,omap4-prm },
  + { .compatible = ti,omap5-prm },
  + { .compatible = ti,dra7-prm },
  + { }
  +};
  +
 
  I'd like to avoid adding more driver like stuff to mach-omap2
  and parsing compatible flags and dealing with interupts sounds
  very driver like.. But maybe just the handling can be moved
  out?

 I understand your view, but, Handling of interrupts is already in
 place even now in mach-omap2. Currently the prm devices are handled by
 mach-omap2 and all this does it to prevent hardcoding of irq numbers
 within the current code.

 Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
 that SoC specific data around until a driver can deal with it
 in a standard way.

  Would a simple driver be doable that parses the compatible
  flags, takes care of the IRQ chaining, and gets some SoC specific
  function pointers as auxdata?

 Tero has been trying to move PRM/CM stuff to a separate drivers of
 thier own. With that there wont be a need for auxdata even. - this
 current logic will get merged with that driver - if and when that is
 ready. I am not actually adding any driver logic here - just reusing
 the logic and providing glue for using dt description instead of
 hardcoded logic that the current mach-omap2 driver does.

 Well how about let's just leave out the non-standard parts for
 now, then once the PRM/CM driver can deal with, it can do things
 in a normal way?

Broken PRCM interrupt handling for DRA7. but if you like to state
which parts are ok, I can probably repost with just those and leave
the rest for when ever PRM / CM driver happens to work out (and as a
result keep DRA7 daisy chain support broken till then - so probably
blocking low power features such as suspend-to-ram till that work is
complete.).

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

[GIT PULL] omap soc clean-up for v3.17 merge window

[Tony Lindgren]

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.17/soc-cleanup

for you to fetch changes up to 3db53918e306d3960bf9e12eea8b2fd3f7d0fd62:

  Merge tag 'for-v3.17/omap-clock-a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into 
omap-for-v3.17/soc (2014-07-21 00:35:38 -0700)



SoC specific omap clean-up for v3.17 merge window:

- Changes to PRM and clock related code to help move
  things to drivers

- Removal of unused ctrl module defines that no longer
  are needed with things moving to .dts files and
  drivers


Joachim Eastwood (1):
  ARM: OMAP4: Ctrl module register define diet

Tero Kristo (22):
  ARM: OMAP3: PRM: move prcm wakeup helper to prm driver
  ARM: OMAP3: PRM: move iva reset to PRM driver
  ARM: OMAP3: PRM: move modem reset to PRM driver
  ARM: OMAP3: PRM: add API for checking and clearing cold reset status
  ARM: OMAP3: PRM: add API for saving PRM scratchpad contents
  ARM: OMAP24xx: PRM: add API for clearing wakeup status bits
  ARM: OMAP3: PRM: move PRM init code from PM core to the driver
  ARM: OMAP3: control: add API for setting up the modem pads
  ARM: OMAP3: PRM: move modem reset and iva2 idle to PRM driver
  ARM: OMAP3: control: isolate control module init to its own function
  ARM: OMAP4+: clock: remove DEFINE_CLK_OMAP_HSDIVIDER macro
  ARM: OMAP4+: dpll: remove cpu_is_omap44xx checks
  ARM: OMAP4+: dpll44xx: remove cm-regbits-44xx.h and clock44xx.h includes
  ARM: OMAP2+: clock: introduce ti_clk_features flags
  ARM: OMAP2+: clock: add fint values to the ti_clk_features struct
  ARM: OMAP2+: clock/dpll: add private API for checking if DPLL is in bypass
  ARM: OMAP2+: clock/dpll: convert bypass check to use clk_features
  ARM: OMAP2+: clock/dpll: add jitter correction behind clk_features
  ARM: OMAP2+: clock/interface: add a clk_features definition for idlest 
value
  ARM: OMAP2+: clock/dpll: remove unused header includes from clkt_dpll.c
  ARM: OMAP2+: clock/dpll: remove unused header includes from dpll3xxx.c
  ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file

Tony Lindgren (2):
  Merge branch 'for-v3.17/cm-prm-cleanup' of 
https://github.com/t-kristo/linux-pm into omap-for-v3.17/soc
  Merge tag 'for-v3.17/omap-clock-a' of 
git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.17/soc

 arch/arm/mach-omap2/clkt_dpll.c |   98 +-
 arch/arm/mach-omap2/clkt_iclk.c |8 +-
 arch/arm/mach-omap2/clock.c |   76 +-
 arch/arm/mach-omap2/clock.h |   44 +-
 arch/arm/mach-omap2/control.c   |   60 +-
 arch/arm/mach-omap2/control.h   |   40 +-
 arch/arm/mach-omap2/ctrl_module_core_44xx.h |  392 ---
 arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h | 1409 ---
 arch/arm/mach-omap2/ctrl_module_pad_wkup_44xx.h |  236 
 arch/arm/mach-omap2/dpll3xxx.c  |7 +-
 arch/arm/mach-omap2/dpll44xx.c  |   19 +-
 arch/arm/mach-omap2/io.c|2 +
 arch/arm/mach-omap2/pm24xx.c|   31 +-
 arch/arm/mach-omap2/pm34xx.c|  218 +---
 arch/arm/mach-omap2/prm2xxx.c   |   18 +
 arch/arm/mach-omap2/prm2xxx.h   |1 +
 arch/arm/mach-omap2/prm3xxx.c   |  233 
 arch/arm/mach-omap2/prm3xxx.h   |6 +
 18 files changed, 516 insertions(+), 2382 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/ctrl_module_core_44xx.h
 delete mode 100644 arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h
 delete mode 100644 arch/arm/mach-omap2/ctrl_module_pad_wkup_44xx.h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140721 05:11]:
 On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren t...@atomide.com wrote:
  * Nishanth Menon n...@ti.com [140721 04:24]:
  On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren t...@atomide.com wrote:
  
   +static struct of_device_id omap_prm_dt_match_table[] = {
   + { .compatible = ti,omap4-prm },
   + { .compatible = ti,omap5-prm },
   + { .compatible = ti,dra7-prm },
   + { }
   +};
   +
  
   I'd like to avoid adding more driver like stuff to mach-omap2
   and parsing compatible flags and dealing with interupts sounds
   very driver like.. But maybe just the handling can be moved
   out?
 
  I understand your view, but, Handling of interrupts is already in
  place even now in mach-omap2. Currently the prm devices are handled by
  mach-omap2 and all this does it to prevent hardcoding of irq numbers
  within the current code.
 
  Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
  that SoC specific data around until a driver can deal with it
  in a standard way.
 
   Would a simple driver be doable that parses the compatible
   flags, takes care of the IRQ chaining, and gets some SoC specific
   function pointers as auxdata?
 
  Tero has been trying to move PRM/CM stuff to a separate drivers of
  thier own. With that there wont be a need for auxdata even. - this
  current logic will get merged with that driver - if and when that is
  ready. I am not actually adding any driver logic here - just reusing
  the logic and providing glue for using dt description instead of
  hardcoded logic that the current mach-omap2 driver does.
 
  Well how about let's just leave out the non-standard parts for
  now, then once the PRM/CM driver can deal with, it can do things
  in a normal way?
 
 Broken PRCM interrupt handling for DRA7. but if you like to state
 which parts are ok, I can probably repost with just those and leave
 the rest for when ever PRM / CM driver happens to work out (and as a
 result keep DRA7 daisy chain support broken till then - so probably
 blocking low power features such as suspend-to-ram till that work is
 complete.).

Well if Tero is fine with this approach, looks OK for me. At least
the .dts entries should work in the long run.

Regards,

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

Re: [PATCH 3/6] tty: serial: 8250 core: add runtime pm

[Mika Westerberg]

On Wed, Jul 09, 2014 at 07:49:34PM +0200, Sebastian Andrzej Siewior wrote:
 While comparing the OMAP-serial and the 8250 part of this I noticed that
 the the latter does not use runtime-pm. Here are the pieces. It is
 basically a get before first register access and a last_busy + put after
 last access.
 If I understand this correct, it should do nothing as long as
 pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
 device.
 
 Cc: mika.westerb...@linux.intel.com

Sorry for the delay, just came back from vacation.

Adding Heikki, who knows the 8250_dw driver much better than me.
Unfortunately he is still on vacation for next two weeks.

 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/tty/serial/8250/8250_core.c | 101 
 +++-
  1 file changed, 88 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index d37eb08..1a91a89 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -38,6 +38,7 @@
  #include linux/nmi.h
  #include linux/mutex.h
  #include linux/slab.h
 +#include linux/pm_runtime.h
  #ifdef CONFIG_SPARC
  #include linux/sunserialcore.h
  #endif
 @@ -553,10 +554,11 @@ static void serial8250_set_sleep(struct uart_8250_port 
 *p, int sleep)
* offset but the UART channel may only write to the corresponding
* bit.
*/
 + pm_runtime_get_sync(p-port.dev);
   if ((p-port.type == PORT_XR17V35X) ||
  (p-port.type == PORT_XR17D15X)) {
   serial_out(p, UART_EXAR_SLEEP, sleep ? 0xff : 0);
 - return;
 + goto out;
   }
  
   if (p-capabilities  UART_CAP_SLEEP) {
 @@ -571,7 +573,17 @@ static void serial8250_set_sleep(struct uart_8250_port 
 *p, int sleep)
   serial_out(p, UART_EFR, 0);
   serial_out(p, UART_LCR, 0);
   }
 +
 + if (!device_may_wakeup(p-port.dev)) {
 + if (sleep)
 + pm_runtime_forbid(p-port.dev);
 + else
 + pm_runtime_allow(p-port.dev);
 + }
   }
 +out:
 + pm_runtime_mark_last_busy(p-port.dev);
 + pm_runtime_put_autosuspend(p-port.dev);
  }
  
  #ifdef CONFIG_SERIAL_8250_RSA
 @@ -1280,6 +1292,7 @@ static void serial8250_stop_tx(struct uart_port *port)
   struct uart_8250_port *up =
   container_of(port, struct uart_8250_port, port);
  
 + pm_runtime_get_sync(port-dev);
   __stop_tx(up);
  
   /*
 @@ -1289,6 +1302,8 @@ static void serial8250_stop_tx(struct uart_port *port)
   up-acr |= UART_ACR_TXDIS;
   serial_icr_write(up, UART_ACR, up-acr);
   }
 + pm_runtime_mark_last_busy(port-dev);
 + pm_runtime_put_autosuspend(port-dev);
  }
  
  static void serial8250_start_tx(struct uart_port *port)
 @@ -1296,8 +1311,9 @@ static void serial8250_start_tx(struct uart_port *port)
   struct uart_8250_port *up =
   container_of(port, struct uart_8250_port, port);
  
 + pm_runtime_get_sync(port-dev);
   if (up-dma  !serial8250_tx_dma(up)) {
 - return;
 + goto out;
   } else if (!(up-ier  UART_IER_THRI)) {
   up-ier |= UART_IER_THRI;
   serial_port_out(port, UART_IER, up-ier);
 @@ -1318,6 +1334,9 @@ static void serial8250_start_tx(struct uart_port *port)
   up-acr = ~UART_ACR_TXDIS;
   serial_icr_write(up, UART_ACR, up-acr);
   }
 +out:
 + pm_runtime_mark_last_busy(port-dev);
 + pm_runtime_put_autosuspend(port-dev);
  }
  
  static void serial8250_stop_rx(struct uart_port *port)
 @@ -1325,9 +1344,14 @@ static void serial8250_stop_rx(struct uart_port *port)
   struct uart_8250_port *up =
   container_of(port, struct uart_8250_port, port);
  
 + pm_runtime_get_sync(port-dev);
 +
   up-ier = ~UART_IER_RLSI;
   up-port.read_status_mask = ~UART_LSR_DR;
   serial_port_out(port, UART_IER, up-ier);
 +
 + pm_runtime_mark_last_busy(port-dev);
 + pm_runtime_put_autosuspend(port-dev);
  }
  
  static void serial8250_enable_ms(struct uart_port *port)
 @@ -1340,7 +1364,10 @@ static void serial8250_enable_ms(struct uart_port 
 *port)
   return;
  
   up-ier |= UART_IER_MSI;
 + pm_runtime_get_sync(port-dev);
   serial_port_out(port, UART_IER, up-ier);
 + pm_runtime_mark_last_busy(port-dev);
 + pm_runtime_put_autosuspend(port-dev);
  }
  
  /*
 @@ -1530,9 +1557,17 @@ EXPORT_SYMBOL_GPL(serial8250_handle_irq);
  
  static int serial8250_default_handle_irq(struct uart_port *port)
  {
 - unsigned int iir = serial_port_in(port, UART_IIR);
 + unsigned int iir;
 + int ret;
  
 - return serial8250_handle_irq(port, iir);
 + pm_runtime_get_sync(port-dev);

Is this function executed in interrupt context? Calling _sync() 

Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform

[Laurent Pinchart]

Hi Felipe,

What happened to these two patches ?

On Monday 16 December 2013 17:48:29 Felipe Balbi wrote:
 On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote:
  * Felipe Balbi ba...@ti.com [131216 13:31]:
   On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote:
After the platform devices are created using PLATFORM_DEVID_AUTO, the
device names given in usb_bind_phy (in board file) does not match with
the actual device name causing the USB PHY library not to return the
PHY reference when the MUSB controller request for the PHY in the
non-dt boot case.
So removed creating platform devices using PLATFORM_DEVID_AUTO in
omap2430.c.

Did enumeration testing in omap3 beagle.

Changes from v2:
* Fixed the commit log

Changes from v1:
* refreshed to the latested mainline kernel
* added musb_put_id from omap2430 remove.
   
   Tony, how do you want to handle this ? You want me to provide you a
   branch which we both merge ?
  
  Yes that would be great thanks. For the mach-omap2 touching parts:
  
  Acked-by: Tony Lindgren t...@atomide.com
 
 Here it is, let me know if you prefer a signed tag:
 
 The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
 
   Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 usb-phy-binding-omap3
 
 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18:
 
   arm: omap: remove *.auto* from device names given in usb_bind_phy
 (2013-12-16 17:44:43 -0600)
 
 
 Kishon Vijay Abraham I (2):
   usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
   arm: omap: remove *.auto* from device names given in usb_bind_phy
 
  arch/arm/mach-omap2/board-2430sdp.c|  2 +-
  arch/arm/mach-omap2/board-3430sdp.c|  2 +-
  arch/arm/mach-omap2/board-cm-t35.c |  2 +-
  arch/arm/mach-omap2/board-devkit8000.c |  2 +-
  arch/arm/mach-omap2/board-ldp.c|  2 +-
  arch/arm/mach-omap2/board-omap3beagle.c|  2 +-
  arch/arm/mach-omap2/board-omap3logic.c |  2 +-
  arch/arm/mach-omap2/board-omap3pandora.c   |  2 +-
  arch/arm/mach-omap2/board-omap3stalker.c   |  2 +-
  arch/arm/mach-omap2/board-omap3touchbook.c |  2 +-
  arch/arm/mach-omap2/board-overo.c  |  2 +-
  arch/arm/mach-omap2/board-rx51.c   |  2 +-
  drivers/usb/musb/musb_core.c   | 31 ++-
  drivers/usb/musb/musb_core.h   |  2 ++
  drivers/usb/musb/omap2430.c| 19 --
  15 files changed, 61 insertions(+), 15 deletions(-)

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform

[Felipe Balbi]

Hi,

On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote:
 Hi Felipe,
 
 What happened to these two patches ?

looks like I lost them.

 On Monday 16 December 2013 17:48:29 Felipe Balbi wrote:
  On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote:
   * Felipe Balbi ba...@ti.com [131216 13:31]:
On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote:
 After the platform devices are created using PLATFORM_DEVID_AUTO, the
 device names given in usb_bind_phy (in board file) does not match with
 the actual device name causing the USB PHY library not to return the
 PHY reference when the MUSB controller request for the PHY in the
 non-dt boot case.
 So removed creating platform devices using PLATFORM_DEVID_AUTO in
 omap2430.c.
 
 Did enumeration testing in omap3 beagle.
 
 Changes from v2:
 * Fixed the commit log
 
 Changes from v1:
 * refreshed to the latested mainline kernel
 * added musb_put_id from omap2430 remove.

Tony, how do you want to handle this ? You want me to provide you a
branch which we both merge ?
   
   Yes that would be great thanks. For the mach-omap2 touching parts:
   
   Acked-by: Tony Lindgren t...@atomide.com
  
  Here it is, let me know if you prefer a signed tag:
  
  The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
  
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
  
  are available in the git repository at:
  
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
  usb-phy-binding-omap3
  
  for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18:
  
arm: omap: remove *.auto* from device names given in usb_bind_phy
  (2013-12-16 17:44:43 -0600)
  
  
  Kishon Vijay Abraham I (2):
usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
arm: omap: remove *.auto* from device names given in usb_bind_phy

Kishon, are these still valid ?

-- 
balbi


signature.asc
Description: Digital signature

Re: AM3517 fails to boot 3.16-rc5 device tree kernel

[Michael Welling]

On Mon, Jul 21, 2014 at 12:09:13AM -0700, Tony Lindgren wrote:
 * Michael Welling mwell...@emacinc.com [140718 07:42]:
  On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote:
  
   Hmm maybe double check your're booting device tree based kernel
   instead of legacy machine ID based kernel? The legacy booting should
   still work just fine and no changes has been made to it, but it will
   get removed shortly.
 
  I downloaded the version from the test results and it did boot.
 
 OK that's good to hear.
 
  These are combining the uImage and dtb. How do you accomplish this?
 
 You need to make sure you have the appended DTB support enabled like
 we do in omap2plus_defconfig:
 
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
 
 Then just cat zImage board.dtb  /tmp/zImage-dtba and run
 mkimage to convert it to a uImage:
 
 $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
   -n Linux -d /tmp/zImage-dtba /tmp/uImage
 

I actually discovered this and got LCD video working. Now USB host is
not working. The only thing that registers is the OHCI/EHCI hosts.

root@som3517:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Not sure what the problem is. The USB devices that are plugged in are
powered but never detected.

Any hints?

 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: [GIT PULL] omap soc clean-up for v3.17 merge window

[Olof Johansson]

On Mon, Jul 21, 2014 at 5:30 AM, Tony Lindgren t...@atomide.com wrote:
 The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

   Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.17/soc-cleanup

 for you to fetch changes up to 3db53918e306d3960bf9e12eea8b2fd3f7d0fd62:

   Merge tag 'for-v3.17/omap-clock-a' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into 
 omap-for-v3.17/soc (2014-07-21 00:35:38 -0700)

 

 SoC specific omap clean-up for v3.17 merge window:

 - Changes to PRM and clock related code to help move
   things to drivers

 - Removal of unused ctrl module defines that no longer
   are needed with things moving to .dts files and
   drivers


Merged, thanks.


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

Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver

[Laurent Pinchart]

Hi Tony and Joerg,

On Monday 21 July 2014 02:33:36 Tony Lindgren wrote:
 * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]:
  Hi Suman, Joerg and Tony,
  
  On Friday 18 July 2014 11:53:56 Suman Anna wrote:
   On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
Hello,

The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.

The removal is split in three patches to ease upstream merge. The
first patch removes the omap-iovmm driver, the second patch removes
setting of now unused platform data fields from arch code, and the
last patch cleans up the platform data structure.
   
   Thanks for the revised series, it looks good. I have also tested the
   series on OMAP3, OMAP4 and OMAP5.
   
   For the changes in the entire series,
   Acked-by: Suman Anna s-a...@ti.com
  
  Thank you.
  
I'd like to get at least the first patch merged in v3.17. To avoid
splitting the series across three kernel versions, it would be nice to
also merge at least the second patch for v3.17. If there's no risk of
conflict everything could be merged in one go through the ARM SoC
tree. Otherwise a stable branch with patch 1/3 will be needed to base
the arch change on.

Joerg, Tony, how would you like to proceed ?
  
  The v3.17 merge window is getting close, it's probably too late to merge
  patch 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3
  and 3/3 would then get in v3.18. Tony, how would you like to proceed for
  those ?

 How about Joerg maybe do an immutable branch against v3.16-rc1
 with just these three patches and merge it into your tree?
 
 That way I too can merge the minimal branch in if there are conflics.
 If that works for Joerg, then for arch/arm/*omap* changes:
 
 Acked-by: Tony Lindgren t...@atomide.com

I've created an immutable branch (or, rather, immutable until the changes 
reach mainline, at which point I will remove the branch) on top of v3.16-rc1 
with just the three patches from this series. You can find it at.

git://linuxtv.org/pinchartl/media.git omap/iommu

Tony, is there still time to get this (and especially patch 2/3, which touches 
arch/ code) in v3.17 ?

 If the above is too complicated, then how about Laurent resend patches
 2 - 3 once the dependencies have cleared so I can pick them up. This
 is assuming nothing breaks with patchs 2 - 3 missing naturally :)

-- 
Regards,

Laurent Pinchart

--
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 6/7] arm: dts: omap3-gta04: Add display alias

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 370c08b..05fd4d2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -26,6 +26,10 @@
reg = 0x8000 0x2000; /* 512 MB */
};
 
+   aliases {
+   display0 = lcd;
+   };
+
gpio-keys {
compatible = gpio-keys;
 
-- 
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 7/7] arm: dts: omap3-gta04: Add twl4030 regulators parameters

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 05fd4d2..e39ede2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -346,11 +346,37 @@
bb_uamp = 150;
 };
 
+/* spare */
+vaux1 {
+   regulator-min-microvolt = 250;
+   regulator-max-microvolt = 300;
+};
+
+/* sensors */
+vaux2 {
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   regulator-always-on;
+};
+
+/* camera */
+vaux3 {
+   regulator-min-microvolt = 250;
+   regulator-max-microvolt = 250;
+};
+
+/* WLAN/BT */
 vaux4 {
regulator-min-microvolt = 280;
regulator-max-microvolt = 315;
 };
 
+/* GPS LNA */
+vsim {
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 315;
+};
+
 /* Needed to power the DPI pins */
 vpll2 {
regulator-always-on;
-- 
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/7] arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 5b08d93..4ca1277 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -141,12 +141,15 @@
0x0da (PIN_OUTPUT | MUX_MODE0)   /* 
dss_data23.dss_data23 */
;
};
+};
 
+omap3_pmx_core2 {
spi_gpio_pins: spi_gpio_pinmux {
-   pinctrl-single,pins = 0x5a8 (PIN_OUTPUT | MUX_MODE4) /* clk */
-   0x5b6 (PIN_OUTPUT | MUX_MODE4) /* cs */
-   0x5b8 (PIN_OUTPUT | MUX_MODE4) /* tx */
-   0x5b4 (PIN_INPUT | MUX_MODE4) /* rx */
+   pinctrl-single,pins = 
+   OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* 
clk */
+   OMAP3630_CORE2_IOPAD(0x25e6, PIN_OUTPUT | MUX_MODE4) /* 
cs */
+   OMAP3630_CORE2_IOPAD(0x25e8, PIN_OUTPUT | MUX_MODE4) /* 
tx */
+   OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE4) /* 
rx */
;
};
 };
-- 
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/7] arm: dts: omap3-gta04: Add wifi reset node

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 6d1a8d8..5b08d93 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -196,6 +196,9 @@
#size-cells = 0;
reg = 0x45;
 
+   gpio-controller;
+   #gpio-cells = 2;
+
gta04_led0: red_aux@0 {
label = gta04:red:aux;
reg = 0x0;
@@ -216,6 +219,11 @@
label = gta04:green:power;
reg = 0x4;
};
+
+   wifi_reset: wifi_reset@6 {
+   reg = 0x6;
+   compatible = gpio;
+   };
};
 
/* compass aka magnetometer */
-- 
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/7] arm: dts: omap3-gta04: Add nand support

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 021311f..7d7ddd7 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -309,3 +309,57 @@
};
};
 };
+
+gpmc {
+   ranges = 0 0 0x3000 0x04; /* CS0: NAND */
+
+   nand@0,0 {
+   reg = 0 0 0; /* CS0, offset 0 */
+   nand-bus-width = 16;
+   ti,nand-ecc-opt = bch8;
+
+   gpmc,sync-clk-ps = 0;
+   gpmc,cs-on-ns = 0;
+   gpmc,cs-rd-off-ns = 44;
+   gpmc,cs-wr-off-ns = 44;
+   gpmc,adv-on-ns = 6;
+   gpmc,adv-rd-off-ns = 34;
+   gpmc,adv-wr-off-ns = 44;
+   gpmc,we-off-ns = 40;
+   gpmc,oe-off-ns = 54;
+   gpmc,access-ns = 64;
+   gpmc,rd-cycle-ns = 82;
+   gpmc,wr-cycle-ns = 82;
+   gpmc,wr-access-ns = 40;
+   gpmc,wr-data-mux-bus-ns = 0;
+   gpmc,device-width = 2;
+
+   #address-cells = 1;
+   #size-cells = 1;
+
+   x-loader@0 {
+   label = X-Loader;
+   reg = 0 0x8;
+   };
+
+   bootloaders@8 {
+   label = U-Boot;
+   reg = 0x8 0x1e;
+   };
+
+   bootloaders_env@26 {
+   label = U-Boot Env;
+   reg = 0x26 0x2;
+   };
+
+   kernel@28 {
+   label = Kernel;
+   reg = 0x28 0x40;
+   };
+
+   filesystem@68 {
+   label = File System;
+   reg = 0x68 0xf98;
+   };
+   };
+};
-- 
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/7] arm: dts: omap3-gta04: Fix magnetometer model

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 7d7ddd7..6d1a8d8 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -220,7 +220,7 @@
 
/* compass aka magnetometer */
hmc5843@1e {
-   compatible = honeywell,hmc5843;
+   compatible = honeywell,hmc5843l;
reg = 0x1e;
};
 
-- 
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/7] arm: dts: omap3-gta04: Add USB host support

[Marek Belisko]

Signed-off-by: Marek Belisko ma...@goldelico.com
---
 arch/arm/boot/dts/omap3-gta04.dts | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 4ca1277..370c08b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -74,9 +74,30 @@
};
};
};
+
+   hsusb2_phy: hsusb2_phy {
+   compatible = usb-nop-xceiv;
+   reset-gpios = gpio6 14 GPIO_ACTIVE_LOW;
+   };
 };
 
 omap3_pmx_core {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusb2_pins
+   ;
+
+   hsusb2_pins: pinmux_hsusb2_pins {
+   pinctrl-single,pins = 
+   OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi1_cs3.hsusb2_data2 */
+   OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi2_clk.hsusb2_data7 */
+   OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi2_simo.hsusb2_data4 */
+   OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi2_somi.hsusb2_data5 */
+   OMAP3_CORE1_IOPAD(0x21dc, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi2_cs0.hsusb2_data6 */
+   OMAP3_CORE1_IOPAD(0x21de, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi2_cs1.hsusb2_data3 */
+   ;
+   };
+
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = 
0x152 (PIN_INPUT | MUX_MODE0)   /* 
uart1_rx.uart1_rx */
@@ -144,6 +165,22 @@
 };
 
 omap3_pmx_core2 {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusb2_2_pins
+   ;
+
+   hsusb2_2_pins: pinmux_hsusb2_2_pins {
+   pinctrl-single,pins = 
+   OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+   OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+   OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d12.hsusb2_dir */
+   OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+   OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+   OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+   ;
+   };
+
spi_gpio_pins: spi_gpio_pinmux {
pinctrl-single,pins = 
OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* 
clk */
@@ -259,6 +296,14 @@
power = 50;
 };
 
+usbhshost {
+   port2-mode = ehci-phy;
+};
+
+usbhsehci {
+   phys = 0 hsusb2_phy;
+};
+
 mmc1 {
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
-- 
1.9.1

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

[PATCH 0/7] arm: dts: oma3-gta04: Various updates

[Marek Belisko]

Following patchset add various improvements to gta04 devicetree.

Marek Belisko (7):
  arm: dts: omap3-gta04: Add nand support
  arm: dts: omap3-gta04: Fix magnetometer model
  arm: dts: omap3-gta04: Add wifi reset node
  arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2
  arm: dts: omap3-gta04: Add USB host support
  arm: dts: omap3-gta04: Add display alias
  arm: dts: omap3-gta04: Add twl4030 regulators parameters

 arch/arm/boot/dts/omap3-gta04.dts | 150 --
 1 file changed, 145 insertions(+), 5 deletions(-)

-- 
1.9.1

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

Re: AM3517 fails to boot 3.16-rc5 device tree kernel

[Michael Welling]

On Mon, Jul 21, 2014 at 11:38 AM, Michael Welling mwell...@emacinc.com wrote:
 On Mon, Jul 21, 2014 at 12:09:13AM -0700, Tony Lindgren wrote:
 * Michael Welling mwell...@emacinc.com [140718 07:42]:
  On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote:
  
   Hmm maybe double check your're booting device tree based kernel
   instead of legacy machine ID based kernel? The legacy booting should
   still work just fine and no changes has been made to it, but it will
   get removed shortly.
 
  I downloaded the version from the test results and it did boot.

 OK that's good to hear.

  These are combining the uImage and dtb. How do you accomplish this?

 You need to make sure you have the appended DTB support enabled like
 we do in omap2plus_defconfig:

 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

 Then just cat zImage board.dtb  /tmp/zImage-dtba and run
 mkimage to convert it to a uImage:

 $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
   -n Linux -d /tmp/zImage-dtba /tmp/uImage


 I actually discovered this and got LCD video working. Now USB host is
 not working. The only thing that registers is the OHCI/EHCI hosts.

 root@som3517:~# lsusb
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

 Not sure what the problem is. The USB devices that are plugged in are
 powered but never detected.

 Any hints?

So I got the USB host to work on boot with additional entries in the devicetree.
Documentation/devicetree/bindings/omap-usb-host.txt

Though the devices work if plugged in at boot, any time a device is
hotplugged then
the device is not detected. It is powered very briefly and then off
without any kernel messages.

So hints from this point would be good.


 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