Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Lokesh Vutla]

Hi Tony,

On Wednesday 14 October 2015 04:43 AM, Tony Lindgren wrote:
> On boards with more than 2GB of RAM booting goes wrong with things not working
> and we're getting lots of l3 warnings:
> 
> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x260/0x384()
> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access in 
> User mode during Functional access
> ...
> [] (scsi_add_host_with_dma) from [] 
> (ata_scsi_add_hosts+0x5c/0x18c)
> [] (ata_scsi_add_hosts) from [] 
> (ata_host_register+0x150/0x2cc)
> [] (ata_host_register) from [] 
> (ata_host_activate+0xd4/0x124)
> [] (ata_host_activate) from [] 
> (ahci_host_activate+0x5c/0x194)
> [] (ahci_host_activate) from [] 
> (ahci_platform_init_host+0x1f0/0x3f0)
> [] (ahci_platform_init_host) from [] 
> (ahci_probe+0x70/0x98)
> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> 
> Let's fix the issue by enabling ZONE_DMA for LPAE.

May I know on which platform you have reproduced this?
Just wondering what other changes you made for booting a OMAP5+ based
board with more than 2GB.

Thanks and regards,
Lokesh
> 
> Signed-off-by: Tony Lindgren 
> ---
>  arch/arm/mach-omap2/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index b3a0dff..33d1460 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -49,6 +49,7 @@ config SOC_OMAP5
>   select OMAP_INTERCONNECT
>   select OMAP_INTERCONNECT_BARRIER
>   select PM_OPP if PM
> + select ZONE_DMA if ARM_LPAE
>  
>  config SOC_AM33XX
>   bool "TI AM33XX"
> @@ -78,6 +79,7 @@ config SOC_DRA7XX
>   select OMAP_INTERCONNECT
>   select OMAP_INTERCONNECT_BARRIER
>   select PM_OPP if PM
> + select ZONE_DMA if ARM_LPAE
>  
>  config ARCH_OMAP2PLUS
>   bool
> 
--
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: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Vignesh R]

On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
state via pinctrl and IO daisy chain using generic wakeirq framework.
With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
interrupt in device tree") i2c core allows optional wakeirq to be
specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
to wake the system from low power state.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 22038f21f228..69e93af7df0d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -581,8 +581,13 @@
 
attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
 
+   interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
+ <_pinmux 0x264>;
+   interrupt-names = "tsc", "wakeup";
+
touchscreen-size-x = <1024>;
touchscreen-size-y = <600>;
+   wakeup-source;
};
 
ov2659@30 {
-- 
2.6.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 v3] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*

[Keerthy]

Currently apart from dra7, omap5 and amx3 all the other SoCs
are identified using cpu_is_* functions which is not right since
they are all SoCs(System on Chips). Hence changing the SoC
identification code to use soc_is instead of cpu_is and keeping
defines for cpu_is where needed. This allows us to replace the
rest of cpu_is usage along with other fixes as needed.

Acked-by: Russell King 
Signed-off-by: Keerthy 
---

Compile Testing:

** Compile tested individual: OMAP2, OMAP3, OMAP4, OMAP5, DRA7XX, AM437x,
   AM33XX defconfig.
** Ran Randconfig and found no errors under arch/arm/mach-omap2
   overnight testing.
   Source: https://github.com/felipebalbi/omap-seeds

Boot tested on: DRA7-EVM, AM437X-GP-EVM, AM335X-Beaglebone, OMAP3
Beagle-xm.

Changes in V3:

** Fixed individual defconfig, randconfig compilation errors.

 arch/arm/mach-omap2/id.c  |  30 
 arch/arm/mach-omap2/soc.h | 169 --
 2 files changed, 134 insertions(+), 65 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 54a5ba5..8a2ae82 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -57,15 +57,15 @@ int omap_type(void)
if (val < OMAP2_DEVICETYPE_MASK)
return val;
 
-   if (cpu_is_omap24xx()) {
+   if (soc_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
-   } else if (cpu_is_ti81xx()) {
+   } else if (soc_is_ti81xx()) {
val = omap_ctrl_readl(TI81XX_CONTROL_STATUS);
} else if (soc_is_am33xx() || soc_is_am43xx()) {
val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
-   } else if (cpu_is_omap34xx()) {
+   } else if (soc_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
-   } else if (cpu_is_omap44xx()) {
+   } else if (soc_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
@@ -122,7 +122,7 @@ static u16 tap_prod_id;
 
 void omap_get_die_id(struct omap_die_id *odi)
 {
-   if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
+   if (soc_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -218,17 +218,17 @@ static void __init omap3_cpuinfo(void)
 * on available features. Upon detection, update the CPU id
 * and CPU class bits.
 */
-   if (cpu_is_omap3630()) {
+   if (soc_is_omap3630()) {
cpu_name = "OMAP3630";
} else if (soc_is_am35xx()) {
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
-   } else if (cpu_is_ti816x()) {
+   } else if (soc_is_ti816x()) {
cpu_name = "TI816X";
} else if (soc_is_am335x()) {
cpu_name =  "AM335X";
} else if (soc_is_am437x()) {
cpu_name =  "AM437x";
-   } else if (cpu_is_ti814x()) {
+   } else if (soc_is_ti814x()) {
cpu_name = "TI814X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
@@ -275,11 +275,11 @@ void __init omap3xxx_check_features(void)
OMAP3_CHECK_FEATURE(status, SGX);
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
-   if (cpu_is_omap3630())
+   if (soc_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
-   if (cpu_is_omap3430() || cpu_is_omap3630())
+   if (soc_is_omap3430() || soc_is_omap3630())
omap_features |= OMAP3_HAS_IO_WAKEUP;
-   if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
+   if (soc_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
 
@@ -701,7 +701,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
*tap)
tap_base = tap;
 
/* XXX What is this intended to do? */
-   if (cpu_is_omap34xx())
+   if (soc_is_omap34xx())
tap_prod_id = 0x0210;
else
tap_prod_id = 0x0208;
@@ -719,11 +719,11 @@ static const char * const omap_types[] = {
 
 static const char * __init omap_get_family(void)
 {
-   if (cpu_is_omap24xx())
+   if (soc_is_omap24xx())
return kasprintf(GFP_KERNEL, "OMAP2");
-   else if (cpu_is_omap34xx())
+   else if (soc_is_omap34xx())
return kasprintf(GFP_KERNEL, "OMAP3");
-   else if (cpu_is_omap44xx())
+   else if (soc_is_omap44xx())
return kasprintf(GFP_KERNEL, "OMAP4");
else if 

Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Lokesh Vutla]

On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> Hello Lokesh,
> 
> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>> +Nishanth,
>>
>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>>> On embedded devices, often there is a combination of
>>> removable mmc devices (e.g. MMC/SD cards) and hard
>>> wired ones (e.g. eMMC). Depending on the hardware
>>> configuration, the 'mmcblkN' node might change if
>>> the removable device is available or not at boot time.
>>>
>>> E.g. if the removable device is attached at boot time,
>>> it might become mmxblk0. And the hard wired one mmcblk1.
>>> But if the removable device isn't there at boot time,
>>> the hard wired one will become mmcblk0. This makes it
>>> somehow difficult to hard code the root device to the
>>> non-removable device and boot fast.
>>
>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>> mmcblk no?
>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>> does this in u-boot.
> 
> Good tip ... I do not know, if it is possible to update U-Boot
> on this boards...
> 
> Current U-Boot says:
> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
> 
> I2C:   ready
> DRAM:  512 MiB
> [...]
> U-Boot# mmc rescan
> U-Boot# mmc part
> 
> Partition Map for MMC device 0  --   Partition Type: DOS
> 
> PartStart SectorNum Sectors UUIDType
>   1 63  144522  000ce343-01 0e Boot
>   2 144585  659861  000ce343-02 83
> U-Boot# part uuid mmc 0:2 uuid
> Unknown command 'part' - try 'help'
> U-Boot#
> 
> So, if this patch has no chance for mainline, please let me
> know it, thanks!
> 

IIRC, Nishanth had posted a patch something similar but got rejected for
some reason. Probably Nishanth can comment more here.

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

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Tero Kristo]

On 10/12/2015 06:22 PM, Rolf Peukert wrote:

The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
interface and function clocks for the M-USB controller. These calls fail
in the current kernel. This patch adds clock definitions containing the
device ID to the list in clk-3xxx.c, so the calls to clk_get() in
am35x.c can succeed.

Signed-off-by:  Rolf Peukert 

---
  drivers/clk/ti/clk-3xxx.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 8831e1a..b635deb 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
DT_CLK("vpfe-capture", "master", "vpfe_ick"),
DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
+   DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
+   DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
DT_CLK(NULL, "hecc_ck", "hecc_ck"),
DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),



Adding clock aliases should be avoided, isn't there any other way to fix 
this issue? Like adding clocks = <> references under the DT node?


-Tero

--
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] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Ben Dooks]

On 12/10/15 20:19, Tony Lindgren wrote:
> * Ben Dooks  [151012 11:22]:
>> On 12/10/15 18:45, Tony Lindgren wrote:
>>> * Ben Dooks  [151012 10:38]:
 The AM3715 OHCI controller will not function without the EHCI
 unit's 120m fclk being enabled. If all the ports in the system
 are set to OHCI then the 120m_fclk will not get enabled and no
 devices are detected.

 Add a new (optional) property to signal the system must enable
 the 120m_fck for OHCI so that if no EHCI ports are signalled
 then the 120m_fclk should be enabled.

 We have found no information about why this is necessary, but
 it is suspected the EHCI controller does not complete the initial
 reset sequence and therefore does not hand control of the USB
 port back.

 Signed-off-by: Ben Dooks 
 ---
  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
  drivers/mfd/omap-usb-host.c| 4 
  2 files changed, 7 insertions(+)

 diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
 b/Documentation/devicetree/bindings/usb/omap-usb.txt
 index 38d9bb8..fb5fea5 100644
 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
 @@ -23,6 +23,9 @@ OMAP MUSB GLUE
  Optional properties:
   - ctrl-module : phandle of the control module this glue uses to write to
 mailbox
 + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
 +   using ohci. Needed for AM3517 in OHCI only mode.
 +
  
  SOC specific device node entry
  usb_otg_hs: usb_otg_hs@4a0ab000 {
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 1d924d1..13880cf 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
 *pdev)
need_logic_fck |= true;
}
  
 +  /* The AM3517 requries the 120m-fck active to allow the OHCI to 
 work */
 +  if (of_property_read_bool(dev->of_node, 
 "ti,ohci-needs-120m-fck"))
 +  need_logic_fck |= true;
 +
if (need_logic_fck) {
omap->ehci_logic_fck = devm_clk_get(dev,
"usbhost_120m_fck");
>>>
>>> Hmm why not just use the standard device tree clocks property and then do
>>> clk_get_rate() on the clock?
>>
>> I don't see that helps enabling the clock. The code decideds if
>> no EHCI ports in use that it doesn't need to enable the EHCI fclk.
> 
> Right, you need to do clk_prepare_enable() in it first? :)

No, if that was the case the driver would never work for the EHCI case.

The issue is:

1) All ports on the system are set to OHCI
2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
3) The OHCI fails to detect any devices due to point 2.

-- 
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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: DM3730 vs 3630 DSS Cock dividers

[Tero Kristo]

On 10/12/2015 10:35 PM, Tony Lindgren wrote:

* Tomi Valkeinen  [151012 11:08]:


On 12.10.2015 19:00, Tony Lindgren wrote:

* Adam Ford  [151010 13:29]:

Tomi and Tony,

I am working on the LogicPD DM3730 Torpedo module.  If I try to use the
DSS, I get the same errors as mentioned in these previous messages found
here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/255103.html

The patch is basicaly:


* >>  drivers/video/fbdev/omap2/dss/dss.c | 5 +++--

*>* >>  1 file changed, 3 insertions(+), 2 deletions(-)
*>* >>
*>* >> diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> index d55266c..ad6561f 100644
*>* >> --- a/drivers/video/fbdev/omap2/dss/dss.c
*>* >> +++ b/drivers/video/fbdev/omap2/dss/dss.c
*>* >> @@ -707,9 +707,10 @@ static const struct dss_features
omap34xx_dss_feats __initconst = {
*>* >>   .dpi_select_source  =   _dpi_select_source_omap2_omap3,
*>* >>  };
*>* >>
*>* >> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be
rechecked */
*>* >>  static const struct dss_features omap3630_dss_feats __initconst = {
*>* >> - .fck_div_max=   32,
*>* >> - .dss_fck_multiplier =   1,
*>* >> + .fck_div_max=   16,
*>* >> + .dss_fck_multiplier =   2,
*>* >
*>* > These values tell about the clock hardware, they are not settings that
*>* > can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
*>* > and a divider with maximum value of 16.
*>* >
*>* >  Tomi
*>* >
*>* >*


I don't see this mainstream yet, but the patch is from a while ago.
Do you guys know if this will make it into the kernel?  Without it, I
cannot the DM3730 to DSS to operate correctly.


AFAIK 37xx is same as 3630 and does not work properly without the patch
above as we've seen.


Well, the patch is definitely wrong for 3630, as 3630 has divider range from
1 to 32, as seen from the CM_CLKSEL_DSS register.


Yes something is wrong somewhere for sure.. What if it's .dss_fck_multiplier = 2
and .fck_div_max = 32?


I can't find the fixed x2 multiplier from the TRM, but looking at the .dts
files, 3630 DSS gets the clock from dpll4_m4x2_ck, so maybe it is there. Or
maybe the clocks in the .dts files are wrong, and the multplier in dss.c is
right.


Yes grepping for it we have it both for legacy and dts clocks:

$ git grep dpll4_m4x2_ck
Documentation/devicetree/bindings/clock/ti/gate.txt:clocks = 
<_m4x2_ck>;
arch/arm/boot/dts/omap3430es1-clocks.dtsi:  clocks = 
<_m4x2_ck>;
arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi:  clocks = 
<_m4x2_ck>;
arch/arm/boot/dts/omap3xxx-clocks.dtsi: dpll4_m4x2_ck: dpll4_m4x2_ck {
drivers/clk/ti/clk-3xxx-legacy.c:static struct ti_clk_gate dpll4_m4x2_ck_data = 
{
drivers/clk/ti/clk-3xxx-legacy.c:static struct ti_clk dpll4_m4x2_ck = {
drivers/clk/ti/clk-3xxx-legacy.c:   .name = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   .data = _m4x2_ck_data,
drivers/clk/ti/clk-3xxx-legacy.c:   .parent = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   .parent = "dpll4_m4x2_ck",
drivers/clk/ti/clk-3xxx-legacy.c:   CLK(NULL, "dpll4_m4x2_ck", 
_m4x2_ck),
drivers/clk/ti/clk-3xxx.c:  DT_CLK(NULL, "dpll4_m4x2_ck", "dpll4_m4x2_ck"),


And looking at the TRM, "3.5.3.3.4 DPLL Clock Summary" hints strongly that
there is no x2 multiplier there, so it might be that the dts clock files are
not right.


Or maybe the TRM was copied from the 34xx and never updated?

Tero, any ideas?


TRMs are correct, 3630 does not have x2 multiplier after DPLL4.

In the clock data, dpll4_m4x2 path is an x1 multiplier on omap3630, it 
is easier to represent this in DT than completely remove the dpll4_*x2 
nodes for omap36xx. This is how it was already before the DT clocks.


Here is a copy paste from clock debug data on omap36xx where you see the 
rate for the whole dpll4_m4 path is 96MHz:


 dpll4_m4_ck  019600 
   0 0
dpll4_m4x2_mul_ck   019600 
 0 0
   dpll4_m4x2_ck   019600 
0 0
  dss1_alwon_fck_3430es2   04 
  9600  0 0


And same on omap34xx (not sure why the clock rate is totally different 
here though, but you see the x2 applied):


 dpll4_m4_ck  01   21600 
   0

0
dpll4_m4x2_mul_ck   01   43200 


0 0
   dpll4_m4x2_ck   01   43200 
0

 0


-Tero




Unfortunately I have no working omap3 devices to test this =(.


Should not cost you more than few tens of whatever units to get one :)

Anybody have a spare 37xx device with an LCD to donate for Tomi?

Regards,

Tony



--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Heiko Schocher]

Hello Lokesh,

Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:

+Nishanth,

On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:

On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.

E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.


Why not use "root=PARTUUID=${uuid}" option instead of relying on mmcblk no?
U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
does this in u-boot.


Good tip ... I do not know, if it is possible to update U-Boot
on this boards...

Current U-Boot says:
U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)

I2C:   ready
DRAM:  512 MiB
[...]
U-Boot# mmc rescan
U-Boot# mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 63  144522  000ce343-01 0e Boot
  2 144585  659861  000ce343-02 83
U-Boot# part uuid mmc 0:2 uuid
Unknown command 'part' - try 'help'
U-Boot#

So, if this patch has no chance for mainline, please let me
know it, thanks!

bye,
Heiko


[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=437bc42e7ff930dc4d4bd47199d2e823cf84bf4c;hp=85d17be374678ec37fd1e55db994a942e400dc80

Thanks and regards,
Lokesh


Signed-off-by: Heiko Schocher 
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"

I adapt this to the omap_hsmmc driver.

Is there another solution for this problem?
Or why was this patch not accepted to mainline?

  drivers/mmc/card/block.c  | 6 --
  drivers/mmc/host/omap_hsmmc.c | 6 ++
  include/linux/mmc/host.h  | 3 +++
  3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;

-   devidx = find_first_zero_bit(dev_use, max_devices);
+   devidx = find_next_zero_bit(dev_use, max_devices,
+   card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
 * index anymore so we keep track of a name index.
 */
if (!subname) {
-   md->name_idx = find_first_zero_bit(name_use, max_devices);
+   md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;

+   if (pdev->dev.of_node) {
+   ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+   if (ret >= 0)
+   host->mmc->devidx = ret;
+   }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */

+   /* preferred mmc block device index (mmcblkX) */
+   unsigned intdevidx;
+
unsigned long   private[0] cacheline_aligned;
  };






--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] arm: omap2+: PM: change trace_power_domain_target event format.

[Marc Titinger]

On 13/10/2015 01:33, Tony Lindgren wrote:

* Marc Titinger  [150925 08:02]:



On 25/09/2015 16:10, Steven Rostedt wrote:

On Fri, 25 Sep 2015 15:22:25 +0200
Marc Titinger  wrote:


From: Marc Titinger 

power_domain_target arg3 is now a string (event name) with generic power
domains. In the case of Omap, it is a hint to the prev/next switch op.
Incidentally this trace is now conditioned by CONFIG_PM_ADVANCED_DEBUG.

I'm curious to why the addition of this config option?


I meant to be consistent with Juno/generic-power-domains, so that this trace
always (or never) requires this switch.
I think I will remove this condition for both actually.


Compiled for Omap2+ but not tested.

Signed-off-by: Marc Titinger 
---
  arch/arm/mach-omap2/powerdomain.c | 32 
  1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 78af6d8..cd77696 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -160,7 +160,7 @@ static void _update_logic_membank_counters(struct 
powerdomain *pwrdm)
  static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
  {
-   int prev, next, state, trace_state = 0;
+   int prev, state;
if (pwrdm == NULL)
return -EINVAL;
@@ -177,18 +177,25 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
pwrdm->state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
_update_logic_membank_counters(pwrdm);
-   /*
-* If the power domain did not hit the desired state,
-* generate a trace event with both the desired and hit states
-*/
-   next = pwrdm_read_next_pwrst(pwrdm);
-   if (next != prev) {
-   trace_state = (PWRDM_TRACE_STATES_FLAG |
+
+#ifdef CONFIG_PM_ADVANCED_DEBUG

You do realize that you can add this to the block:


if (trace_power_domain_target_enabled()) {

Nope I didn't, but now I do ;) thanks.


Probably best to keep this with your series, it should not cause merge 
conflicts,
so:

Acked-by: Tony Lindgren 



Thanks for the ack. Indeed, I rebased it on current but figured that 
it's not that usefull until 'multiple states' are merged in.


M.

--
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 11/25] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

[Peter Ujfalusi]

On 10/12/2015 07:00 PM, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 01:01:58PM +0300, Peter Ujfalusi wrote:
>> Move the code out from arch/arm/common and merge it inside of the dmaengine
>> driver.
>> This change is done with as minimal change to the code as possible to avoid
>> any possibilities to introducing regression.
> 
> Is this a pure move patch or code has been modified, if latter am
> disappointed that existing code style issue have not been fixed

Yes, it is mostly code move, I have done minimal changes only needed to get
the moved code working in the new location.
Patch 13 in this series will go through the file and will fix up most (I hope
all) of the outstanding coding style issues.
At this point I wanted to have as small change as possible.

>> +static inline void edma_write(struct edma_cc *ecc, int offset, int val)
>> +{
>> +__raw_writel(val, ecc->base + offset);
>> +}
>> +static inline void edma_modify(struct edma_cc *ecc, int offset, unsigned 
>> and,
>> +   unsigned or)
> 
> This looks bad on my 80 char screen, and few more places below
> 
>> +{
>> +unsigned val = edma_read(ecc, offset);
> 
> checkpatch should have asked you to add empty line here, many places below
> too
> 
>> +val &= and;
>> +val |= or;
>> +edma_write(ecc, offset, val);
>> +}
> 
> empty line here and few more places
> 
> More later :)
> 


-- 
Péter
--
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] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Roger Quadros]

Ben,

On 13/10/15 11:23, Ben Dooks wrote:
> On 12/10/15 20:19, Tony Lindgren wrote:
>> * Ben Dooks  [151012 11:22]:
>>> On 12/10/15 18:45, Tony Lindgren wrote:
 * Ben Dooks  [151012 10:38]:
> The AM3715 OHCI controller will not function without the EHCI
> unit's 120m fclk being enabled. If all the ports in the system
> are set to OHCI then the 120m_fclk will not get enabled and no
> devices are detected.
>
> Add a new (optional) property to signal the system must enable
> the 120m_fck for OHCI so that if no EHCI ports are signalled
> then the 120m_fclk should be enabled.
>
> We have found no information about why this is necessary, but
> it is suspected the EHCI controller does not complete the initial
> reset sequence and therefore does not hand control of the USB
> port back.
>
> Signed-off-by: Ben Dooks 
> ---
>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>  drivers/mfd/omap-usb-host.c| 4 
>  2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 38d9bb8..fb5fea5 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>  Optional properties:
>   - ctrl-module : phandle of the control module this glue uses to write to
> mailbox
> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
> +   using ohci. Needed for AM3517 in OHCI only mode.
> +
>  
>  SOC specific device node entry
>  usb_otg_hs: usb_otg_hs@4a0ab000 {
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 1d924d1..13880cf 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
> *pdev)
>   need_logic_fck |= true;
>   }
>  
> + /* The AM3517 requries the 120m-fck active to allow the OHCI to 
> work */
> + if (of_property_read_bool(dev->of_node, 
> "ti,ohci-needs-120m-fck"))
> + need_logic_fck |= true;
> +
>   if (need_logic_fck) {
>   omap->ehci_logic_fck = devm_clk_get(dev,
>   "usbhost_120m_fck");

 Hmm why not just use the standard device tree clocks property and then do
 clk_get_rate() on the clock?
>>>
>>> I don't see that helps enabling the clock. The code decideds if
>>> no EHCI ports in use that it doesn't need to enable the EHCI fclk.
>>
>> Right, you need to do clk_prepare_enable() in it first? :)
> 
> No, if that was the case the driver would never work for the EHCI case.
> 
> The issue is:
> 
> 1) All ports on the system are set to OHCI
> 2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
> 3) The OHCI fails to detect any devices due to point 2.
> 

Instead of your existing approach why not just modify the preceeding
if condition that sets need_logic_fck to suit the OHCI case.

That way you don't need to add a new DT binding.

The old assumption was that 120m_fck logic clock is only needed for
EHCI mode but it looks like OHCI mode needs it as well.

You should also rename omap->ehci_logic_fck to omap->hci_logic_fck
as it is no longer ehci specific.

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 v3] ARM: dts: twl4030: Add iio properties for bci subnode

[Belisko Marek]

Hi,

On Tue, Oct 13, 2015 at 1:53 AM, Sebastian Reichel  wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 03:20:10PM -0700, Tony Lindgren wrote:
>> * Tony Lindgren  [151012 14:43]:
>> > * Belisko Marek  [150926 13:02]:
>> > > Tony sorry I forgot to add you to the recipients for this patchset.
>> > > Can you please queue this patch. Many thanks.
>> >
>> > OK applying into omap-for-v4.4/dt thanks.
>>
>> Actually dropping this one, it makes build fail as we don't
>> have twl4030_madc yet.
>>
>> Maybe please send a separate set of dts patches for me.
>
> mh that's strange, twl4030-madc is there since a long time. But
> checking the patch, it seems Marek got the phandle wrong:
OK, thanks for letting me know. I'll send update soon. Thanks.
>
> $ grep -B1 "ti,twl4030-madc" arch/arm/boot/dts/twl4030.dtsi
> twl_madc: madc {
> compatible = "ti,twl4030-madc";
>
> Once that is fixed, the patch should have no dependencies.
>
> -- Sebastian

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
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] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Lokesh Vutla]

+Nishanth,

On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
> On embedded devices, often there is a combination of
> removable mmc devices (e.g. MMC/SD cards) and hard
> wired ones (e.g. eMMC). Depending on the hardware
> configuration, the 'mmcblkN' node might change if
> the removable device is available or not at boot time.
> 
> E.g. if the removable device is attached at boot time,
> it might become mmxblk0. And the hard wired one mmcblk1.
> But if the removable device isn't there at boot time,
> the hard wired one will become mmcblk0. This makes it
> somehow difficult to hard code the root device to the
> non-removable device and boot fast.

Why not use "root=PARTUUID=${uuid}" option instead of relying on mmcblk no?
U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
does this in u-boot.

[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=437bc42e7ff930dc4d4bd47199d2e823cf84bf4c;hp=85d17be374678ec37fd1e55db994a942e400dc80

Thanks and regards,
Lokesh
> 
> Signed-off-by: Heiko Schocher 
> ---
> Dirk Behme tried to bring this in, last mail I found:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
> where Dirk worked in Arnds suggestion to use the
> "/aliases" device node"
> 
> I adapt this to the omap_hsmmc driver.
> 
> Is there another solution for this problem?
> Or why was this patch not accepted to mainline?
> 
>  drivers/mmc/card/block.c  | 6 --
>  drivers/mmc/host/omap_hsmmc.c | 6 ++
>  include/linux/mmc/host.h  | 3 +++
>  3 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index c742cfd..62250d8 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
> mmc_card *card,
>   struct mmc_blk_data *md;
>   int devidx, ret;
>  
> - devidx = find_first_zero_bit(dev_use, max_devices);
> + devidx = find_next_zero_bit(dev_use, max_devices,
> + card->host->devidx);
>   if (devidx >= max_devices)
>   return ERR_PTR(-ENOSPC);
>   __set_bit(devidx, dev_use);
> @@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
> mmc_card *card,
>* index anymore so we keep track of a name index.
>*/
>   if (!subname) {
> - md->name_idx = find_first_zero_bit(name_use, max_devices);
> + md->name_idx = find_next_zero_bit(name_use, max_devices,
> +   card->host->devidx);
>   __set_bit(md->name_idx, name_use);
>   } else
>   md->name_idx = ((struct mmc_blk_data *)
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 7fb0753..0b45b48 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device 
> *pdev)
>   host->pbias_enabled = 0;
>   host->vqmmc_enabled = 0;
>  
> + if (pdev->dev.of_node) {
> + ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
> + if (ret >= 0)
> + host->mmc->devidx = ret;
> + }
> +
>   ret = omap_hsmmc_gpio_init(mmc, host, pdata);
>   if (ret)
>   goto err_gpio;
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 83b81fd..4f071681 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -382,6 +382,9 @@ struct mmc_host {
>   int dsr_req;/* DSR value is valid */
>   u32 dsr;/* optional driver stage (DSR) value */
>  
> + /* preferred mmc block device index (mmcblkX) */
> + unsigned intdevidx;
> +
>   unsigned long   private[0] cacheline_aligned;
>  };
>  
> 
--
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] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Ben Dooks]

On 13/10/15 09:45, Roger Quadros wrote:
> Ben,
> 
> On 13/10/15 11:23, Ben Dooks wrote:
>> On 12/10/15 20:19, Tony Lindgren wrote:
>>> * Ben Dooks  [151012 11:22]:
 On 12/10/15 18:45, Tony Lindgren wrote:
> * Ben Dooks  [151012 10:38]:
>> The AM3715 OHCI controller will not function without the EHCI
>> unit's 120m fclk being enabled. If all the ports in the system
>> are set to OHCI then the 120m_fclk will not get enabled and no
>> devices are detected.
>>
>> Add a new (optional) property to signal the system must enable
>> the 120m_fck for OHCI so that if no EHCI ports are signalled
>> then the 120m_fclk should be enabled.
>>
>> We have found no information about why this is necessary, but
>> it is suspected the EHCI controller does not complete the initial
>> reset sequence and therefore does not hand control of the USB
>> port back.
>>
>> Signed-off-by: Ben Dooks 
>> ---
>>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>>  drivers/mfd/omap-usb-host.c| 4 
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> index 38d9bb8..fb5fea5 100644
>> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>>  Optional properties:
>>   - ctrl-module : phandle of the control module this glue uses to write 
>> to
>> mailbox
>> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if 
>> just
>> +   using ohci. Needed for AM3517 in OHCI only mode.
>> +
>>  
>>  SOC specific device node entry
>>  usb_otg_hs: usb_otg_hs@4a0ab000 {
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 1d924d1..13880cf 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
>> *pdev)
>>  need_logic_fck |= true;
>>  }
>>  
>> +/* The AM3517 requries the 120m-fck active to allow the 
>> OHCI to work */
>> +if (of_property_read_bool(dev->of_node, 
>> "ti,ohci-needs-120m-fck"))
>> +need_logic_fck |= true;
>> +
>>  if (need_logic_fck) {
>>  omap->ehci_logic_fck = devm_clk_get(dev,
>>  
>> "usbhost_120m_fck");
>
> Hmm why not just use the standard device tree clocks property and then do
> clk_get_rate() on the clock?

 I don't see that helps enabling the clock. The code decideds if
 no EHCI ports in use that it doesn't need to enable the EHCI fclk.
>>>
>>> Right, you need to do clk_prepare_enable() in it first? :)
>>
>> No, if that was the case the driver would never work for the EHCI case.
>>
>> The issue is:
>>
>> 1) All ports on the system are set to OHCI
>> 2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
>> 3) The OHCI fails to detect any devices due to point 2.
>>
> 
> Instead of your existing approach why not just modify the preceeding
> if condition that sets need_logic_fck to suit the OHCI case.
> 
> That way you don't need to add a new DT binding.
> 
> The old assumption was that 120m_fck logic clock is only needed for
> EHCI mode but it looks like OHCI mode needs it as well.
> 
> You should also rename omap->ehci_logic_fck to omap->hci_logic_fck
> as it is no longer ehci specific.

Thanks, will go and have a look at the manual later as didn't see two
separate 120m clocks when looking.


-- 
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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

[BISECTED] v4.3-rc5: OMAP1 boot hang

[Aaro Koskinen]

Hi,

Amstrad E3 / OMAP1 boot hangs, and I bisected it to
a5e090acbf545c0a3b04080f8a488b17ec41fe02 ("ARM: software-based
priviledged-no-access support").

Below is the boot log. Disabling CPU_SW_DOMAIN_PAN helps.

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.3.0-rc5-e3-los_df2ad+ (aaro@amd-fx-6350) (gcc 
version 5.2.0 (GCC) ) #1 Tue Oct 13 10:08:05 EEST 2015
[0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Amstrad E3 (Delta)
[0.00] Ignoring memory below PHYS_OFFSET: 0x0200-0x1000
[0.00] Memory policy: Data cache writethrough
[0.00] On node 0 totalpages: 8192
[0.00] free_area_init_node: node 0, pgdat c0427018, node_mem_map 
c1fb7000
[0.00]   Normal zone: 64 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 8192 pages, LIFO batch:0
[0.00] OMAP1510
[0.00]  revision 2 handled as 15xx id: bc058c9b93111a16
[0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/150.0/150.0 MHz
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 8128
[0.00] Kernel command line: mem=32M console=tty console=ttyS0,115200n8 
root=/dev/ram0 initrd=0x11c0,2894948 initcall_debug=1 loglevel=9
[0.00] PID hash table entries: 128 (order: -3, 512 bytes)
[0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Memory: 25136K/32768K available (3074K kernel code, 141K rwdata, 
864K rodata, 140K init, 212K bss, 7632K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc280 - 0xff00   ( 968 MB)
[0.00] lowmem  : 0xc000 - 0xc200   (  32 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc03e0ec4   (3940 kB)
[0.00]   .init : 0xc03e1000 - 0xc0404000   ( 140 kB)
[0.00]   .data : 0xc0404000 - 0xc04277e0   ( 142 kB)
[0.00].bss : 0xc04277e0 - 0xc045c9c0   ( 213 kB)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] Total of 64 interrupts in 2 interrupt banks
[0.000131] sched_clock: 32 bits at 6MHz, resolution 166ns, wraps every 
357913940908ns
[0.000382] clocksource: mpu_timer2: mask: 0x max_cycles: 
0x, max_idle_ns: 318543407797 ns
[0.001561] Console: colour dummy device 80x30
[0.009527] console [tty0] enabled
[0.010230] Calibrating delay loop... 74.13 BogoMIPS (lpj=370688)
[0.100420] pid_max: default: 32768 minimum: 301
[0.101672] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.102202] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.108589] CPU: Testing write buffer coherency: ok
[0.111741] calling  init_static_idmap+0x0/0x11c @ 1
[0.112570] Setting up static identity map for 0x10008400 - 0x1000842c
[0.113178] initcall init_static_idmap+0x0/0x11c returned 0 after 0 usecs
[0.113812] calling  spawn_ksoftirqd+0x0/0x30 @ 1
[0.115210] initcall spawn_ksoftirqd+0x0/0x30 returned 0 after 0 usecs
[0.115820] calling  init_workqueues+0x0/0x2ec @ 1
[0.120426] initcall init_workqueues+0x0/0x2ec returned 0 after 9765 usecs
[0.121133] calling  rand_initialize+0x0/0x34 @ 1
[0.122426] initcall rand_initialize+0x0/0x34 returned 0 after 0 usecs
[0.126229] devtmpfs: initialized
[0.136417] calling  ipc_ns_init+0x0/0x44 @ 1
[0.136959] initcall ipc_ns_init+0x0/0x44 returned 0 after 0 usecs
[0.137461] calling  init_mmap_min_addr+0x0/0x2c @ 1
[0.137893] initcall init_mmap_min_addr+0x0/0x2c returned 0 after 0 usecs
[0.138440] calling  net_ns_init+0x0/0x1c8 @ 1
[0.139019] initcall net_ns_init+0x0/0x1c8 returned 0 after 0 usecs
[0.140507] calling  ptrace_break_init+0x0/0x34 @ 1
[0.141046] initcall ptrace_break_init+0x0/0x34 returned 0 after 0 usecs
[0.141573] calling  omap1_pm_runtime_init+0x0/0x28 @ 1
[0.142020] initcall omap1_pm_runtime_init+0x0/0x28 returned 0 after 0 usecs
[0.142531] calling  wq_sysfs_init+0x0/0x38 @ 1
[0.144169] initcall wq_sysfs_init+0x0/0x38 returned 0 after 0 usecs
[0.144753] calling  ksysfs_init+0x0/0xa8 @ 1
[0.145728] initcall ksysfs_init+0x0/0xa8 returned 0 after 0 usecs
[0.146299] calling  

Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Lee Jones]

On Sun, 11 Oct 2015, Jonathan Cameron wrote:

> On 05/10/15 07:14, H. Nikolaus Schaller wrote:
> > This driver code was found as:
> > 
> > https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
> > 
> > Fixed various compilation issues and test this driver on omap5 evm.
> > 
> > Signed-off-by: Pradeep Goudagunta 
> > Signed-off-by: H. Nikolaus Schaller 
> > Signed-off-by: Marek Belisko 
> 
> I'm pretty much fine with this.  However, there are some edits within the
> existing mfd support so I will want acks for that or for the driver to go
> through the MFD tree (note that as it touched that, even if only a header,
> Lee and Samuel should have been cc'd).
> 
> One thing that slightly confuses me is there seems to be hints of support in 
> the
> mfd driver already... I can't find any sign of the child device however so
> I guess this is fine from that point of view.
> 
> Reviewed-by: Jonathan Cameron 
> > ---
> >  drivers/iio/adc/Kconfig|   9 +
> >  drivers/iio/adc/Makefile   |   1 +
> >  drivers/iio/adc/palmas_gpadc.c | 818 
> > +
> >  include/linux/mfd/palmas.h |  75 ++--

Acked-by: Lee Jones 

> >  4 files changed, 879 insertions(+), 24 deletions(-)
> >  create mode 100644 drivers/iio/adc/palmas_gpadc.c
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index eb0cd89..05a0368 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -242,6 +242,15 @@ config NAU7802
> >   To compile this driver as a module, choose M here: the
> >   module will be called nau7802.
> >  
> > +config PALMAS_GPADC
> > +   tristate "TI Palmas General Purpose ADC"
> > +   depends on MFD_PALMAS
> > +   help
> > + Say yes here to build support for Texas Instruments Palmas.
> > +
> > + Palmas series pmic chip (twl6035/6037) is used in smartphones and
> > + tablets and supports a 16 channel general purpose ADC.
> > +
> >  config QCOM_SPMI_IADC
> > tristate "Qualcomm SPMI PMIC current ADC"
> > depends on SPMI
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index a096210..716f112 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> >  obj-$(CONFIG_MCP3422) += mcp3422.o
> >  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> >  obj-$(CONFIG_NAU7802) += nau7802.o
> > +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
> >  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> >  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> >  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> > diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
> > new file mode 100644
> > index 000..6805d81
> > --- /dev/null
> > +++ b/drivers/iio/adc/palmas_gpadc.c
> > @@ -0,0 +1,818 @@
> > +/*
> > + * palmas-adc.c -- TI PALMAS GPADC.
> > + *
> > + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
> > + *
> > + * Author: Pradeep Goudagunta 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MOD_NAME "palmas-gpadc"
> > +#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
> > +#define PALMAS_TO_BE_CALCULATED 0
> > +#define PALMAS_GPADC_TRIMINVALID   -1
> > +
> > +struct palmas_gpadc_info {
> > +/* calibration codes and regs */
> > +   int x1; /* lower ideal code */
> > +   int x2; /* higher ideal code */
> > +   int v1; /* expected lower volt reading */
> > +   int v2; /* expected higher volt reading */
> > +   u8 trim1_reg;   /* register number for lower trim */
> > +   u8 trim2_reg;   /* register number for upper trim */
> > +   int gain;   /* calculated from above (after reading trim regs) */
> > +   int offset; /* calculated from above (after reading trim regs) */
> > +   int gain_error; /* calculated from above (after reading trim regs) */
> > +   bool is_uncalibrated;   /* if channel has calibration data */
> > +};
> > +
> > +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
> > _is_uncalibrated) \
> > +   [PALMAS_ADC_CH_##_chan] = { \
> > +   .x1 = _x1, \
> > +   .x2 = _x2, \
> > +   .v1 = _v1, \
> > +   .v2 = _v2, \
> > +   .gain = PALMAS_TO_BE_CALCULATED, \
> > +   .offset = PALMAS_TO_BE_CALCULATED, \
> > +   .gain_error = PALMAS_TO_BE_CALCULATED, \
> > +   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
> > +   

Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Lucas Stach]

Am Freitag, den 25.09.2015, 20:44 + schrieb Woodruff, Richard:
> > From: Menon, Nishanth
> > Sent: Friday, September 25, 2015 9:44 AM
> 
> > > If I688 is not needed on am335x, then it seems there are still some
> > > mysteries remaining with this erratum to unravel. Something like
> > > difference in the L3 implementation. Maybe somebody from TI can
> > > investigate which SoCs this is really needed on?
> 
> > + Richard who probably has the oldest history on the topic.
> > 
> > I suspect strongly that the erratum was discovered during A9 OMAP4 days,
> > but never percolated to older SoC erratum documentation. The need of
> > barrier logic was clarified with SoC folks to confirm the behavior though.
> 
> -0-
> After looking up i688 in data base and reviewing AM335x SOC I do NOT think 
> i688 will exhibit for AM335x.
>  - it appears not to be using pieces which have issues on path.
> 
> I688 could impact SOCs which use a DMM and the interconnect infrastructure 
> which supports it.
> 
> I believe hang issues on path could be mapped to 3 sources:
>   - asyncbrige used from MPUSS to Arteris NOC to DMM
>   - Dual EMIF idle (ocp-connect/disconnect) policy on path
>   - PL310 idle signal usage on path
> 
> SOCs using similar chassis components of OMAP4430 time are impacted.  Errata 
> aspect in generic bridge map to Aegis, J5E, ...
> 
> The hangs are brought out by enabling power management features which causes 
> micro-idles on path which can trigger a lock up.
> 
> Later SOCs pulled in fixes in one or all areas.  Some SOCs are not using 
> components.

So please help me to get this straight:

Errata I688 only affects OMAP4 which is consequently the only user of
omap_interconnect_sync() in it's WFI enter sequence, which in turn is
the only user of the SRAM scratch area to work around the erratum.

The OMAP specific barrier implementation which should be used also on
other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
the strongly ordered access.

So it is safe to say that we only ever need to run the initcall
allocating the SRAM scratch area on OMAP4.

Is this conclusion correct?

Thanks,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 12/10/15 21:28, Tony Lindgren wrote:

* Tony Lindgren  [151012 13:27]:

* Sudeep Holla  [150921 08:52]:

The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system
from a suspended state, enable_irq_wake is recommended to be used for
the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.


Applying into omap-for-v4.4/cleanup thanks.


Actually I don't think this does the right thing. The interrupts
in the $subject patch are in the always on powerdomain, and we really


Agreed


want them to be excluded from the suspend.



OK but what's wrong with this patch. At-least the name suggest it's a
wakeup interrupt. And using IRQF_NO_SUSPEND for the wakeup interrupt is
simply wrong.


So not applying without further explanations.



But I don't understand the real need for IRQF_NO_SUSPEND over wakeup APIs ?

--
Regards,
Sudeep
--
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 11/25] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

[Peter Ujfalusi]

On 10/13/2015 11:58 AM, Peter Ujfalusi wrote:
> On 10/12/2015 07:00 PM, Vinod Koul wrote:
>> On Thu, Sep 24, 2015 at 01:01:58PM +0300, Peter Ujfalusi wrote:
>>> Move the code out from arch/arm/common and merge it inside of the dmaengine
>>> driver.
>>> This change is done with as minimal change to the code as possible to avoid
>>> any possibilities to introducing regression.
>>
>> Is this a pure move patch or code has been modified, if latter am
>> disappointed that existing code style issue have not been fixed
> 
> Yes, it is mostly code move, I have done minimal changes only needed to get
> the moved code working in the new location.
> Patch 13 in this series will go through the file and will fix up most (I hope
> all) of the outstanding coding style issues.
> At this point I wanted to have as small change as possible.

But fair enough, I will resend the series with checkpatch fixes done for this
patch.

-- 
Péter
--
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] spi: spi-ti-qspi: switch to polling mode for better r/w performance

[Vignesh R]

Currently word completion interrupt is fired for transfer of every
word(8bit to 128bit in size). This adds a lot of overhead, and decreases
r/w throughput. It hardly takes 3us(@48MHz) for 128bit r/w to complete,
hence its better to poll on word complete bit to be set in
QSPI_SPI_STATUS_REG instead of using interrupts.
This increases the throughput by 30% in both read and write case.

So, switch to polling mode instead of interrupts to determine completion
of word transfer.

Signed-off-by: Vignesh R 
---

Tested on DRA74 Rev G EVM.

 drivers/spi/spi-ti-qspi.c | 74 +--
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 81b84858cfee..69c1a95b0615 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -39,8 +39,6 @@ struct ti_qspi_regs {
 };
 
 struct ti_qspi {
-   struct completion   transfer_complete;
-
/* list synchronization */
struct mutexlist_lock;
 
@@ -62,10 +60,6 @@ struct ti_qspi {
 
 #define QSPI_PID   (0x0)
 #define QSPI_SYSCONFIG (0x10)
-#define QSPI_INTR_STATUS_RAW_SET   (0x20)
-#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
-#define QSPI_INTR_ENABLE_SET_REG   (0x28)
-#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
 #define QSPI_SPI_CLOCK_CNTRL_REG   (0x40)
 #define QSPI_SPI_DC_REG(0x44)
 #define QSPI_SPI_CMD_REG   (0x48)
@@ -97,7 +91,6 @@ struct ti_qspi {
 #define QSPI_RD_DUAL   (3 << 16)
 #define QSPI_RD_QUAD   (7 << 16)
 #define QSPI_INVAL (4 << 16)
-#define QSPI_WC_CMD_INT_EN (1 << 14)
 #define QSPI_FLEN(n)   ((n - 1) << 0)
 #define QSPI_WLEN_MAX_BITS 128
 #define QSPI_WLEN_MAX_BYTES16
@@ -106,10 +99,6 @@ struct ti_qspi {
 #define BUSY   0x01
 #define WC 0x02
 
-/* INTERRUPT REGISTER */
-#define QSPI_WC_INT_EN (1 << 1)
-#define QSPI_WC_INT_DISABLE(1 << 1)
-
 /* Device Control */
 #define QSPI_DD(m, n)  (m << (3 + n * 8))
 #define QSPI_CKPHA(n)  (1 << (2 + n * 8))
@@ -217,6 +206,24 @@ static inline u32 qspi_is_busy(struct ti_qspi *qspi)
return stat & BUSY;
 }
 
+static inline int ti_qspi_poll_wc(struct ti_qspi *qspi)
+{
+   u32 stat;
+   unsigned long timeout = jiffies + QSPI_COMPLETION_TIMEOUT;
+
+   do {
+   stat = ti_qspi_read(qspi, QSPI_SPI_STATUS_REG);
+   if (stat & WC)
+   return 0;
+   cpu_relax();
+   } while (time_after(timeout, jiffies));
+
+   stat = ti_qspi_read(qspi, QSPI_SPI_STATUS_REG);
+   if (stat & WC)
+   return 0;
+   return  -ETIMEDOUT;
+}
+
 static int qspi_write_msg(struct ti_qspi *qspi, struct spi_transfer *t)
 {
int wlen, count, xfer_len;
@@ -275,8 +282,7 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
}
 
ti_qspi_write(qspi, cmd, QSPI_SPI_CMD_REG);
-   if (!wait_for_completion_timeout(>transfer_complete,
-QSPI_COMPLETION_TIMEOUT)) {
+   if (ti_qspi_poll_wc(qspi)) {
dev_err(qspi->dev, "write timed out\n");
return -ETIMEDOUT;
}
@@ -315,8 +321,7 @@ static int qspi_read_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
return -EBUSY;
 
ti_qspi_write(qspi, cmd, QSPI_SPI_CMD_REG);
-   if (!wait_for_completion_timeout(>transfer_complete,
-QSPI_COMPLETION_TIMEOUT)) {
+   if (ti_qspi_poll_wc(qspi)) {
dev_err(qspi->dev, "read timed out\n");
return -ETIMEDOUT;
}
@@ -388,9 +393,7 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,
qspi->cmd = 0;
qspi->cmd |= QSPI_EN_CS(spi->chip_select);
qspi->cmd |= QSPI_FLEN(frame_length);
-   qspi->cmd |= QSPI_WC_CMD_INT_EN;
 
-   ti_qspi_write(qspi, QSPI_WC_INT_EN, QSPI_INTR_ENABLE_SET_REG);
ti_qspi_write(qspi, qspi->dc, QSPI_SPI_DC_REG);
 
mutex_lock(>list_lock);
@@ -417,31 +420,6 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,
return status;
 }
 
-static irqreturn_t ti_qspi_isr(int irq, void *dev_id)
-{
-   struct ti_qspi *qspi = dev_id;
-   u16 int_stat;
-   u32 stat;
-
-   irqreturn_t ret = IRQ_HANDLED;
-
-   int_stat = ti_qspi_read(qspi, QSPI_INTR_STATUS_ENABLED_CLEAR);
-   stat = ti_qspi_read(qspi, QSPI_SPI_STATUS_REG);
-
-   if (!int_stat) {
-   dev_dbg(qspi->dev, "No IRQ triggered\n");
-   ret = IRQ_NONE;
-   

Re: [PATCH v2 0/3] arm:irchip: IRQCHIP_DECLARE macro is now accessible

[Shawn Guo]

On Tue, Oct 13, 2015 at 02:56:12PM +0200, Joel Porquet wrote:
> The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
> globally accessible.
> 
> See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d ("irqchip: Move
> IRQCHIP_DECLARE macro to include/linux/irqchip.h").
> 
> This series of patches add inclusions of 'include/linux/irqchip.h' and
> replaces uses of macro OF_DECLARE_2 with IRQCHIP_DECLARE for platforms
> exynos, imx and omap2.
> 
> I had submitted a single patch a few months ago
> (https://lkml.org/lkml/2015/7/7/1069), but it never got merged although it
> had been acked by all the subsystem maintainers. Hopefully, splitting the
> patch into these independent patches that can be applied separately should
> help.
> 
> Joël
> 
> Joel Porquet (3):
>   arm:exynos: IRQCHIP_DECLARE macro is now accessible
>   arm:imx: IRQCHIP_DECLARE macro is now accessible
>   arm:omap2: IRQCHIP_DECLARE macro is now accessible
> 
>  arch/arm/mach-exynos/suspend.c   | 3 ++-
>  arch/arm/mach-imx/gpc.c  | 7 ++-
>  arch/arm/mach-omap2/omap-wakeupgen.c | 7 ++-
>  3 files changed, 6 insertions(+), 11 deletions(-)

Marc sent a patch [1] doing the same thing a few days ago.

Shawn

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/444136
--
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: DRA7: hwmod: Remove elm address space from hwmod data

[Franklin S Cooper Jr]

ELM address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..ad2cc7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
.master = _l4_per1_hwmod,
.slave  = _elm_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.1

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

Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Dirk Behme]

On 13.10.2015 07:29, Heiko Schocher wrote:

On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.

E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.

Signed-off-by: Heiko Schocher 
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"



The last attempt I remember is from last year


http://www.spinics.net/lists/linux-mmc/msg26586.html

http://www.spinics.net/lists/linux-mmc/msg26588.html


I can't remember why this wasn't accepted, too. But maybe searching 
the archives will help answering that.



Best regards

Dirk



I adapt this to the omap_hsmmc driver.

Is there another solution for this problem?
Or why was this patch not accepted to mainline?

  drivers/mmc/card/block.c  | 6 --
  drivers/mmc/host/omap_hsmmc.c | 6 ++
  include/linux/mmc/host.h  | 3 +++
  3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;

-   devidx = find_first_zero_bit(dev_use, max_devices);
+   devidx = find_next_zero_bit(dev_use, max_devices,
+   card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
 * index anymore so we keep track of a name index.
 */
if (!subname) {
-   md->name_idx = find_first_zero_bit(name_use, max_devices);
+   md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;

+   if (pdev->dev.of_node) {
+   ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+   if (ret >= 0)
+   host->mmc->devidx = ret;
+   }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */

+   /* preferred mmc block device index (mmcblkX) */
+   unsigned intdevidx;
+
unsigned long   private[0] cacheline_aligned;
  };




--
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] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Tom Rini]

On Tue, Oct 13, 2015 at 08:24:08AM -0500, Nishanth Menon wrote:
> On Tue, Oct 13, 2015 at 3:03 AM, Lokesh Vutla  wrote:
> >
> >
> > On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> >> Hello Lokesh,
> >>
> >> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
> >>> +Nishanth,
> >>>
> >>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>  On embedded devices, often there is a combination of
>  removable mmc devices (e.g. MMC/SD cards) and hard
>  wired ones (e.g. eMMC). Depending on the hardware
>  configuration, the 'mmcblkN' node might change if
>  the removable device is available or not at boot time.
> 
>  E.g. if the removable device is attached at boot time,
>  it might become mmxblk0. And the hard wired one mmcblk1.
>  But if the removable device isn't there at boot time,
>  the hard wired one will become mmcblk0. This makes it
>  somehow difficult to hard code the root device to the
>  non-removable device and boot fast.
> >>>
> >>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
> >>> mmcblk no?
> >>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
> >>> does this in u-boot.
> >>
> >> Good tip ... I do not know, if it is possible to update U-Boot
> >> on this boards...
> >>
> >> Current U-Boot says:
> >> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
> >>
> >> I2C:   ready
> >> DRAM:  512 MiB
> >> [...]
> >> U-Boot# mmc rescan
> >> U-Boot# mmc part
> >>
> >> Partition Map for MMC device 0  --   Partition Type: DOS
> >>
> >> PartStart SectorNum Sectors UUIDType
> >>   1 63  144522  000ce343-01 0e Boot
> >>   2 144585  659861  000ce343-02 83
> >> U-Boot# part uuid mmc 0:2 uuid
> >> Unknown command 'part' - try 'help'
> >> U-Boot#
> >>
> >> So, if this patch has no chance for mainline, please let me
> >> know it, thanks!
> >>
> >
> > IIRC, Nishanth had posted a patch something similar but got rejected for
> > some reason. Probably Nishanth can comment more here.
> >
> 
> overall the feedback I received was for block devices, there is
> already an unique method(PARTUUID/uuid) of referencing required device
> and mmcxblky aliasing was not really needed - hence dropped my patch
> and switched over to partuuid.

Not telling the kernel what to do here but root=PARTUUID=$x is the long
standing portable multi-architecture (and storage medium) way to have a
stable name for your root device.  The automatic way of digging this
information out in U-Boot is dates back to Sept 2012 in mainline.

-- 
Tom


signature.asc
Description: Digital signature

Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Shawn Guo]

On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote:
> Laurent Pinchart (37):
...
>   ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
...
>   ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
...
>   ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
>   ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
>   ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
>   ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
>   ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
>   ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
>   ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
>   ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity

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

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Rolf Peukert]

On 13.10.2015 10:15, Tero Kristo wrote:
> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
>> interface and function clocks for the M-USB controller. These calls fail
>> in the current kernel. This patch adds clock definitions containing the
>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>> am35x.c can succeed.
>>
>> Signed-off-by:  Rolf Peukert 
>>
>> ---
>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> index 8831e1a..b635deb 100644
>> --- a/drivers/clk/ti/clk-3xxx.c
>> +++ b/drivers/clk/ti/clk-3xxx.c
>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>>
> 
> Adding clock aliases should be avoided, isn't there any other way to fix
> this issue? Like adding clocks = <> references under the DT node?
> 
> -Tero
> 

Yes, I just tried adding the lines

clocks = <_ick_am35xx>, <_fck_am35xx>;
clock-names = "ick", "fck";

to am3517.dtsi and this works too. But wouldn't this mean the driver
will not work anymore in kernels without DT support?
(my first idea was to change the clk_get calls in am35x.c, but Felipe
Balbi objected)

Best regards,
Rolf

--
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] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Nishanth Menon]

On Tue, Oct 13, 2015 at 3:03 AM, Lokesh Vutla  wrote:
>
>
> On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
>> Hello Lokesh,
>>
>> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>>> +Nishanth,
>>>
>>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
 On embedded devices, often there is a combination of
 removable mmc devices (e.g. MMC/SD cards) and hard
 wired ones (e.g. eMMC). Depending on the hardware
 configuration, the 'mmcblkN' node might change if
 the removable device is available or not at boot time.

 E.g. if the removable device is attached at boot time,
 it might become mmxblk0. And the hard wired one mmcblk1.
 But if the removable device isn't there at boot time,
 the hard wired one will become mmcblk0. This makes it
 somehow difficult to hard code the root device to the
 non-removable device and boot fast.
>>>
>>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>>> mmcblk no?
>>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>>> does this in u-boot.
>>
>> Good tip ... I do not know, if it is possible to update U-Boot
>> on this boards...
>>
>> Current U-Boot says:
>> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
>>
>> I2C:   ready
>> DRAM:  512 MiB
>> [...]
>> U-Boot# mmc rescan
>> U-Boot# mmc part
>>
>> Partition Map for MMC device 0  --   Partition Type: DOS
>>
>> PartStart SectorNum Sectors UUIDType
>>   1 63  144522  000ce343-01 0e Boot
>>   2 144585  659861  000ce343-02 83
>> U-Boot# part uuid mmc 0:2 uuid
>> Unknown command 'part' - try 'help'
>> U-Boot#
>>
>> So, if this patch has no chance for mainline, please let me
>> know it, thanks!
>>
>
> IIRC, Nishanth had posted a patch something similar but got rejected for
> some reason. Probably Nishanth can comment more here.
>

overall the feedback I received was for block devices, there is
already an unique method(PARTUUID/uuid) of referencing required device
and mmcxblky aliasing was not really needed - hence dropped my patch
and switched over to partuuid.

CC Tom and u-boot list as well.
for reference the current thread: http://marc.info/?t=14447142172=1=2
-- 
---
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: [PATCH] ARM: DRA7: hwmod: Remove elm address space from hwmod data

[Lokesh Vutla]

On Tuesday 13 October 2015 07:14 PM, Franklin S Cooper Jr wrote:
> ELM address information is provided by device tree. No longer need
> to include this information within hwmod.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247b..ad2cc7a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if 
> dra7xx_l3_main_1__hdmi = {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> -static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
> - {
> - .pa_start   = 0x48078000,
> - .pa_end = 0x48078fff,
> - .flags  = ADDR_TYPE_RT
> - },
> - { }
> -};
> -
>  /* l4_per1 -> elm */
>  static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
>   .master = _l4_per1_hwmod,
>   .slave  = _elm_hwmod,
>   .clk= "l3_iclk_div",
> - .addr   = dra7xx_elm_addrs,
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Russell King - ARM Linux]

On Tue, Oct 13, 2015 at 12:10:45PM +, Woodruff, Richard wrote:
> > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > Sent: Tuesday, October 13, 2015 5:01 AM
> 
> > So please help me to get this straight:
> > 
> > Errata I688 only affects OMAP4 which is consequently the only user of
> > omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> > the only user of the SRAM scratch area to work around the erratum.
> > 
> > The OMAP specific barrier implementation which should be used also on
> > other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> > the strongly ordered access.
> > 
> > So it is safe to say that we only ever need to run the initcall
> > allocating the SRAM scratch area on OMAP4.
> 
> There are 2 separate things here.  One is the bus sync function and the
> other is the errata which requires a bus sync near WFI to avoid an errata.
> 
> The rational for the bus sync is similar to why there is a writel() and a
> writel_releaxed().  The bus sync has been used for a long time to ensure
> writes have landed and are not stuck in some posting buffer on path.
> 
> A lot of historical drivers use a writel() where perhaps they could choose
> a more granular construct.  If drivers were audited maybe the bus sync
> could be minimized on writel() path.

No, we're not going around that discussion loop again.

Linux requirements are that writel() at the CPU should be ordered with
respect to other writel()s and memory accesses which occur before the
writel().

However, buffering of the write by down-stream busses is permitted, and
where drivers want to ensure that the write has hit the device, a
read-back must be performed.  This requirement comes directly from the
PCI specification, and is *not* actually something that is specific to
Linux.  Linux only adopts it from PCI.

We're not going to ever relax these rules: if people want to perform
accesses which do not conform to the above, they are free to - if they
don't care about the timing of the write hitting the device, they can
omit the read-back.  If they don't care about the write being ordered,
they can use writel_relaxed() (relaxed, because it doesn't have the
ordering guarantees of standard writel().)

It's up to the driver author to use the correct accessor(s) in their
drivers.  It's not for the architecture to decide that it can relax
these rules (if it does, it risks breaking a load of drivers out there.)

So, if people want to avoid the expensive OMAP bus sync on every access
in their drivers, they _have_ to consider whether each load or store
needs to be ordered.  In general, a sequence of writes to a device
should be implemented as a sequence of writel_relaxed(), and if it needs
to be ordered, the last write should be a writel() or accompanied by a
barrier.  An example of this would be writing DMA controller configuration.
All those writes should be writel_relaxed() except for the final writel()
which kicks off the DMA operation.

If you implement drivers using nothing but writel() and readl(), then your
performance _will_ suck, but that's entirely the driver's fault.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] arm:exynos: IRQCHIP_DECLARE macro is now accessible

[Joel Porquet]

The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
globally accessible.

See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d ("irqchip: Move
IRQCHIP_DECLARE macro to include/linux/irqchip.h").

This patch adds the inclusion of 'include/linux/irqchip.h' and replaces the
use of OF_DECLARE_2 with IRQCHIP_DECLARE.

Signed-off-by: Joel Porquet 
---
 arch/arm/mach-exynos/suspend.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index e00eb39..dfb1fcf 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -262,7 +263,7 @@ static int __init exynos_pmu_irq_init(struct device_node 
*node,
return 0;
 }
 
-#define EXYNOS_PMU_IRQ(symbol, name)   OF_DECLARE_2(irqchip, symbol, name, 
exynos_pmu_irq_init)
+#define EXYNOS_PMU_IRQ(symbol, name)   IRQCHIP_DECLARE(symbol, name, 
exynos_pmu_irq_init)
 
 EXYNOS_PMU_IRQ(exynos3250_pmu_irq, "samsung,exynos3250-pmu");
 EXYNOS_PMU_IRQ(exynos4210_pmu_irq, "samsung,exynos4210-pmu");
-- 
2.6.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 v2 2/3] arm:imx: IRQCHIP_DECLARE macro is now accessible

[Joel Porquet]

The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
globally accessible.

See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d ("irqchip: Move
IRQCHIP_DECLARE macro to include/linux/irqchip.h").

This patch adds the inclusion of 'include/linux/irqchip.h' and replaces the
use of OF_DECLARE_2 with IRQCHIP_DECLARE.

Signed-off-by: Joel Porquet 
---
 arch/arm/mach-imx/gpc.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 8c4467f..c7de608 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -269,11 +270,7 @@ static int __init imx_gpc_init(struct device_node *node,
return 0;
 }
 
-/*
- * We cannot use the IRQCHIP_DECLARE macro that lives in
- * drivers/irqchip, so we're forced to roll our own. Not very nice.
- */
-OF_DECLARE_2(irqchip, imx_gpc, "fsl,imx6q-gpc", imx_gpc_init);
+IRQCHIP_DECLARE(imx_gpc, "fsl,imx6q-gpc", imx_gpc_init);
 
 void __init imx_gpc_check_dt(void)
 {
-- 
2.6.1

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

RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Tuesday, October 13, 2015 5:01 AM

> So please help me to get this straight:
> 
> Errata I688 only affects OMAP4 which is consequently the only user of
> omap_interconnect_sync() in it's WFI enter sequence, which in turn is
> the only user of the SRAM scratch area to work around the erratum.
> 
> The OMAP specific barrier implementation which should be used also on
> other SoCs does not need any SRAM scratch, but uses a part of DRAM to do
> the strongly ordered access.
> 
> So it is safe to say that we only ever need to run the initcall
> allocating the SRAM scratch area on OMAP4.

There are 2 separate things here.  One is the bus sync function and the other 
is the errata which requires a bus sync near WFI to avoid an errata.

The rational for the bus sync is similar to why there is a writel() and a 
writel_releaxed().  The bus sync has been used for a long time to ensure writes 
have landed and are not stuck in some posting buffer on path.   

A lot of historical drivers use a writel() where perhaps they could choose a 
more granular construct.  If drivers were audited maybe the bus sync could be 
minimized on writel() path.  Some writel's could be converted to use something 
like an mmiowb () or some appropriate option.  There is a lot of good 
information in the 
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt 
document.  It seems every time I scan it some new aspect comes out.   

For many product launches I was part of in mobile >24 hour robustness was not 
achievable in non-trivial use cases without the serializing bus sync.  For 
CortexA9 ARM pushed in pl310sync and we added a bit to flush the interconnect 
posting buffer.   For a time in the mainline tree the bus sync's fell out as it 
seemed to complicate single kernel booting.   This has the effect of opening up 
folks to sparse hang issues like found in i688.  Re-closing this issue is the 
point of this mail series.

Regards,
Richard W.

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

RE: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x

[Woodruff, Richard]

> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, October 13, 2015 7:24 AM



> If you implement drivers using nothing but writel() and readl(), then your
> performance _will_ suck, but that's entirely the driver's fault.

Your above analysis seems correct.

Perhaps it is wrongheaded but part of the rationalization I used in the past 
was many of the ARM SW drivers evolved from low performance bus architectures 
which didn't punish drivers for forgetting to use a barrier or a read back.  
Many driver porters assumed what was there was good and built atop that.  The 
result was a lot of hidden issues during production ramps.  This is a mix of 
errata, missing read backs, wrong macro choice  (and many valid macro usage 
instances).  A couple SOCs I sampled in the past just used StronlgyOrdered and 
didn't buffer.  This created a lot of 'it works for me not sure of your problem 
is' inputs.

In that environment the question was realized performance vs. correctness.  The 
promotion in heaviness for some of the valid macro usages tended to not be an 
issue as they are sparse.  In cases they were not were in places where a DMA 
engine should have been in use anyway.  The end result of promotion was the 
ability to work around many of the bad with one knob.  I recall consulting 
Linux PowerPC folks (production users of weak memory model) in that time frame 
and they indicated they over synchronized also.  I don't know what they do 
today.

Today, maybe the code has been refactored/evolved enough that the older issues 
have been boiled away but this seems a bit optimistic given history.

Regards,
Richard W.

--
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 v2 0/3] arm:irchip: IRQCHIP_DECLARE macro is now accessible

[Joel Porquet]

The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
globally accessible.

See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d ("irqchip: Move
IRQCHIP_DECLARE macro to include/linux/irqchip.h").

This series of patches add inclusions of 'include/linux/irqchip.h' and
replaces uses of macro OF_DECLARE_2 with IRQCHIP_DECLARE for platforms
exynos, imx and omap2.

I had submitted a single patch a few months ago
(https://lkml.org/lkml/2015/7/7/1069), but it never got merged although it
had been acked by all the subsystem maintainers. Hopefully, splitting the
patch into these independent patches that can be applied separately should
help.

Joël

Joel Porquet (3):
  arm:exynos: IRQCHIP_DECLARE macro is now accessible
  arm:imx: IRQCHIP_DECLARE macro is now accessible
  arm:omap2: IRQCHIP_DECLARE macro is now accessible

 arch/arm/mach-exynos/suspend.c   | 3 ++-
 arch/arm/mach-imx/gpc.c  | 7 ++-
 arch/arm/mach-omap2/omap-wakeupgen.c | 7 ++-
 3 files changed, 6 insertions(+), 11 deletions(-)

-- 
2.6.1

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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> * Pali Rohár  [151012 13:29]:
> > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > > 
> > > Pali, any news on posting an updated series with the comments
> > > addressed in this thread? It seems that we all pretty much agree
> > > what needs to be done.
> > 
> > Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into 
> > CONFIG_KEXEC? Or something more?
> 
> Well for most part your patches are fine, I think there were some
> minor comments on the series.
> 
> For the CONFIG_KEXEC dependency, we should just keep the existing
> behavior and keep /proc/atags behind CONFIG_KEXEC. That's all
> I believe :)
> 
> Regards,
> 
> Tony
> 
> 

Ok. I will add CONFIG_KEXEC into atag patches.

And there is missing documentation for these two new DT properties
(marked as TODO in commit messages). Where to put them?

-- 
Pali Rohár
pali.ro...@gmail.com
--
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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Tony Lindgren]

* Roger Quadros  [151012 23:33]:
> On 13/10/15 03:43, Tony Lindgren wrote:
> > * Roger Quadros  [150918 08:00]:
> >> Add compatible id, GPMC register resource and interrupt
> >> resource to NAND controller nodes.
> >>
> >> The GPMC driver now implements gpiochip and irqchip so
> >> enable gpio-controller and interrupt-controller properties.
> >>
> >> With this the interrupt parent of NAND node changes so fix it
> >> accordingly.
> > ...
> >> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> >> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> >> @@ -35,11 +35,14 @@
> >>  };
> >>  
> >>   {
> >> -  ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
> >> +  ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
> >>  
> >>nand@0,0 {
> >> -  linux,mtd-name = "micron,mt29f4g16abbda3w";
> >> +  compatible = "ti,omap2-nand";
> >>reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
> >> +  interrupt-parent = <>;
> >> +  interrupts = <20>;
> >> +  linux,mtd-name = "micron,mt29f4g16abbda3w";
> >>nand-bus-width = <16>;
> >>ti,nand-ecc-opt = "bch8";
> >>gpmc,sync-clk-ps = <0>;
> > 
> > At least torpedo breaks for NFSroot as NAND now overlaps with
> > Ethernet.. What's the policy you have for moving the addresses
> > around?
> 
> For OMAP3 I intended to use 0x3000 for NAND but incorrectly
> used 0x0800 for the torpedo.

Might be worth adding some documentation of suggested standardized
mappings.. For most of theme we could just add them as 16MB chunks,
then reserve some larger area for NOR?

> Does setting it to 0x3000 work? If not what is the original
> NAND address for this board?

The u-boot addresses are probably what were used in the .dts* files.
Setting NAND to 0x3000 is not enough though, looks like there's
a bug where the logicpd-torpedo-37xx-devkit.dts ranges is missing
the NAND range in logicpd-torpedo-som.dtsi. Something like the
patch below seems to make things work again, might be worth
checking what ranges make sense to standardize on though. Please
feel free to fold it into your patches.

> > There may be other similar cases to check too.
> 
> Just checked that all other OMAP3 boards I've set to 0x3000
> if they were 0x0.

Do you want to reserve a large chunk for NOR at cs0 or what's
the reason for picking 0x3000 for NAND?

I guess NOR can be also on other chipselects.. Not sure we can
standardize on any specific partition scheme?

Regards,

Tony

8< 
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,7 +73,8 @@
 };
 
  {
-   ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
+   ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
+ 1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
 
ethernet@gpmc {
pinctrl-names = "default";
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -35,7 +35,7 @@
 };
 
  {
-   ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
compatible = "ti,omap2-nand";
--
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 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 13/10/15 15:53, Tony Lindgren wrote:

* Sudeep Holla  [151013 03:46]:



On 12/10/15 21:28, Tony Lindgren wrote:

* Tony Lindgren  [151012 13:27]:

* Sudeep Holla  [150921 08:52]:

The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system

>from a suspended state, enable_irq_wake is recommended to be used for

the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.


Applying into omap-for-v4.4/cleanup thanks.


Actually I don't think this does the right thing. The interrupts
in the $subject patch are in the always on powerdomain, and we really


Agreed


want them to be excluded from the suspend.



OK but what's wrong with this patch. At-least the name suggest it's a
wakeup interrupt. And using IRQF_NO_SUSPEND for the wakeup interrupt is
simply wrong.


Hmm so if we have a separate always on irq controller for the wake-up events
and we want to keep it always on and exclude it from any suspend related
things.. Why would we not use IRQF_NO_SUSPEND on it?

Above you say "The IRQF_NO_SUSPEND flag is used to identify the interrupts
that should be left enabled so as to allow them to work as expected during
the suspend-resume cycle..." and that's exactly what we want to do here :)



OK if these interrupts meet that criteria to use IRQF_NO_SUSPEND, then
it should be fine, my earlier argument was based on the assumption that
it's just another wakeup interrupt.


For the dedicated wake-up interrupts, we have separate registers to enable
and disable them. The $subject irq is the shared interrupt that allows
making use of the pin specific wake-up interrupts, and for those yes we
are using enable_irq_wake().



If it's already take care, then fine. I am just hunting all the misuse
of IRQF_NO_SUSPEND flag especially as wakeup source and fixing them


So not applying without further explanations.



But I don't understand the real need for IRQF_NO_SUSPEND over wakeup APIs ?


Because in the $subject case we just want to always keep it on and
never suspend it. It's unrelated to the wakeup APIs at least for the
omap related SoCs.



OK, understood now. Thanks

--
Regards,
Sudeep
--
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 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hi Shawn,

On Tuesday 13 October 2015 22:09:46 Shawn Guo wrote:
> On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote:
> > Laurent Pinchart (37):
> ...
> 
> >   ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
> 
> ...
> 
> >   ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
> 
> ...
> 
> >   ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
> >   ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
> >   ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
> 
> Applied these 15 patches, thanks.

There's ongoing discussions regarding whether this is the right thing to do. 
Please see http://www.spinics.net/lists/arm-kernel/msg451724.html. It's thus a 
bit early to apply the patches at this point I'm afraid.

-- 
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 v2 3/3] arm:omap2: IRQCHIP_DECLARE macro is now accessible

[Joel Porquet]

The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
globally accessible.

See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d ("irqchip: Move
IRQCHIP_DECLARE macro to include/linux/irqchip.h").

This patch adds the inclusion of 'include/linux/irqchip.h' and replaces the
use of OF_DECLARE_2 with IRQCHIP_DECLARE.

Signed-off-by: Joel Porquet 
---
 arch/arm/mach-omap2/omap-wakeupgen.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
b/arch/arm/mach-omap2/omap-wakeupgen.c
index e1d2e99..a2dc324 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -538,8 +539,4 @@ static int __init wakeupgen_init(struct device_node *node,
return 0;
 }
 
-/*
- * We cannot use the IRQCHIP_DECLARE macro that lives in
- * drivers/irqchip, so we're forced to roll our own. Not very nice.
- */
-OF_DECLARE_2(irqchip, ti_wakeupgen, "ti,omap4-wugen-mpu", wakeupgen_init);
+IRQCHIP_DECLARE(ti_wakeupgen, "ti,omap4-wugen-mpu", wakeupgen_init);
-- 
2.6.1

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

Re: [PATCH 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Sudeep Holla  [151013 03:46]:
> 
> 
> On 12/10/15 21:28, Tony Lindgren wrote:
> >* Tony Lindgren  [151012 13:27]:
> >>* Sudeep Holla  [150921 08:52]:
> >>>The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> >>>be left enabled so as to allow them to work as expected during the
> >>>suspend-resume cycle, but doesn't guarantee that it will wake the system
> >>>from a suspended state, enable_irq_wake is recommended to be used for
> >>>the wakeup.
> >>>
> >>>This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> >>>enable_irq_wake instead.
> >>
> >>Applying into omap-for-v4.4/cleanup thanks.
> >
> >Actually I don't think this does the right thing. The interrupts
> >in the $subject patch are in the always on powerdomain, and we really
> 
> Agreed
> 
> >want them to be excluded from the suspend.
> >
> 
> OK but what's wrong with this patch. At-least the name suggest it's a
> wakeup interrupt. And using IRQF_NO_SUSPEND for the wakeup interrupt is
> simply wrong.

Hmm so if we have a separate always on irq controller for the wake-up events
and we want to keep it always on and exclude it from any suspend related
things.. Why would we not use IRQF_NO_SUSPEND on it?

Above you say "The IRQF_NO_SUSPEND flag is used to identify the interrupts
that should be left enabled so as to allow them to work as expected during
the suspend-resume cycle..." and that's exactly what we want to do here :)

For the dedicated wake-up interrupts, we have separate registers to enable
and disable them. The $subject irq is the shared interrupt that allows
making use of the pin specific wake-up interrupts, and for those yes we
are using enable_irq_wake().

> >So not applying without further explanations.
> >
> 
> But I don't understand the real need for IRQF_NO_SUSPEND over wakeup APIs ?

Because in the $subject case we just want to always keep it on and
never suspend it. It's unrelated to the wakeup APIs at least for the
omap related SoCs.

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 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Shawn Guo]

On Tue, Oct 13, 2015 at 05:17:24PM +0300, Laurent Pinchart wrote:
> Hi Shawn,
> 
> On Tuesday 13 October 2015 22:09:46 Shawn Guo wrote:
> > On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote:
> > > Laurent Pinchart (37):
> > ...
> > 
> > >   ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
> > 
> > ...
> > 
> > >   ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
> > 
> > ...
> > 
> > >   ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
> > >   ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
> > 
> > Applied these 15 patches, thanks.
> 
> There's ongoing discussions regarding whether this is the right thing to do. 
> Please see http://www.spinics.net/lists/arm-kernel/msg451724.html. It's thus 
> a 
> bit early to apply the patches at this point I'm afraid.

Okay, dropped them except the first one which fixes a typo for
imx6sx-sdb.

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

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Felipe Balbi]

Hi,

Rolf Peukert  writes:
> On 13.10.2015 10:15, Tero Kristo wrote:
>> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
>>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
>>> interface and function clocks for the M-USB controller. These calls fail
>>> in the current kernel. This patch adds clock definitions containing the
>>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>>> am35x.c can succeed.
>>>
>>> Signed-off-by:  Rolf Peukert 
>>>
>>> ---
>>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>>> index 8831e1a..b635deb 100644
>>> --- a/drivers/clk/ti/clk-3xxx.c
>>> +++ b/drivers/clk/ti/clk-3xxx.c
>>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>>>
>> 
>> Adding clock aliases should be avoided, isn't there any other way to fix
>> this issue? Like adding clocks = <> references under the DT node?
>> 
>> -Tero
>> 
>
> Yes, I just tried adding the lines
>
>   clocks = <_ick_am35xx>, <_fck_am35xx>;
>   clock-names = "ick", "fck";
>
> to am3517.dtsi and this works too. But wouldn't this mean the driver
> will not work anymore in kernels without DT support?

I have this doubt myself. This will break on non-DT boots and, while
we're trying to move to DT-only, IMO meanwhile we should allow for fixes
to DT and non-DT world. Once the conversion is done, fine.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro

[Laurent Pinchart]

Use the macro instead of absolute register offsets to make the code more
readable as the values now match register addresses from the datasheet.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/omap3-igep.dtsi | 48 +++
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index a2f97928297d..09a438ebfbbe 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -35,60 +35,60 @@
 _pmx_core {
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
-   0x152 (PIN_INPUT | MUX_MODE0)   /* 
uart1_rx.uart1_rx */
-   0x14c (PIN_OUTPUT |MUX_MODE0)   /* 
uart1_tx.uart1_tx */
+   OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)
/* uart1_rx.uart1_rx */
+   OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)   
/* uart1_tx.uart1_tx */
>;
};
 
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = <
-   0x16e (PIN_INPUT | MUX_MODE0)   /* 
uart3_rx.uart3_rx */
-   0x170 (PIN_OUTPUT | MUX_MODE0)  /* 
uart3_tx.uart3_tx */
+   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
/* uart3_rx.uart3_rx */
+   OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)   
/* uart3_tx.uart3_tx */
>;
};
 
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins = <
-   0x10c (PIN_INPUT | MUX_MODE0)   /* 
mcbsp2_fsx.mcbsp2_fsx */
-   0x10e (PIN_INPUT | MUX_MODE0)   /* 
mcbsp2_clkx.mcbsp2_clkx */
-   0x110 (PIN_INPUT | MUX_MODE0)   /* 
mcbsp2_dr.mcbsp2.dr */
-   0x112 (PIN_OUTPUT | MUX_MODE0)  /* 
mcbsp2_dx.mcbsp2_dx */
+   OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
/* mcbsp2_fsx.mcbsp2_fsx */
+   OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
/* mcbsp2_clkx.mcbsp2_clkx */
+   OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
/* mcbsp2_dr.mcbsp2.dr */
+   OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)   
/* mcbsp2_dx.mcbsp2_dx */
>;
};
 
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
-   0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_clk.sdmmc1_clk */
-   0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_cmd.sdmmc1_cmd */
-   0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat0.sdmmc1_dat0 */
-   0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat1.sdmmc1_dat1 */
-   0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat2.sdmmc1_dat2 */
-   0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat3.sdmmc1_dat3 */
+   OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_clk.sdmmc1_clk */
+   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_cmd.sdmmc1_cmd */
+   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat0.sdmmc1_dat0 */
+   OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat1.sdmmc1_dat1 */
+   OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat2.sdmmc1_dat2 */
+   OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat3.sdmmc1_dat3 */
>;
};
 
mmc2_pins: pinmux_mmc2_pins {
pinctrl-single,pins = <
-   0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_clk.sdmmc2_clk */
-   0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_cmd.sdmmc2_cmd */
-   0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat0.sdmmc2_dat0 */
-   0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat1.sdmmc2_dat1 */
-   0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat2.sdmmc2_dat2 */
-   0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat3.sdmmc2_dat3 */
+   OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_clk.sdmmc2_clk */
+   OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_cmd.sdmmc2_cmd */
+   OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat0.sdmmc2_dat0 */
+   OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat1.sdmmc2_dat1 */
+   OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | 

Re: [PATCH] ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro

[Javier Martinez Canillas]

Hello Laurent,

Thanks a lot for the patch.

On Tue, Oct 13, 2015 at 7:31 PM, Laurent Pinchart
 wrote:
> Use the macro instead of absolute register offsets to make the code more
> readable as the values now match register addresses from the datasheet.
>
> Signed-off-by: Laurent Pinchart 
> ---

Agreed with the patch and in fact I had the same change in my TODO list.

I didn't double check the values against the TRM but I trust you ;-)

Acked-by: Javier Martinez Canillas 

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 2/2] gpio: omap: convert to use generic irq handler

[Thomas Gleixner]

Grygorii,

On Tue, 13 Oct 2015, Grygorii Strashko wrote:
> I'd very appreciate for any advice of how to better proceed with your request.
>  - I can try to apply and re-send only patches marked by '*'
>  - I can prepare branch with all above patches

Please provide a branch on top of 4.1.10 which contains the whole
lot. I have a look at it and decide then how to go from there.

Thanks,

tglx
--
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/3] ARM: dts: Add basic support for isee igepv5

[Tony Lindgren]

With omap5-board-common.dtsi, we can now easily add support for various omap5
board variants. Let's add minimal support for isee igepv5.

So far I've tested that basic things work, such as serial, USB Ethernet, HDMI
and WLAN.

Note that like omap5-uevm, these boards seem to need to reserve 16MB for a
trap section as in commit 03178c66d289 ("ARM: dts: omap5-evm: Update
available memory to 2032 MB") and also noted in a u-boot commit at
http://marc.info/?l=u-boot=134376852603255 and also at
http://patchwork.ozlabs.org/patch/159881/.

Not sure why this is not needed for omap5-cm-t54.dts, maybe because of
different u-boot configuration.

Signed-off-by: Tony Lindgren 
---

Enric, can you please check if there are some critical pieces compared
to omap5-uevm that should be updated for this patch?

---
 arch/arm/boot/dts/Makefile   |  1 +
 arch/arm/boot/dts/omap5-igep0050.dts | 54 
 2 files changed, 55 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-igep0050.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e45d771..2c12411 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -471,6 +471,7 @@ dtb-$(CONFIG_SOC_AM43XX) += \
am437x-gp-evm.dtb
 dtb-$(CONFIG_SOC_OMAP5) += \
omap5-cm-t54.dtb \
+   omap5-igep0050.dtb \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
 dtb-$(CONFIG_SOC_DRA7XX) += \
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts 
b/arch/arm/boot/dts/omap5-igep0050.dts
new file mode 100644
index 000..46ecb1d
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "omap5-board-common.dtsi"
+
+/ {
+   model = "IGEPv5";
+   compatible = "isee,omap5-igep0050", "ti,omap5";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x7f00>; /* 2032 MB */
+   };
+};
+
+ {
+   vdda-supply = <_reg>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   tca6416: tca6416@21 {
+   compatible = "ti,tca6416";
+   reg = <0x21>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+};
+
+_pmx_core {
+   i2c4_pins: pinmux_i2c4_pins {
+   pinctrl-single,pins = <
+   OMAP5_IOPAD(0x0f8, PIN_INPUT | MUX_MODE0)   /* 
i2c4_scl */
+   OMAP5_IOPAD(0x0fa, PIN_INPUT | MUX_MODE0)   /* 
i2c4_sda */
+   >;
+   };
+};
+
+ {
+   gpios = < 11 0>,/* TCA6416 P01, CT_CP_HDP */
+   < 12 0>,/* TCA6416 P00, LS_OE*/
+   < 1 0>,   /* 193, HPD */
+   < 2 0>,   /* 194, SCL */
+   < 3 0>;   /* 195, SDA */
+};
+
-- 
2.1.4

--
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/3] ARM: dts: Move most of omap5-uevm.dts to omap5-board-common.dtsi

[Tony Lindgren]

Looks like thevarious omap5-uevm models and igepv5 are very similar. So let's
create omap5-board-common.dtsi to allow fixing up things properly for mainline
kernel to support all these.

Even if we eventually end up having only PMIC + MMC + eMMC + SDIO WLAN + SATA +
USB + HDMI configuration in the omap5-board-common.dtsi, this is the easiest
way to add support for other boards rather than diffing various versions of
out of tree dts files.

My guess is that also omap5-sbc-t54.dts can use this, but I don't have that
board so that will need to be dealt with later on.

Signed-off-by: Tony Lindgren 
---
 .../{omap5-uevm.dts => omap5-board-common.dtsi}|  38 +-
 arch/arm/boot/dts/omap5-uevm.dts   | 662 +
 2 files changed, 17 insertions(+), 683 deletions(-)
 copy arch/arm/boot/dts/{omap5-uevm.dts => omap5-board-common.dtsi} (95%)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
b/arch/arm/boot/dts/omap5-board-common.dtsi
similarity index 95%
copy from arch/arm/boot/dts/omap5-uevm.dts
copy to arch/arm/boot/dts/omap5-board-common.dtsi
index f10b42f..5cf76a1 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -5,21 +5,11 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-/dts-v1/;
-
 #include "omap5.dtsi"
 #include 
 #include 
 
 / {
-   model = "TI OMAP5 uEVM board";
-   compatible = "ti,omap5-uevm", "ti,omap5";
-
-   memory {
-   device_type = "memory";
-   reg = <0x8000 0x7F00>; /* 2032 MB */
-   };
-
aliases {
display0 = 
};
@@ -80,9 +70,7 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 
-   gpios = < 0 GPIO_ACTIVE_HIGH>,/* TCA6424A P01, CT CP 
HPD */
-   < 1 GPIO_ACTIVE_HIGH>,/* TCA6424A P00, LS OE 
*/
-   < 1 GPIO_ACTIVE_HIGH>;/* GPIO 193, HPD */
+   /* gpios defined in the board specific dts */
 
ports {
#address-cells = <1>;
@@ -190,13 +178,6 @@
>;
};
 
-   i2c5_pins: pinmux_i2c5_pins {
-   pinctrl-single,pins = <
-   0x186 (PIN_INPUT | MUX_MODE0)   /* i2c5_scl */
-   0x188 (PIN_INPUT | MUX_MODE0)   /* i2c5_sda */
-   >;
-   };
-
mcspi2_pins: pinmux_mcspi2_pins {
pinctrl-single,pins = <
0xbc (PIN_INPUT | MUX_MODE0)/*  mcspi2_clk 
*/
@@ -587,20 +568,6 @@
};
 };
 
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-
-   clock-frequency = <40>;
-
-   gpio9: gpio@22 {
-   compatible = "ti,tca6424";
-   reg = <0x22>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-};
-
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -674,7 +641,8 @@
 
  {
status = "ok";
-   vdda-supply = <_reg>;
+
+   /* vdda-supply populated in board specific dts file */
 
pinctrl-names = "default";
pinctrl-0 = <_hdmi_pins>;
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index f10b42f..05b1c1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -7,9 +7,7 @@
  */
 /dts-v1/;
 
-#include "omap5.dtsi"
-#include 
-#include 
+#include "omap5-board-common.dtsi"
 
 / {
model = "TI OMAP5 uEVM board";
@@ -19,572 +17,10 @@
device_type = "memory";
reg = <0x8000 0x7F00>; /* 2032 MB */
};
-
-   aliases {
-   display0 = 
-   };
-
-   vmmcsd_fixed: fixedregulator-mmcsd {
-   compatible = "regulator-fixed";
-   regulator-name = "vmmcsd_fixed";
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
-   };
-
-   mmc3_pwrseq: sdhci0_pwrseq {
-   compatible = "mmc-pwrseq-simple";
-   clocks = <>;
-   clock-names = "ext_clock";
-   };
-
-   vmmcsdio_fixed: fixedregulator-mmcsdio {
-   compatible = "regulator-fixed";
-   regulator-name = "vmmcsdio_fixed";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   gpio = < 12 GPIO_ACTIVE_HIGH>;/* gpio140 WLAN_EN */
-   enable-active-high;
-   startup-delay-us = <7>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   };
-
-   /* HS USB Host PHY on PORT 2 */
-   hsusb2_phy: hsusb2_phy {
-   compatible = "usb-nop-xceiv";
-   reset-gpios = < 16 GPIO_ACTIVE_LOW>; /* gpio3_80 
HUB_NRESET */
-   clocks = <_ck>;
-   clock-names = 

[PATCH 1/3] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
device tree bindings for the TI WLAN SDIO on many omap variants.

I recall wondering how come omap5-uevm did not have the WLAN
added and this issue has been bugging me for a while now, and
I finally tracked it down to a bad pinmux regression, and a missing
deferred probe handling for the 32k clock from palmas that's
requested by twl6040.

Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
added pin muxing for mcspi4 that conflicts with the onboard
WLAN. While some omap5-uevm don't have WLAN populated, the
pins are not reused for other devices. And as the SDIO bus
should be probed, let's try to enable WLAN by default.

Let's fix the regression and add the WLAN configuration as
done for the other boards in 99f84cae43df ("ARM: dts: add
wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for
the 32k clock as suggested by Javier Martinez Canillas
.

Note that without a related deferred probe fix for twl6040,
the 32k clock is not initialized if palmas-clk is a module
and twl6040 is built-in.

Let's also use the generic "non-removable" instead of the
legacy "ti,non-removable" property while at it.

And finally, note that omap5 seems to require WAKEUP_EN for
the WLAN GPIO interrupt.

Fixes: 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
Cc: Sourav Poddar 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap5-uevm.dts | 66 +---
 1 file changed, 55 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 4da9e52..f10b42f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,6 +31,24 @@
regulator-max-microvolt = <300>;
};
 
+   mmc3_pwrseq: sdhci0_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   clocks = <>;
+   clock-names = "ext_clock";
+   };
+
+   vmmcsdio_fixed: fixedregulator-mmcsdio {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsdio_fixed";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 12 GPIO_ACTIVE_HIGH>;/* gpio140 WLAN_EN */
+   enable-active-high;
+   startup-delay-us = <7>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   };
+
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
@@ -197,12 +215,20 @@
>;
};
 
-   mcspi4_pins: pinmux_mcspi4_pins {
+   mmc3_pins: pinmux_mmc3_pins {
+   pinctrl-single,pins = <
+   OMAP5_IOPAD(0x01a4, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_clk */
+   OMAP5_IOPAD(0x01a6, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_cmd */
+   OMAP5_IOPAD(0x01a8, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_data0 */
+   OMAP5_IOPAD(0x01aa, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_data1 */
+   OMAP5_IOPAD(0x01ac, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_data2 */
+   OMAP5_IOPAD(0x01ae, PIN_INPUT_PULLUP | MUX_MODE0) /* 
wlsdio_data3 */
+   >;
+   };
+
+   wlan_pins: pinmux_wlan_pins {
pinctrl-single,pins = <
-   0x164 (PIN_INPUT | MUX_MODE1)   /*  mcspi4_clk 
*/
-   0x168 (PIN_INPUT | MUX_MODE1)   /*  mcspi4_simo 
*/
-   0x16a (PIN_INPUT | MUX_MODE1)   /*  mcspi4_somi 
*/
-   0x16c (PIN_INPUT | MUX_MODE1)   /*  mcspi4_cs0 
*/
+   OMAP5_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE6) /* 
mcspi1_clk.gpio5_140 */
>;
};
 
@@ -276,6 +302,12 @@
0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub 
clk */
>;
};
+
+   wlcore_irq_pin: pinmux_wlcore_irq_pin {
+   pinctrl-single,pins = <
+   OMAP5_IOPAD(0x040, WAKEUP_EN | PIN_INPUT_PULLUP | 
MUX_MODE6)/* llia_wakereqin.gpio1_wk14 */
+   >;
+   };
 };
 
  {
@@ -290,8 +322,25 @@
 };
 
  {
+   vmmc-supply = <_fixed>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
-   ti,non-removable;
+   non-removable;
+   cap-power-off-card;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins _irq_pin>;
+   interrupts-extended = < GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH
+  _pmx_core 0x168>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@2 {
+   compatible = "ti,wl1271";
+   reg = <2>;
+   interrupt-parent = <>;
+   interrupts = <14 IRQ_TYPE_LEVEL_HIGH>;  /* gpio 14 */
+  

Re: musb: communication issue with more than 12 FTDI ports

[Felipe Balbi]

Yegor Yefremov  writes:
> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>  wrote:
>> We have a problem, when using more than 12 FTDI ports. Kernels tried:
>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
>>
>> Below the USB topology:
>>
>> # lsusb -t
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>
>> When using 12 ports and performing serial test (a pair of ports is
>> connected via null-modem cable and a rather short string ca. 90
>> characters will be sent alternating at 1200 and 115200b/s, testing
>> scripts are written in Python and running as own processes per a pair
>> of ports) there are no timeouts, i.e. all sent characters will be
>> received. As soon as I open ports 13 and 14 I start to get arbitrary
>> timeouts  (from test software point of view) on all ports.
>>
>> In order to check, if ftdi_sio has primary to do with this issue, I've
>> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
>> there were no issues with 16 ports. So it seems to have something to
>> do with am335x + musb + number of end points.
>>
>> Any idea? Let me know, if you need our test script.
>
> From time to time I get following warnings (4.3.0-rc5):
>
> musb_host_rx 1915: RX1 dma busy, csr 2020
> musb_host_rx 1915: RX4 dma busy, csr 2020
> musb_host_rx 1915: RX7 dma busy, csr 2220
> musb_host_rx 1915: RX1 dma busy, csr 2020
>
> Though they are not timely related to serial test timeouts.

yeah, I don't think MUSB can easily handle that. IIRC, endpoint
scheduling in MUSB is rather bad. While we have enough endpoints to
handle this case, you might be running into some IP (or driver) issues.

Bin, have you ever tested this many serial devices on AM335x ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] gpio: omap: convert to use generic irq handler

[Grygorii Strashko]

Hi Thomas,

On 10/12/2015 10:52 AM, Thomas Gleixner wrote:
> Grygorii,
> 
> can you please provide a patch set against 4.1-RT? That stuff rejects
> left and right.
> 

This is really not easy thing to do :( and I don't know how to do it the best 
way.

This patches are based on top of big set of other patches. As result we've 
back-ported
mostly all GPIO patches from upstream kernel to TI's 4.1 kernel to keep things
consistent and avoid complicated conflicts during back-porting of fixes.
The branch linux-4.1.y-rt is continuously merged in TI's 4.1 rt-kernel.

So, on top of linux-4.1.y there is below set of patches in TI's kernel now:
*bc6b549 gpio: omap: convert to use generic irq handler
*d8b79f8 gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock
c5d9d80 gpio: omap: fix static checker warning
8e3f97d gpio: omap: Fix GPIO numbering for deferred probe
a5fafaa gpio: omap: Fix gpiochip_add() handling for deferred probe
*a79afac gpio: omap: fix clk_prepare/unprepare usage
*e967fb8 gpio: omap: protect regs access in omap_gpio_irq_handler
7f66a45 gpio: omap: fix omap2_set_gpio_debounce
225b622 gpio: omap: switch to use platform_get_irq
4ad92d9 gpio: omap: remove wrong irq_domain_remove usage in probe
f76691a gpio: omap: Fix missing raw locks conversion
*97e1a2c gpio: omap: use raw locks for locking
7a74d02 ARM: OMAP2: Drop the concept of certain power domains not being able to 
lose context.
76281a5 gpio: omap: prevent module from being unloaded while in use
7aa88c9 gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type
79d3bc2 gpio: omap: rework omap_gpio_irq_startup to handle current pin state 
properly
81dcc40 gpio: omap: rework omap_gpio_request to touch only gpio specific 
registers
e44665c gpio: omap: rework omap_x_irq_shutdown to touch only irqs specific 
registers
23c487f gpio: omap: fix error handling in omap_gpio_irq_type
b328dfc gpio: omap: fix omap_gpio_free to not clean up irq configuration
2966641 gpio: omap: Allow building as a loadable module

I'd very appreciate for any advice of how to better proceed with your request.
 - I can try to apply and re-send only patches marked by '*'
 - I can prepare branch with all above patches
 - smth. else


-- 
regards,
-grygorii
--
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: AM37x unable to drive output of some gpio lines (works with 2.6.37)

[Grygorii Strashko]

On 10/12/2015 04:12 PM, Ladislav Michl wrote:
> On Fri, Oct 09, 2015 at 11:45:17AM +0200, Rolf Peukert wrote:
>> On 09.10.2015 02:54, Ladislav Michl wrote:
>>> Hi there!
>>>
>>> on custom AM37x board running 2.6.37 this was enough to enable gpio 67:
>>> echo 71 > /sys/class/gpio/export
>>> echo out > /sys/class/gpio/gpio71/direction
>>> echo 1 > /sys/class/gpio/gpio71/value
>>>
>>> However, with DT configured linux-4.2 compiled using omap2plus_defconfig
>>> this no longer works.
>> [...]
>>
>> Is some other device driver using these pins? Pins 70 and 71 could be
>> DSS or UART1. Maybe you need to set them to "disabled" in your DT.
> 
> Only UART2 is enabled. This should not make difference anyway, as it should
> be matter of mux config and gpio settings. Working GPIO 82 is on the same
> bank as GPIO 71 and to make it work from U-Boot only these registers need
> to be touched:
> => mw.l 0x480020DC 0x40004
> => mw.l 0x480020F4 0x40004
> => mw.l 0x49052034 0xFFF41F3F
> => mw.l 0x4905203C 
> First two writes are mux config, 3rd is direction and the last one is output.
> Both GPIO 71 and 82 could be driven this way. But as long as kernel steps in,
> GPIO 71 no longer works even if I use devmem utility to write relevant
> registers. Just tried 3.19.8 and it does not work either, moving backward
> to the past...
> 

I think You might need to check pin muxing in DT-file. if you have smth like

dss_dpi_pins_cm_t35x: pinmux_dss_dpi_pins_cm_t35x {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   
/* dss_data0.dss_data0 */
OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   
/* dss_data1.dss_data1 */

^ it will not work as gpio.

OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   
/* dss_data2.dss_data2 */
OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   
/* dss_data3.dss_data3 */
OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   
/* dss_data4.dss_data4 */
OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   
/* dss_data5.dss_data5 */
>;
};


-- 
regards,
-grygorii
--
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 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

[Rafael J. Wysocki]

On Monday, September 28, 2015 03:20:44 PM Marc Titinger wrote:
> - change arg3 to a state name string: we got the current CPU rom the trace
> backend already. This also prepares for multiple/named states in the power
> domain, consistent with idle-states. states in the domain may match given
> CPU states in this case, we will trace them by their name, and potentially
> use arg2 as a link to their index for the cpuidle driver.
> 
> - tested with Juno DP
> 
> -0 [000]42.395510: power_domain_target:  a53_pd index=0 
> 'cluster-sleep-0'
> -0 [000]42.395528: cpu_idle: state=4294967295 
> cpu_id=0
> -0 [000]42.395668: cpu_idle: state=2 cpu_id=0
> 
> - compiled for Omap2+
> 
> Signed-off-by: Marc Titinger 

Hi,

What's your intent regarding this series?  Do you want it to be applied
separately, or is it going to be part of a larger series?

Thanks,
Rafael

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

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Sebastian Reichel]

Hi,

On Tue, Oct 13, 2015 at 05:57:59PM -0500, Felipe Balbi wrote:
> Sebastian Reichel  writes:
> > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote:
> >> Rolf Peukert  writes:
> >> > On 13.10.2015 10:15, Tero Kristo wrote:
> >> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
> >> >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
> >> >>> interface and function clocks for the M-USB controller. These calls 
> >> >>> fail
> >> >>> in the current kernel. This patch adds clock definitions containing the
> >> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
> >> >>> am35x.c can succeed.
> >> >>>
> >> >>> Signed-off-by:  Rolf Peukert 
> >> >>>
> >> >>> ---
> >> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
> >> >>>   1 file changed, 2 insertions(+)
> >> >>>
> >> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> >> >>> index 8831e1a..b635deb 100644
> >> >>> --- a/drivers/clk/ti/clk-3xxx.c
> >> >>> +++ b/drivers/clk/ti/clk-3xxx.c
> >> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
> >> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
> >> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
> >> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
> >> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
> >> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
> >> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
> >> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
> >> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
> >> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
> >> >>>
> >> >> 
> >> >> Adding clock aliases should be avoided, isn't there any other way to fix
> >> >> this issue? Like adding clocks = <> references under the DT node?
> >> >> 
> >> >> -Tero
> >> >> 
> >> >
> >> > Yes, I just tried adding the lines
> >> >
> >> >  clocks = <_ick_am35xx>, <_fck_am35xx>;
> >> >  clock-names = "ick", "fck";
> >> >
> >> > to am3517.dtsi and this works too. But wouldn't this mean the driver
> >> > will not work anymore in kernels without DT support?
> >> 
> >> I have this doubt myself. This will break on non-DT boots and, 
> >> while we're trying to move to DT-only, IMO meanwhile we should
> >> allow for fixes to DT and non-DT world. Once the conversion is
> >> done, fine.
> >
> > Isn't am35xx already DT-only? The remaining omap2+ boards are both
> > omap3430 based:
> 
> yeah, and this system is omap3 based, not am335x based ;-)

Sure, am35xx depends on omap3 and omap3 still supports platform
based booting because of the mentioned boards, but that does not
mean, that am35xx also needs to support legacy booting. From what
I can see, the last am35xx board has been removed in v4.0 [0]
together with the am35xx platform headers.

So while omap3 can still be booted the legacy way, am35xx cannot
without modifying the kernel. Other omap3 based SoCs will initialize
musb's omap2430 gluecode, so they are not affected.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=omap-for-v3.20/drop-legacy-3517-v2

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Felipe Balbi]

hi,

Sebastian Reichel  writes:
> Hi,
>
> On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote:
>> Rolf Peukert  writes:
>> > On 13.10.2015 10:15, Tero Kristo wrote:
>> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
>> >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
>> >>> interface and function clocks for the M-USB controller. These calls fail
>> >>> in the current kernel. This patch adds clock definitions containing the
>> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>> >>> am35x.c can succeed.
>> >>>
>> >>> Signed-off-by:  Rolf Peukert 
>> >>>
>> >>> ---
>> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>> >>>   1 file changed, 2 insertions(+)
>> >>>
>> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> >>> index 8831e1a..b635deb 100644
>> >>> --- a/drivers/clk/ti/clk-3xxx.c
>> >>> +++ b/drivers/clk/ti/clk-3xxx.c
>> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>> >>>
>> >> 
>> >> Adding clock aliases should be avoided, isn't there any other way to fix
>> >> this issue? Like adding clocks = <> references under the DT node?
>> >> 
>> >> -Tero
>> >> 
>> >
>> > Yes, I just tried adding the lines
>> >
>> >clocks = <_ick_am35xx>, <_fck_am35xx>;
>> >clock-names = "ick", "fck";
>> >
>> > to am3517.dtsi and this works too. But wouldn't this mean the driver
>> > will not work anymore in kernels without DT support?
>> 
>> I have this doubt myself. This will break on non-DT boots and, 
>> while we're trying to move to DT-only, IMO meanwhile we should
>> allow for fixes to DT and non-DT world. Once the conversion is
>> done, fine.
>
> Isn't am35xx already DT-only? The remaining omap2+ boards are both
> omap3430 based:

yeah, and this system is omap3 based, not am335x based ;-)

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Tony Lindgren]

On boards with more than 2GB of RAM booting goes wrong with things not working
and we're getting lots of l3 warnings:

WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x260/0x384()
4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access in 
User mode during Functional access
...
[] (scsi_add_host_with_dma) from [] 
(ata_scsi_add_hosts+0x5c/0x18c)
[] (ata_scsi_add_hosts) from [] 
(ata_host_register+0x150/0x2cc)
[] (ata_host_register) from [] 
(ata_host_activate+0xd4/0x124)
[] (ata_host_activate) from [] 
(ahci_host_activate+0x5c/0x194)
[] (ahci_host_activate) from [] 
(ahci_platform_init_host+0x1f0/0x3f0)
[] (ahci_platform_init_host) from [] (ahci_probe+0x70/0x98)
[] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)

Let's fix the issue by enabling ZONE_DMA for LPAE.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b3a0dff..33d1460 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -49,6 +49,7 @@ config SOC_OMAP5
select OMAP_INTERCONNECT
select OMAP_INTERCONNECT_BARRIER
select PM_OPP if PM
+   select ZONE_DMA if ARM_LPAE
 
 config SOC_AM33XX
bool "TI AM33XX"
@@ -78,6 +79,7 @@ config SOC_DRA7XX
select OMAP_INTERCONNECT
select OMAP_INTERCONNECT_BARRIER
select PM_OPP if PM
+   select ZONE_DMA if ARM_LPAE
 
 config ARCH_OMAP2PLUS
bool
-- 
2.1.4

--
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: Linux 4.2.0-rc5: am335x: musb warnings

[Ladislav Michl]

On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
> Hi Felipe,
> 
> On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
>  wrote:
> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
> >  wrote:
> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
> >>> HI,
> >>>
> >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>  I performed a stress test with several FT4232H chips connected to a
> >>>
> >>> how many ?
> >>
> >> # lsusb -t
> >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
> >>
> >> 3 chips a 4-ports are attached.
> >
> > Warnings appear on another device (without internal hub) with only one
> > FT4232H too:
> >
> > # lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
> >
>  hub, that is attached to one of the musb ports. So far the test was
>  successful for several hours. But I've seen following warnings:
> 
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
> 
>  Is this expected behavior?
> >>>
> >>> no, that shouldn't happen, but it does and, apparently, in more than one
> >>> implementation. Wondering if you're running into endpoint limitation due
> >>> to MUSB's poor transfer scheduling for non-bulk endpoints.

To add more:
kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged:
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 
480M
|__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 
480M
|__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 
480M
|__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 
480M
|__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 
480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M

 musb_ep_program 931: broken !rx_reinit, ep2 csr a203
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_ep_program 931: broken !rx_reinit, ep5 csr a203
 musb_host_rx 1973: Rx interrupt with no errors or packet!

and in both PIO and DMA mode write to device ends this way:
 [ cut here ]
 WARNING: CPU: 0 PID: 146 at drivers/usb/musb/musb_host.c:128 
musb_h_tx_flush_fifo+0x84/0xb8()
 Could not flush host TX2 fifo: csr: 2003
 Modules linked in: option usb_wwan usbserial snd_soc_omap_twl4030 cpufreq_dt 
snd_soc_omap_mcbsp snd_soc_omap snd_soc_twl4030 snd_pcm_dmaengine omap_aes 
snd_soc_core omap_sham omap_mailbox s
 CPU: 0 PID: 146 Comm: ModemManager Not tainted 4.2.0 #3
 Hardware name: Generic OMAP36xx (Flattened Device Tree)
 [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
 [] (show_stack) from [] (warn_slowpath_common+0x84/0xac)
 [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x2c/0x3c)
 [] (warn_slowpath_fmt) from [] 
(musb_h_tx_flush_fifo+0x84/0xb8)
 [] (musb_h_tx_flush_fifo) from [] 
(musb_cleanup_urb.isra.13+0xa0/0x12c)
 [] (musb_cleanup_urb.isra.13) from [] 
(musb_urb_dequeue+0xf4/0x114)
 [] (musb_urb_dequeue) from [] 
(usb_hcd_unlink_urb+0x60/0x7c)
 [] (usb_hcd_unlink_urb) from [] 

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Sebastian Reichel]

Hi,

On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote:
> Rolf Peukert  writes:
> > On 13.10.2015 10:15, Tero Kristo wrote:
> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
> >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
> >>> interface and function clocks for the M-USB controller. These calls fail
> >>> in the current kernel. This patch adds clock definitions containing the
> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
> >>> am35x.c can succeed.
> >>>
> >>> Signed-off-by:  Rolf Peukert 
> >>>
> >>> ---
> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
> >>>   1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> >>> index 8831e1a..b635deb 100644
> >>> --- a/drivers/clk/ti/clk-3xxx.c
> >>> +++ b/drivers/clk/ti/clk-3xxx.c
> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
> >>>
> >> 
> >> Adding clock aliases should be avoided, isn't there any other way to fix
> >> this issue? Like adding clocks = <> references under the DT node?
> >> 
> >> -Tero
> >> 
> >
> > Yes, I just tried adding the lines
> >
> > clocks = <_ick_am35xx>, <_fck_am35xx>;
> > clock-names = "ick", "fck";
> >
> > to am3517.dtsi and this works too. But wouldn't this mean the driver
> > will not work anymore in kernels without DT support?
> 
> I have this doubt myself. This will break on non-DT boots and, 
> while we're trying to move to DT-only, IMO meanwhile we should
> allow for fixes to DT and non-DT world. Once the conversion is
> done, fine.

Isn't am35xx already DT-only? The remaining omap2+ boards are both
omap3430 based:

$ grep "^MACHINE_START(" arch/arm/mach-omap2/*
arch/arm/mach-omap2/board-ldp.c:MACHINE_START(OMAP_LDP, "OMAP LDP board")
arch/arm/mach-omap2/board-rx51.c:MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")

-- Sebastian


signature.asc
Description: PGP signature

Re: AM37x unable to drive output of some gpio lines (works with 2.6.37)

[Ladislav Michl]

On Tue, Oct 13, 2015 at 09:26:24PM +0300, Grygorii Strashko wrote:
> I think You might need to check pin muxing in DT-file. if you have smth like
> 
>   dss_dpi_pins_cm_t35x: pinmux_dss_dpi_pins_cm_t35x {
>   pinctrl-single,pins = <
>   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data0.dss_data0 */
>   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data1.dss_data1 */
> 
> ^ it will not work as gpio.
> 
>   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data2.dss_data2 */
>   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data3.dss_data3 */
>   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data4.dss_data4 */
>   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)   
> /* dss_data5.dss_data5 */
>   >;
>   };

It is not there as proven in very first mail reading mux register value
CONTROL_PADCONF_DSS_DATA0 0x480020DC: 0x1040104
Turned out to be hardware problem, scheme I have does not match PCB -
device controled by GPIO 71 is actually powered by VSDI_CSI (vpll2),
but on scheme there is line directly from power supply. And as 2.6.37
does not disable regulator it worked there. Shame on me and sorry for the
noise.

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

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

[Felipe Balbi]

Hi,

Sebastian Reichel  writes:
> On Tue, Oct 13, 2015 at 05:57:59PM -0500, Felipe Balbi wrote:
>> Sebastian Reichel  writes:
>> > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote:
>> >> Rolf Peukert  writes:
>> >> > On 13.10.2015 10:15, Tero Kristo wrote:
>> >> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote:
>> >> >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its
>> >> >>> interface and function clocks for the M-USB controller. These calls 
>> >> >>> fail
>> >> >>> in the current kernel. This patch adds clock definitions containing 
>> >> >>> the
>> >> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>> >> >>> am35x.c can succeed.
>> >> >>>
>> >> >>> Signed-off-by:  Rolf Peukert 
>> >> >>>
>> >> >>> ---
>> >> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>> >> >>>   1 file changed, 2 insertions(+)
>> >> >>>
>> >> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> >> >>> index 8831e1a..b635deb 100644
>> >> >>> --- a/drivers/clk/ti/clk-3xxx.c
>> >> >>> +++ b/drivers/clk/ti/clk-3xxx.c
>> >> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>> >> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>> >> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>> >> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>> >> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>> >> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>> >> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>> >> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>> >> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>> >> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>> >> >>>
>> >> >> 
>> >> >> Adding clock aliases should be avoided, isn't there any other way to 
>> >> >> fix
>> >> >> this issue? Like adding clocks = <> references under the DT node?
>> >> >> 
>> >> >> -Tero
>> >> >> 
>> >> >
>> >> > Yes, I just tried adding the lines
>> >> >
>> >> > clocks = <_ick_am35xx>, <_fck_am35xx>;
>> >> > clock-names = "ick", "fck";
>> >> >
>> >> > to am3517.dtsi and this works too. But wouldn't this mean the driver
>> >> > will not work anymore in kernels without DT support?
>> >> 
>> >> I have this doubt myself. This will break on non-DT boots and, 
>> >> while we're trying to move to DT-only, IMO meanwhile we should
>> >> allow for fixes to DT and non-DT world. Once the conversion is
>> >> done, fine.
>> >
>> > Isn't am35xx already DT-only? The remaining omap2+ boards are both
>> > omap3430 based:
>> 
>> yeah, and this system is omap3 based, not am335x based ;-)
>
> Sure, am35xx depends on omap3 and omap3 still supports platform
> based booting because of the mentioned boards, but that does not
> mean, that am35xx also needs to support legacy booting. From what
> I can see, the last am35xx board has been removed in v4.0 [0]
> together with the am35xx platform headers.
>
> So while omap3 can still be booted the legacy way, am35xx cannot
> without modifying the kernel. Other omap3 based SoCs will initialize
> musb's omap2430 gluecode, so they are not affected.
>
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=omap-for-v3.20/drop-legacy-3517-v2

fair enough, that settles it. DT-only it is.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Sascha Hauer]

On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote:
> Hello,
> 
> While working on regulators, GPIOs and DT I noticed that many of our DT source
> files incorrectly describe fixed regulators. The common error patterns are
> 
> - Usage of the undefined (and never parsed) enable-active-low property
> - Usage of the enable-active-high property without specifying an enable GPIO
> - Typos in the enabl GPIO property name (gpios instead of gpio)
> - Mismatch between the enable-active-high property (or the lack thereof) and
>   the enable GPIO flags
> 
> This patch series fixes those issues in all the DT sources after locating the
> errors using the following script.

Nice. For the i.MX boards:

Reviewed-by: Sascha Hauer 

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

On 13/10/15 03:43, Tony Lindgren wrote:
> * Roger Quadros  [150918 08:00]:
>> Add compatible id, GPMC register resource and interrupt
>> resource to NAND controller nodes.
>>
>> The GPMC driver now implements gpiochip and irqchip so
>> enable gpio-controller and interrupt-controller properties.
>>
>> With this the interrupt parent of NAND node changes so fix it
>> accordingly.
> ...
>> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> @@ -35,11 +35,14 @@
>>  };
>>  
>>   {
>> -ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
>> +ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
>>  
>>  nand@0,0 {
>> -linux,mtd-name = "micron,mt29f4g16abbda3w";
>> +compatible = "ti,omap2-nand";
>>  reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
>> +interrupt-parent = <>;
>> +interrupts = <20>;
>> +linux,mtd-name = "micron,mt29f4g16abbda3w";
>>  nand-bus-width = <16>;
>>  ti,nand-ecc-opt = "bch8";
>>  gpmc,sync-clk-ps = <0>;
> 
> At least torpedo breaks for NFSroot as NAND now overlaps with
> Ethernet.. What's the policy you have for moving the addresses
> around?

For OMAP3 I intended to use 0x3000 for NAND but incorrectly
used 0x0800 for the torpedo.

Does setting it to 0x3000 work? If not what is the original
NAND address for this board?

> 
> There may be other similar cases to check too.

Just checked that all other OMAP3 boards I've set to 0x3000
if they were 0x0.

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