[PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers

[Peter Ujfalusi]

From: Misael Lopez Cruz 

The L3 throughput can be higher than expected when packed access
is not enabled.  The ratio depends on the number of bytes in a
transaction and the EMIF interface width.

The throughput was measured for the following settings/cases:

* Case 1: Burst size of 64 bytes, packed access disabled
* Case 2: Burst size of 64 bytes, packed access enabled
* Case 3: Burst disabled, packed access disabled

Throughput measurements were done during McASP-based audio
playback on the Jacinto6 EVM using the omapconf tool [1]:
$ omapconf trace bw -m sdma_rd

 -
  Throughput (MB/s)
  Audio parametersCase 1Case 2Case 3
 -
  44.1kHz, 16-bits, stereo  1.41  0.18  1.41
  44.1kHz, 32-bits, stereo  1.41  0.35  1.41
  44.1kHz, 16-bits, 4-chan  2.82  0.35  2.82
  44.1kHz, 16-bits, 6-chan  4.23  0.53  4.23
  44.1kHz, 16-bits, 8-chan  5.64  0.71  5.64
 -

>From above measurements, case 2 is the only one that delivers
the expected throughput for the given audio parameters.  For
that reason, the packed accesses are now enabled.

It's worth to mention that packed accesses cannot be enabled
for all addressing modes. In cyclic transfers, it can be
enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
as they use post-increment mode which supports packed accesses.

Peter Ujfalusi:
>From the TRM regarding to this:
"NOTE: Except in the constant addressing mode, the source or
destination must be specified as packed for burst transactions
to occur."

So w/o the packed setting the burst on the MEM side was not
enabled, this explains the numbers.

[1] https://github.com/omapconf/omapconf

Signed-off-by: Misael Lopez Cruz 
Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/omap-dma.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 249445c8a4c6..1dfc71c90123 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -935,8 +935,12 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_cyclic(
else
d->ccr |= CCR_SYNC_ELEMENT;
 
-   if (dir == DMA_DEV_TO_MEM)
+   if (dir == DMA_DEV_TO_MEM) {
d->ccr |= CCR_TRIGGER_SRC;
+   d->csdp |= CSDP_DST_PACKED;
+   } else {
+   d->csdp |= CSDP_SRC_PACKED;
+   }
 
d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
 
-- 
2.5.2

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

Re: mysterious crashes on OMAP5 uevm

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 03:03:07PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 03:27:13PM +0200, Grazvydas Ignotas wrote:
> > On Thu, Sep 10, 2015 at 10:30 AM, Russell King - ARM Linux
> >  wrote:
> > > On Thu, Sep 10, 2015 at 08:42:57AM +0200, Dr. H. Nikolaus Schaller wrote:
> > >> ...
> > >>
> > >> Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and 
> > >> adding the
> > >> >> #if 0 //__LINUX_ARM_ARCH__ >= 7
> > >> makes it re-appear.
> > >>
> > >> A while ago I tried to debug running the x-server under strace and could 
> > >> find that it also has
> > >> something to do with SIGALRM.
> > >>
> > >> And that is very consistent with “enable/disable” by modifying 
> > >> arch/arm/kernel/signal.c
> > >
> > > It would be really nice if someone could diagnose what's going on here.
> > > What exception is causing the X server to be killed (someone said a
> > > segfault)?  What is the register state at the point that happens?  What
> > > does the code look like  Is it happening inside the SIGALRM handler, or
> > > when the SIGALRM handler has returned?
> > >
> > > I'd suggest attaching gdb to the X server, but remember to set gdb to
> > > ignore SIGPIPEs.
> > 
> > It's actually pretty random, see some debug sessions in [1].
> > The first one is the most useful one, but I haven't though of checking
> > what pixman_rasterize_edges() was doing when the signal arrived, and
> > most often the "less useful" segfaults occur. However from the
> > disassembly (see debug1_libpixman.gz) it can be seen that the signal
> > arrived right after IT.
> > 
> > [1] http://notaz.gp2x.de/tmp/thumb_segfault/
> 
> We're not going from ARM -> Thumb or Thumb -> ARM here, but Thumb code
> in libpixman is being interrupted calling a Thumb signal handler.
> 
> Working through the code:
> 
>0x7f717ec8 : ldr r2, [pc, #20]   ; = 0x0004112e
>0x7f717eca :   ldr r1, [pc, #24]   ; = 0x0c48
>0x7f717ecc :   ldr r3, [pc, #24]   ; = 0x0e6c
>0x7f717ece :   add r2, pc
>0x7f717ed0 :   ldr r1, [r2, r1]
>0x7f717ed2 :  ldr r3, [r2, r3]
> => 0x7f717ed4 :  ldr r2, [r1, #0]
> 
> The instruction at 0x7f717ed4 was trying to access 0xd1242963 which
> is in kernel space, and this is the faulting instruction.
> 
> At this point, r2 should contain 0x0004112e plus the PC value.  r2 in
> the register dump was 0x7f717fa0.  Let's calculate the value that PC
> should be here.  0x7f717fa0 - 0x0004112e = 0x7f6d6e72, which is
> clearly wrong.
> 
> So, I don't think the first instruction here was executed by the CPU.
> 
> gdb indicates that the parent context to the signal frame, pc was at
> 0xb6dd87f8, which works out at 0x297f8 into the libpixman-1 library:
> 
>297f0:   449cadd ip, r3
>297f2:   f1bc 0fff   cmp.w   ip, #255; 0xff
>297f6:   bfd4ite le
>297f8:   fa5f fc8c   uxtble.wip, ip
>297fc:   f04f 0cff   movgt.w ip, #255; 0xff
>29800:   f88a c000   strb.w  ip, [sl]
> 
> and as you say, is just after an IT instruction, which would have
> set the IT execution state to appropriately skip either the first or
> the second instruction.
> 
> Unfortunately, the IT instruction's condition is being carried forward
> to the signal handler, causing either the first or second instruction
> there to be skipped.
> 
> Looking back at the history, the original commit introducing the
> clearing of the PSR_IT_MASK bits is just wrong:
> 
> -   if (thumb)
> +   if (thumb) {
> cpsr |= PSR_T_BIT;
> -   else
> +#if __LINUX_ARM_ARCH__ >= 7
> +   /* clear the If-Then Thumb-2 execution state */
> +   cpsr &= ~PSR_IT_MASK;
> +#endif
> +   } else
> cpsr &= ~PSR_T_BIT;
> 
> This shouldn't be a compile-time decision at all, and it certainly should
> not be dependent on __LINUX_ARM_ARCH__, which marks the _lowest_ supported
> architecture.
> 
> However, even the idea that it's ARMv7 or later is wrong.  According to
> the ARM ARM, the IT instruction is present in ARMv6T2 as well, which
> means it's ARMv6 too (which would have __LINUX_ARM_ARCH__ = 6).
> 
> Looking at the ARM ARM, these bits are "reserved" in previous non-T2
> architectures, have an undefined value at reset, and are probably zero
> anyway.
> 
> Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the problem,
> and I doubt there's any ARMv6 non-T2 systems out there that would be
> affected by clearing the IT state bits.

Please test the following patch:

8<===
From: Russell King 
Subject: [PATCH] ARM: fix Thumb2 signal handling when ARMv6 is enabled

When a kernel is built covering ARMv6 to 

[PATCH 2/2] arm: omap2: board-generic: use omap4_local_timer_init for AM437x

[Felipe Balbi]

AM437x-based boards, can use omap4_local_timer_init()
just fine. Let's use that instead.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 24c9afc9e8a7..89bf39663d61 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -279,7 +279,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_gptimer_timer_init,
+   .init_time  = omap4_local_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
-- 
2.5.0

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

[PATCH 0/3] arm: am4: initialiaze twd local timer

[Felipe Balbi]

Hi,

the following patches are a rebase of the old series [1] to make use
of TWD/Global timers with AM437x devices.

Note that this depends on another patch which used to be part of this
series, but now it was sent separately [2].

[1] http://marc.info/?l=linux-omap=143940944508625=2
[2] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8434/1

Felipe Balbi (2):
  arm: omap2: Kconfig: select TWD and global timer on AM43xx devices
  arm: omap2: board-generic: use omap4_local_timer_init for AM437x

 arch/arm/kernel/smp_twd.c   | 4 
 arch/arm/mach-omap2/Kconfig | 3 +++
 arch/arm/mach-omap2/board-generic.c | 2 +-
 3 files changed, 4 insertions(+), 5 deletions(-)

-- 
2.5.0

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

[PATCH 1/2] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[Felipe Balbi]

Make sure to tell the kernel that AM437x has
TWD and global timers.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 07d2e100caab..88ef10b2d415 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -63,6 +63,9 @@ config SOC_AM43XX
select MACH_OMAP_GENERIC
select MIGHT_HAVE_CACHE_L2X0
select HAVE_ARM_SCU
+   select HAVE_ARM_TWD
+   select ARM_GLOBAL_TIMER
+   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
 
 config SOC_DRA7XX
bool "TI DRA7XX"
-- 
2.5.0

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

[PATCH] ARM: dts: Fix dm814x control base to properly initialize Ethernet PHY

[Tony Lindgren]

Looks like I made a typo on the control base, all the 81xx
SoCs have it at 0x4814 base. We've just gotten away with
the typo as the Ethernet phy was configured by the bootloader
on my test system and we're not yet using the pinctrl.

In addition to fixing the contol base, we need to also use the
right Ethernet phy flags to initialize it. And we are still
missing the PLL driver for dm814x and only relying on the
divider and mux clocks.

Fixes: f3d953ea3721 ("ARM: dts: Add minimal dm814x support")
Cc: Matthijs van Duin 
Cc: Nicolas Chauvet 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm8148-evm.dts  | 4 ++--
 arch/arm/boot/dts/dm8148-t410.dts | 4 ++--
 arch/arm/boot/dts/dm814x.dtsi | 8 
 3 files changed, 8 insertions(+), 8 deletions(-)

--- a/arch/arm/boot/dts/dm8148-evm.dts
+++ b/arch/arm/boot/dts/dm8148-evm.dts
@@ -19,10 +19,10 @@
 
 _emac0 {
phy_id = <_mdio>, <0>;
-   phy-mode = "mii";
+   phy-mode = "rgmii";
 };
 
 _emac1 {
phy_id = <_mdio>, <1>;
-   phy-mode = "mii";
+   phy-mode = "rgmii";
 };
--- a/arch/arm/boot/dts/dm8148-t410.dts
+++ b/arch/arm/boot/dts/dm8148-t410.dts
@@ -19,10 +19,10 @@
 
 _emac0 {
phy_id = <_mdio>, <0>;
-   phy-mode = "mii";
+   phy-mode = "rgmii";
 };
 
 _emac1 {
phy_id = <_mdio>, <1>;
-   phy-mode = "mii";
+   phy-mode = "rgmii";
 };
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -181,9 +181,9 @@
ti,hwmods = "timer3";
};
 
-   control: control@16 {
+   control: control@14 {
compatible = "ti,dm814-scm", "simple-bus";
-   reg = <0x16 0x16d000>;
+   reg = <0x14 0x16d000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x16 0x16d000>;
@@ -321,9 +321,9 @@
mac-address = [ 00 00 00 00 00 00 ];
};
 
-   phy_sel: cpsw-phy-sel@0x48160650 {
+   phy_sel: cpsw-phy-sel@48140650 {
compatible = "ti,am3352-cpsw-phy-sel";
-   reg= <0x48160650 0x4>;
+   reg= <0x48140650 0x4>;
reg-names = "gmii-sel";
};
};
-- 
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: [PATCH v2 11/23] ARM/dmaengine: edma: Merge the two drivers under drivers/dmaengine

[Tony Lindgren]

* Peter Ujfalusi  [150911 05:35]:
> 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.

You should check your git config so it uses -M option to git diff
to detect renames. Anyways, assuming you're just moving code, for
the omap parts:

Acked-by: Tony Lindgren 

--
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: dts: DRA7: fix a typo in ethernet

[Tony Lindgren]

* Vishal Mahaveer  [150825 12:01]:
> Register address in name of the node is wrong
> 
> Signed-off-by: Vishal Mahaveer 
> Acked-by: Mugunthan V N 

Applying into omap-for-v4.3/fixes thanks.

Tony

> ---
>  arch/arm/boot/dts/dra7.dtsi |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 1e29ccf..9a20d46 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1398,7 +1398,7 @@
>   ti,irqs-safe-map = <0>;
>   };
>  
> - mac: ethernet@4a10 {
> + mac: ethernet@48484000 {
>   compatible = "ti,cpsw";
>   ti,hwmods = "gmac";
>   clocks = <_gmac_ck>, <_gmii_ref_clk_div>;
> -- 
> 1.7.4.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 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Suman Anna]

Hi Tony,

On 09/03/2015 05:34 PM, Suman Anna wrote:
> Hi Sakari,
> 
> On 07/16/2015 07:58 AM, Tony Lindgren wrote:
>> * Laurent Pinchart  [150716 05:57]:
>>> The OMAP3 ISP is now fully supported in DT, remove its instantiation
>>> from C code.
>>
>> Please feel to queue this along with the second patch in this series,
>> this should not cause any merge conflicts:
>>
>> Acked-by: Tony Lindgren 
> 
> Just wondering if you have already queued this, I see the v4l changes in
> linux-next, but not this patch. Also, can you confirm if this series is
> making it into 4.3?
> 

This patch is not in 4.3-rc1, can you pick this up for the next merge
window? I am gonna send out some additional cleanup patches (removing
legacy mailbox and iommu pieces) on top on this patch. The second patch
in this series did make it.

regards
Suman

--
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: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node

[Tony Lindgren]

* Kishon Vijay Abraham I  [150824 23:40]:
> Hi Tony,
> 
> On Thursday 30 July 2015 01:07 AM, Nishanth Menon wrote:
> > On 07/29/2015 06:09 AM, Kishon Vijay Abraham I wrote:
> >> For beagle x15, both the vdd and io lines are connected to the
> >> same regulator (ldo1_reg). However vmmc_aux is populated to vdd_3v3.
> >> Remove it.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I 
> >> ---
> >>  arch/arm/boot/dts/am57xx-beagle-x15.dts |1 -
> >>  1 file changed, 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> >> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >> index a63bf78..d0db5c5 100644
> >> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >> @@ -579,7 +579,6 @@
> >>pinctrl-0 = <_pins_default>;
> >>  
> >>vmmc-supply = <_reg>;
> >> -  vmmc_aux-supply = <_3v3>;
> >>pbias-supply = <_mmc_reg>;
> >>bus-width = <4>;
> >>cd-gpios = < 27 0>; /* gpio 219 */
> >>
> > Acked-by: Nishanth Menon 
> 
> Can you pick this one or you want me to resend it?

Picking into omap-for-v4.3/fixes thanks.

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/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Tony Lindgren]

* Peter Ujfalusi  [150914 01:54]:
> Hi Tony,
> 
> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
> > Hi,
> > 
> > this series will enable analog audio (via onboard aic310x codec) for 
> > dra7-evm,
> > dra72-evm and am57xx-beagle-x15 boards.
> > In these board McASP3 is connected to the codec and for the McASP3 we 
> > needed to
> > have the DMA crossbar in place since the request lines are not mapped by
> > default.
> 
> Did you had a chance to look at this series?

Looks OK to me, will look at it more once we have the fixes merged.

Paul may have comments on the hwmod chage, looks like you forgot
to Cc him on it. Can you please resend that one with Paul in Cc?

Regards,

Tony
 
> > Regars,
> > Peter
> > ---
> > Peter Ujfalusi (11):
> >   ARM: OMAP: DRA7: hwmod: Add data for McASP3
> >   ARM: DTS: dra7: Add McASP3 node
> >   ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw
> >   ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
> >   ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus
> >   ARM: DTS: dra7-evm: Audio support
> >   ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for
> > aic3106
> >   ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio
> >   ARM: DTS: dra72-evm: Audio support
> >   ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD
> >   ARM: DTS: am57xx-beagle-x15: Enable analog audio support
> > 
> >  arch/arm/boot/dts/am57xx-beagle-x15.dts   |  95 
> >  arch/arm/boot/dts/dra7-evm.dts| 142 
> > +-
> >  arch/arm/boot/dts/dra7.dtsi   |  15 
> >  arch/arm/boot/dts/dra72-evm.dts   | 138 
> > +
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  41 +
> >  5 files changed, 428 insertions(+), 3 deletions(-)
> > 
> 
> 
> -- 
> 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 1/2] ARM: dts: am335x-phycore-som: Fix mpu voltage

[Tony Lindgren]

* Teresa Remmet  [150903 05:03]:
> Fix the mpu voltage as it is set to low for the silicon
> revision 2.1.
> 
> Signed-off-by: Teresa Remmet 

Applying this one into omap-for-v4.3/fixes thanks.

Tony

> ---
>  arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi 
> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> index 4d28fc3..5dd084f 100644
> --- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -252,10 +252,10 @@
>   };
>  
>   vdd1_reg: regulator@2 {
> - /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% 
> tolerance */
> + /* VDD_MPU voltage limits 0.95V - 1.325V with +/-4% 
> tolerance */
>   regulator-name = "vdd_mpu";
>   regulator-min-microvolt = <912500>;
> - regulator-max-microvolt = <1312500>;
> + regulator-max-microvolt = <1378000>;
>   regulator-boot-on;
>   regulator-always-on;
>   };
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Tony Lindgren]

* Suman Anna  [150914 09:33]:
> Hi Tony,
> 
> On 09/03/2015 05:34 PM, Suman Anna wrote:
> > Hi Sakari,
> > 
> > On 07/16/2015 07:58 AM, Tony Lindgren wrote:
> >> * Laurent Pinchart  [150716 05:57]:
> >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation
> >>> from C code.
> >>
> >> Please feel to queue this along with the second patch in this series,
> >> this should not cause any merge conflicts:
> >>
> >> Acked-by: Tony Lindgren 
> > 
> > Just wondering if you have already queued this, I see the v4l changes in
> > linux-next, but not this patch. Also, can you confirm if this series is
> > making it into 4.3?
> > 
> 
> This patch is not in 4.3-rc1, can you pick this up for the next merge
> window? I am gonna send out some additional cleanup patches (removing
> legacy mailbox and iommu pieces) on top on this patch. The second patch
> in this series did make it.

OK tagging this one for next, will apply once I'm done with fixes.

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] ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again

[Tony Lindgren]

* Carl Frederik Werner  [150901 18:18]:
> Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.
> 
> According to the OMAP35x Technical Reference Manual
>   CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
>   CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
> the pinmux address of gpio 170 must be 0x480021C6.
> 
> The former wrong address broke i2c3 (used by hdmi ddc), resulting in
> kernel message:
>   omap_i2c 4806.i2c: controller timed out
> 
> Signed-off-by: Carl Frederik Werner 

Thanks applying into omap-for-v4.3/fixes with cc stable v3.15+.
Good to see issues like this to get fixed.

Regards,

Tony

> ---
>  arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
> b/arch/arm/boot/dts/omap3-beagle.dts
> index fd792a4..18b178b 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -202,7 +202,7 @@
>  
>   tfp410_pins: pinmux_tfp410_pins {
>   pinctrl-single,pins = <
> - 0x194 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
> + 0x196 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
>   >;
>   };
>  
> -- 
> 2.5.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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] regulator: Fix pbias regulator enable

[Tony Lindgren]

Hi,

* Ulf Hansson  [150904 05:48]:
> 
> Okay, just to be clear on the way forward. I spoked with Mark Brown
> offlist, and he will/has picked up the regulator patch and will send
> it as fix for the 4.3 rc[n].
> 
> Regarding the ARM patch here, I guess Tony might as well handle it and
> send through arm-soc, especially since the regression won't be fixed
> within my mmc tree anyway.
> 
> So, I am going to leave my next branch as is - and thus relying on
> teet the regression for OMAP will be fixed in some the 4.3 rc[n].

I'm picking up the .dts changes from this series into
omap-for-v4.3/fixes as those are safe to apply while waiting
for the pbias-regulator.c fix to hit mainline.

I'm not yet applying the related dts change "fix address translation
for pbias" as that depends on the pbias-regulator.c change.

Howver, when testing all the patches applied, I'm still getting
the following splat at least on duovero (with MMC working):

WARNING: CPU: 0 PID: 6 at drivers/regulator/core.c:2105 
_regulator_disable+0x13c/0x1d4()
unbalanced disables for pbias_mmc_omap4
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.3.0-rc1-00015-gf5c4173-dirty 
#1295
Hardware name: Generic OMAP4 (Flattened Device Tree)
Workqueue: deferwq deferred_probe_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x9c)
[] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] 
(_regulator_disable+0x13c/0x1d4)
[] (_regulator_disable) from [] 
(regulator_disable+0x30/0x6c)
[] (regulator_disable) from [] 
(omap_hsmmc_set_power+0x158/0x1e8)
[] (omap_hsmmc_set_power) from [] 
(omap_hsmmc_set_ios+0x198/0x318)
[] (omap_hsmmc_set_ios) from [] 
(mmc_power_up.part.10+0x30/0xf8)
[] (mmc_power_up.part.10) from [] (mmc_start_host+0x40/0x7c)
[] (mmc_start_host) from [] (mmc_add_host+0x5c/0x84)
[] (mmc_add_host) from [] (omap_hsmmc_probe+0x5b0/0x9f0)
[] (omap_hsmmc_probe) from [] (platform_drv_probe+0x44/0xac)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x1f4/0x2f0)
[] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[] (bus_for_each_drv) from [] (__device_attach+0xb0/0x118)
[] (__device_attach) from [] (bus_probe_device+0x88/0x90)
[] (bus_probe_device) from [] 
(deferred_probe_work_func+0x60/0x90)
[] (deferred_probe_work_func) from [] 
(process_one_work+0x1a4/0x558)
[] (process_one_work) from [] (worker_thread+0x3c/0x514)
[] (worker_thread) from [] (kthread+0xd4/0xf0)
[] (kthread) from [] (ret_from_fork+0x14/0x24)

Kishon, can you please take a look?

Regards,

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

[PATCH 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation

[Suman Anna]

The legacy-style mailbox device creation is supported currently
only for OMAP3, as all other SoCs are DT-boot only. Even on this
SoC, there are no client drivers that utilize these mailbox devices.
So, clean up the legacy-style mailbox device instantiation logic.
The mailbox devices are already present and supported for the DT
boot on OMAP3.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/devices.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9374da313e8e..f0f9901d90b0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -66,32 +65,6 @@ static int __init omap3_l3_init(void)
 }
 omap_postcore_initcall(omap3_l3_init);
 
-#if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
-static inline void __init omap_init_mbox(void)
-{
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
-   struct omap_mbox_pdata *pdata;
-
-   oh = omap_hwmod_lookup("mailbox");
-   if (!oh) {
-   pr_err("%s: unable to find hwmod\n", __func__);
-   return;
-   }
-   if (!oh->dev_attr) {
-   pr_err("%s: hwmod doesn't have valid attrs\n", __func__);
-   return;
-   }
-
-   pdata = (struct omap_mbox_pdata *)oh->dev_attr;
-   pdev = omap_device_build("omap-mailbox", -1, oh, pdata, sizeof(*pdata));
-   WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n",
-   __func__, PTR_ERR(pdev));
-}
-#else
-static inline void omap_init_mbox(void) { }
-#endif /* CONFIG_OMAP2PLUS_MBOX */
-
 static inline void omap_init_sti(void) {}
 
 #if defined(CONFIG_SND_SOC) || defined(CONFIG_SND_SOC_MODULE)
@@ -246,7 +219,6 @@ static int __init omap2_init_devices(void)
omap_init_audio();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
-   omap_init_mbox();
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
-- 
2.5.0

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

[PATCH 0/2] Cleanup legacy OMAP mailbox support

[Suman Anna]

Hi Tony,

The following series removes the legacy platform device creation
for OMAP mailbox devices. I will remove the platform data file
alongside the non-DT support cleanup in the driver.

Patches based on 4.3-rc1 + the patch on mach-omap2/devices.c that
removes the OMAP3 ISP instantiation in legacy-mode [1]. The hwmod
cleanup patch can be picked up independently if needed - it will
just fail to create the legacy devices in omap_init_mbox(). These
are only build tested and boot tested on OMAP3 in DT-mode, as I do
not have any platforms where I can still perform a legacy-style
boot.

regards
Suman

[1] https://patchwork.kernel.org/patch/6806891/

Suman Anna (2):
  ARM: OMAP2+: Remove legacy mailbox device instantiation
  ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs

 arch/arm/mach-omap2/devices.c  | 28 
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 -
 2 files changed, 57 deletions(-)

-- 
2.5.0

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

[PATCH 2/2] ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs

[Suman Anna]

Remove the mailbox attribute data, irq info and hwmod addr space
data that are used for creating the legacy-style mailbox devices,
there is no need for these as the support for legacy-mode for this
IP is being dropped.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index dc55f8dedf2c..aff78d5198d2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "soc.h"
@@ -1506,26 +1505,9 @@ static struct omap_hwmod_class 
omap3xxx_mailbox_hwmod_class = {
.sysc = _mailbox_sysc,
 };
 
-static struct omap_mbox_dev_info omap3xxx_mailbox_info[] = {
-   { .name = "dsp", .tx_id = 0, .rx_id = 1 },
-};
-
-static struct omap_mbox_pdata omap3xxx_mailbox_attrs = {
-   .num_users  = 2,
-   .num_fifos  = 2,
-   .info_cnt   = ARRAY_SIZE(omap3xxx_mailbox_info),
-   .info   = omap3xxx_mailbox_info,
-};
-
-static struct omap_hwmod_irq_info omap3xxx_mailbox_irqs[] = {
-   { .irq = 26 + OMAP_INTC_START, },
-   { .irq = -1 },
-};
-
 static struct omap_hwmod omap3xxx_mailbox_hwmod = {
.name   = "mailbox",
.class  = _mailbox_hwmod_class,
-   .mpu_irqs   = omap3xxx_mailbox_irqs,
.main_clk   = "mailboxes_ick",
.prcm   = {
.omap2 = {
@@ -1536,7 +1518,6 @@ static struct omap_hwmod omap3xxx_mailbox_hwmod = {
.idlest_idle_bit = OMAP3430_ST_MAILBOXES_SHIFT,
},
},
-   .dev_attr   = _mailbox_attrs,
 };
 
 /*
@@ -3276,20 +3257,10 @@ static struct omap_hwmod_ocp_if 
omap3xxx_l4_per__mcbsp3_sidetone = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space omap3xxx_mailbox_addrs[] = {
-   {
-   .pa_start   = 0x48094000,
-   .pa_end = 0x480941ff,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 /* l4_core -> mailbox */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__mailbox = {
.master = _l4_core_hwmod,
.slave  = _mailbox_hwmod,
-   .addr   = omap3xxx_mailbox_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.5.0

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

[PATCH 0/2] OMAP hwspinlock hwmod cleanup

[Suman Anna]

Hi Paul,

Following are couple of hwmod cleanup patches for HwSpinlock IP. 
Patches based on 4.3-rc1. The legacy platform device instantiation 
logic has been cleaned up in 4.2 kernel when DT-support was added
to the OMAP HwSpinlock driver.

regards
Suman

Suman Anna (2):
  ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs
  ARM: DRA7: hwmod data: Remove spinlock hwmod addrs

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 10 --
 2 files changed, 20 deletions(-)

-- 
2.5.0

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

[PATCH 2/2] ARM: DRA7: hwmod data: Remove spinlock hwmod addrs

[Suman Anna]

The legacy-style device creation logic for hwspinlock
has been removed after the DT-support was added to the
driver. The hwmod addr space for spinlock is therefore
no longer needed, so remove it.

Signed-off-by: Suman Anna 
---
 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 562247bced49..60756ae75a65 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -3029,21 +3029,11 @@ static struct omap_hwmod_ocp_if 
dra7xx_l4_cfg__smartreflex_mpu = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_spinlock_addrs[] = {
-   {
-   .pa_start   = 0x4a0f6000,
-   .pa_end = 0x4a0f6fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_cfg -> spinlock */
 static struct omap_hwmod_ocp_if dra7xx_l4_cfg__spinlock = {
.master = _l4_cfg_hwmod,
.slave  = _spinlock_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_spinlock_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.5.0

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

Re: [PATCH] ARM: OMAP2+: Fixup model name for HP t410 dts

[Tony Lindgren]

* Nicolas Chauvet  [150903 08:40]:
> This fix the model name for the device.
> Whole string taken from the HP support center web page
> 
> Signed-off-by: Nicolas Chauvet 

Thanks applying this into omap-for-v4.3/fixes..

> Cc:   # 4.2.x-

..but leaving out this as this fixes something in the v4.3-rc
cycle for something that got merged for v4.3 :)

Regards,

Tony

> ---
>  arch/arm/boot/dts/dm8148-t410.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/dm8148-t410.dts 
> b/arch/arm/boot/dts/dm8148-t410.dts
> index 8c4bbc7..19e0b9a 100644
> --- a/arch/arm/boot/dts/dm8148-t410.dts
> +++ b/arch/arm/boot/dts/dm8148-t410.dts
> @@ -8,7 +8,7 @@
>  #include "dm814x.dtsi"
>  
>  / {
> - model = "DM8148 EVM";
> + model = "HP t410 Smart Zero Client";
>   compatible = "hp,t410", "ti,dm8148";
>  
>   memory {
> -- 
> 2.4.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs

[Suman Anna]

The legacy-style device creation logic for hwspinlock
has been removed after the DT-support was added to the
driver. The hwmod addr space for spinlock is therefore
no longer needed, so remove it.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 43eebf2c59e2..a5e444b1e57a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4471,21 +4471,11 @@ static struct omap_hwmod_ocp_if 
omap44xx_l4_cfg__smartreflex_mpu = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space omap44xx_spinlock_addrs[] = {
-   {
-   .pa_start   = 0x4a0f6000,
-   .pa_end = 0x4a0f6fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_cfg -> spinlock */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__spinlock = {
.master = _l4_cfg_hwmod,
.slave  = _spinlock_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_spinlock_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.5.0

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

Re: [PATCH] ARM: Remove __ref on hotplug cpu die path

[Viresh Kumar]

On 14-09-15, 17:23, Stephen Boyd wrote:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
> 
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
> 
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
> 
> Cc: Tony Lindgren 
> Cc: Barry Song 
> Cc: Andy Gross 
> Cc: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Cc: Linus Walleij 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Mark Rutland 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
> 
> This patch can be broken up into per-SoC if desired.
> 
>  arch/arm/mach-spear/hotplug.c| 2 +-

Acked-by: Viresh Kumar 

-- 
viresh
--
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: Remove __ref on hotplug cpu die path

[Stephen Boyd]

Now that __cpuinit has been removed, the __ref markings on these
functions are useless. Remove them. This also reduces the size of
the multi_v7_defconfig image:

$ size before after
   textdata bss dec hex filename
   126835781470996  348904 14503478 dd4e36 before
   126832741470996  348904 14503174 dd4d06 after

presumably because now we don't have to jump to code in the
.ref.text section and/or the noinline marking is removed.

Cc: Tony Lindgren 
Cc: Barry Song 
Cc: Andy Gross 
Cc: Viresh Kumar 
Cc: Shiraz Hashim 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Linus Walleij 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Stephen Boyd 
---

This patch can be broken up into per-SoC if desired.

 arch/arm/kernel/psci_smp.c   | 4 ++--
 arch/arm/mach-omap2/omap-hotplug.c   | 2 +-
 arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
 arch/arm/mach-prima2/hotplug.c   | 2 +-
 arch/arm/mach-qcom/platsmp.c | 2 +-
 arch/arm/mach-realview/hotplug.c | 2 +-
 arch/arm/mach-spear/hotplug.c| 2 +-
 arch/arm/mach-tegra/hotplug.c| 2 +-
 arch/arm/mach-ux500/hotplug.c| 2 +-
 arch/arm/mach-vexpress/hotplug.c | 2 +-
 10 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
index 61c04b02faeb..9d479b2ea40d 100644
--- a/arch/arm/kernel/psci_smp.c
+++ b/arch/arm/kernel/psci_smp.c
@@ -71,7 +71,7 @@ int psci_cpu_disable(unsigned int cpu)
return 0;
 }
 
-void __ref psci_cpu_die(unsigned int cpu)
+void psci_cpu_die(unsigned int cpu)
 {
u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
PSCI_0_2_POWER_STATE_TYPE_SHIFT;
@@ -83,7 +83,7 @@ void __ref psci_cpu_die(unsigned int cpu)
panic("psci: cpu %d failed to shutdown\n", cpu);
 }
 
-int __ref psci_cpu_kill(unsigned int cpu)
+int psci_cpu_kill(unsigned int cpu)
 {
int err, i;
 
diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
b/arch/arm/mach-omap2/omap-hotplug.c
index 971791fe9a3f..593fec753b28 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -27,7 +27,7 @@
  * platform-specific code to shutdown a CPU
  * Called with IRQs disabled
  */
-void __ref omap4_cpu_die(unsigned int cpu)
+void omap4_cpu_die(unsigned int cpu)
 {
unsigned int boot_cpu = 0;
void __iomem *base = omap_get_wakeupgen_base();
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
b/arch/arm/mach-omap2/omap-wakeupgen.c
index e1d2e991d17a..d9b317706e63 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -330,7 +330,7 @@ static int irq_cpu_hotplug_notify(struct notifier_block 
*self,
return NOTIFY_OK;
 }
 
-static struct notifier_block __refdata irq_hotplug_notifier = {
+static struct notifier_block irq_hotplug_notifier = {
.notifier_call = irq_cpu_hotplug_notify,
 };
 
diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
index 0ab2f8bae28e..a728c78b996f 100644
--- a/arch/arm/mach-prima2/hotplug.c
+++ b/arch/arm/mach-prima2/hotplug.c
@@ -32,7 +32,7 @@ static inline void platform_do_lowpower(unsigned int cpu)
  *
  * Called with IRQs disabled
  */
-void __ref sirfsoc_cpu_die(unsigned int cpu)
+void sirfsoc_cpu_die(unsigned int cpu)
 {
platform_do_lowpower(cpu);
 }
diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
index 5cde63a64b34..9b00123a315d 100644
--- a/arch/arm/mach-qcom/platsmp.c
+++ b/arch/arm/mach-qcom/platsmp.c
@@ -49,7 +49,7 @@ extern void secondary_startup_arm(void);
 static DEFINE_SPINLOCK(boot_lock);
 
 #ifdef CONFIG_HOTPLUG_CPU
-static void __ref qcom_cpu_die(unsigned int cpu)
+static void qcom_cpu_die(unsigned int cpu)
 {
wfi();
 }
diff --git a/arch/arm/mach-realview/hotplug.c b/arch/arm/mach-realview/hotplug.c
index ac22dd41b135..968e2d1964f6 100644
--- a/arch/arm/mach-realview/hotplug.c
+++ b/arch/arm/mach-realview/hotplug.c
@@ -90,7 +90,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int 
*spurious)
  *
  * Called with IRQs disabled
  */
-void __ref realview_cpu_die(unsigned int cpu)
+void realview_cpu_die(unsigned int cpu)
 {
int spurious = 0;
 
diff --git a/arch/arm/mach-spear/hotplug.c b/arch/arm/mach-spear/hotplug.c
index d97749c642ce..12edd1cf8a12 100644
--- a/arch/arm/mach-spear/hotplug.c
+++ b/arch/arm/mach-spear/hotplug.c
@@ -80,7 +80,7 @@ static inline void spear13xx_do_lowpower(unsigned int 

Re: [PATCH] ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again

[Carl Frederik Werner]

On 2015-09-15 02:24, Tony Lindgren wrote:
> * Carl Frederik Werner  [150901 18:18]:
>> Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.
>>
>> According to the OMAP35x Technical Reference Manual
>>   CONTROL_PADCONF_I2C3_SDA[15:0]  0x480021C4 mode0: i2c3_sda
>>   CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
>> the pinmux address of gpio 170 must be 0x480021C6.
>>
>> The former wrong address broke i2c3 (used by hdmi ddc), resulting in
>> kernel message:
>>   omap_i2c 4806.i2c: controller timed out
>>
>> Signed-off-by: Carl Frederik Werner 
> 
> Thanks applying into omap-for-v4.3/fixes with cc stable v3.15+.
> Good to see issues like this to get fixed.
> 
> Regards,
> 
> Tony

Thanks, it was pleasure to support!

Best regards,
Frederik

> 
>> ---
>>  arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
>> b/arch/arm/boot/dts/omap3-beagle.dts
>> index fd792a4..18b178b 100644
>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>> @@ -202,7 +202,7 @@
>>  
>>  tfp410_pins: pinmux_tfp410_pins {
>>  pinctrl-single,pins = <
>> -0x194 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
>> +0x196 (PIN_OUTPUT | MUX_MODE4)  /* hdq_sio.gpio_170 */
>>  >;
>>  };
>>  
>> -- 
>> 2.5.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
>>
--
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: Remove __ref on hotplug cpu die path

[Barry Song]

2015-09-15 8:23 GMT+08:00 Stephen Boyd :
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
>
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
>
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
>
> Cc: Tony Lindgren 
> Cc: Barry Song 
> Cc: Andy Gross 
> Cc: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Cc: Linus Walleij 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Mark Rutland 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Stephen Boyd 

Acked-by: Barry Song 

> ---
>
> This patch can be broken up into per-SoC if desired.
>
>  arch/arm/kernel/psci_smp.c   | 4 ++--
>  arch/arm/mach-omap2/omap-hotplug.c   | 2 +-
>  arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
>  arch/arm/mach-prima2/hotplug.c   | 2 +-
>  arch/arm/mach-qcom/platsmp.c | 2 +-
>  arch/arm/mach-realview/hotplug.c | 2 +-
>  arch/arm/mach-spear/hotplug.c| 2 +-
>  arch/arm/mach-tegra/hotplug.c| 2 +-
>  arch/arm/mach-ux500/hotplug.c| 2 +-
>  arch/arm/mach-vexpress/hotplug.c | 2 +-
>  10 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> index 61c04b02faeb..9d479b2ea40d 100644
> --- a/arch/arm/kernel/psci_smp.c
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -71,7 +71,7 @@ int psci_cpu_disable(unsigned int cpu)
> return 0;
>  }
>
> -void __ref psci_cpu_die(unsigned int cpu)
> +void psci_cpu_die(unsigned int cpu)
>  {
> u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
> PSCI_0_2_POWER_STATE_TYPE_SHIFT;
> @@ -83,7 +83,7 @@ void __ref psci_cpu_die(unsigned int cpu)
> panic("psci: cpu %d failed to shutdown\n", cpu);
>  }
>
> -int __ref psci_cpu_kill(unsigned int cpu)
> +int psci_cpu_kill(unsigned int cpu)
>  {
> int err, i;
>
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
> b/arch/arm/mach-omap2/omap-hotplug.c
> index 971791fe9a3f..593fec753b28 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -27,7 +27,7 @@
>   * platform-specific code to shutdown a CPU
>   * Called with IRQs disabled
>   */
> -void __ref omap4_cpu_die(unsigned int cpu)
> +void omap4_cpu_die(unsigned int cpu)
>  {
> unsigned int boot_cpu = 0;
> void __iomem *base = omap_get_wakeupgen_base();
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
> b/arch/arm/mach-omap2/omap-wakeupgen.c
> index e1d2e991d17a..d9b317706e63 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -330,7 +330,7 @@ static int irq_cpu_hotplug_notify(struct notifier_block 
> *self,
> return NOTIFY_OK;
>  }
>
> -static struct notifier_block __refdata irq_hotplug_notifier = {
> +static struct notifier_block irq_hotplug_notifier = {
> .notifier_call = irq_cpu_hotplug_notify,
>  };
>
> diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
> index 0ab2f8bae28e..a728c78b996f 100644
> --- a/arch/arm/mach-prima2/hotplug.c
> +++ b/arch/arm/mach-prima2/hotplug.c
> @@ -32,7 +32,7 @@ static inline void platform_do_lowpower(unsigned int cpu)
>   *
>   * Called with IRQs disabled
>   */
> -void __ref sirfsoc_cpu_die(unsigned int cpu)
> +void sirfsoc_cpu_die(unsigned int cpu)
>  {
> platform_do_lowpower(cpu);
>  }
> diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
> index 5cde63a64b34..9b00123a315d 100644
> --- a/arch/arm/mach-qcom/platsmp.c
> +++ b/arch/arm/mach-qcom/platsmp.c
> @@ -49,7 +49,7 @@ extern void secondary_startup_arm(void);
>  static DEFINE_SPINLOCK(boot_lock);
>
>  #ifdef CONFIG_HOTPLUG_CPU
> -static void __ref qcom_cpu_die(unsigned int cpu)
> +static void qcom_cpu_die(unsigned int cpu)
>  {
> wfi();
>  }
> diff --git a/arch/arm/mach-realview/hotplug.c 
> b/arch/arm/mach-realview/hotplug.c
> index ac22dd41b135..968e2d1964f6 100644
> --- a/arch/arm/mach-realview/hotplug.c
> +++ b/arch/arm/mach-realview/hotplug.c
> @@ -90,7 +90,7 @@ static inline void platform_do_lowpower(unsigned int cpu, 
> int *spurious)
>   *
>   * Called with IRQs disabled
>   */
> -void __ref 

Re: [PATCH v3 0/2] regulator: Fix pbias regulator enable

[Kishon Vijay Abraham I]

Hi,

On Tuesday 15 September 2015 01:52 AM, Tony Lindgren wrote:
> Hi,
> 
> * Ulf Hansson  [150904 05:48]:
>>
>> Okay, just to be clear on the way forward. I spoked with Mark Brown
>> offlist, and he will/has picked up the regulator patch and will send
>> it as fix for the 4.3 rc[n].
>>
>> Regarding the ARM patch here, I guess Tony might as well handle it and
>> send through arm-soc, especially since the regression won't be fixed
>> within my mmc tree anyway.
>>
>> So, I am going to leave my next branch as is - and thus relying on
>> teet the regression for OMAP will be fixed in some the 4.3 rc[n].
> 
> I'm picking up the .dts changes from this series into
> omap-for-v4.3/fixes as those are safe to apply while waiting
> for the pbias-regulator.c fix to hit mainline.
> 
> I'm not yet applying the related dts change "fix address translation
> for pbias" as that depends on the pbias-regulator.c change.
> 
> Howver, when testing all the patches applied, I'm still getting
> the following splat at least on duovero (with MMC working):
> 
> WARNING: CPU: 0 PID: 6 at drivers/regulator/core.c:2105 
> _regulator_disable+0x13c/0x1d4()
> unbalanced disables for pbias_mmc_omap4
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.3.0-rc1-00015-gf5c4173-dirty 
> #1295
> Hardware name: Generic OMAP4 (Flattened Device Tree)
> Workqueue: deferwq deferred_probe_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x9c)
> [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4)
> [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x30/0x40)
> [] (warn_slowpath_fmt) from [] 
> (_regulator_disable+0x13c/0x1d4)
> [] (_regulator_disable) from [] 
> (regulator_disable+0x30/0x6c)
> [] (regulator_disable) from [] 
> (omap_hsmmc_set_power+0x158/0x1e8)
> [] (omap_hsmmc_set_power) from [] 
> (omap_hsmmc_set_ios+0x198/0x318)
> [] (omap_hsmmc_set_ios) from [] 
> (mmc_power_up.part.10+0x30/0xf8)
> [] (mmc_power_up.part.10) from [] 
> (mmc_start_host+0x40/0x7c)
> [] (mmc_start_host) from [] (mmc_add_host+0x5c/0x84)
> [] (mmc_add_host) from [] (omap_hsmmc_probe+0x5b0/0x9f0)
> [] (omap_hsmmc_probe) from [] 
> (platform_drv_probe+0x44/0xac)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x1f4/0x2f0)
> [] (driver_probe_device) from [] 
> (bus_for_each_drv+0x64/0x98)
> [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x118)
> [] (__device_attach) from [] (bus_probe_device+0x88/0x90)
> [] (bus_probe_device) from [] 
> (deferred_probe_work_func+0x60/0x90)
> [] (deferred_probe_work_func) from [] 
> (process_one_work+0x1a4/0x558)
> [] (process_one_work) from [] (worker_thread+0x3c/0x514)
> [] (worker_thread) from [] (kthread+0xd4/0xf0)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> 
> Kishon, can you please take a look?

really weird, since I didn't see any issues with my OMAP4 PANDA. Most
likely it's because the PBIAS register is not showing the correct state
of PBIAS. So we might have to remove using regulator_is_enabled and use
our own bookkeeping pbias_enabled variable. Anyway I'll check this.

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

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

[Mark Brown]

On Fri, Sep 04, 2015 at 04:55:33PM +0530, Jagan Teki wrote:
> On 4 September 2015 at 13:59, Vignesh R  wrote:

> > + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory
> > + * mapped interface to communicate with mtd flashes.
> > + * For this, spi  controller needs to know flash
> > + * memory settings like read command to use, dummy
> > + * bytes and address width. Once these settings are
> > + * populated in hardware registers, any read
> > + * accesses to flash's memory map region(as defined
> > + * by SoC) through memcpy or mem-to-mem DMA copy
> > + * will be handled by controller hardware. The
> > + * hardware will automatically generate spi signals
> > + * required to read data from flash and present it
> > + * to CPU or DMA. SPI master drivers can use this
> > + * callback to implement memory mapped read
> > + * interface. Flash driver (like m25p80) requests
> > + * memory mapped read via this method. The interface
> > + * should  only be used mtd flashes and cannot be
> > + * used with other spi devices.

This comment is *way* too verbose - probably you just need up to the
"Once" here.

> > +   int (*spi_mtd_mmap_read)(struct  spi_device *spi,
> > +loff_t from, size_t len, size_t *retlen,
> > +u_char *buf, u8 read_opcode,
> > +u8 addr_width, u8 dummy_bytes);

> This looks un-manageable to know spi core or master knows what are the
> command or opcode used by spi-nor flash and also I think mmap support
> seems to be flash related or any justification this is spi bus
> master/controller feature?

There seem to be a reasonable number of SPI controllers out there which
have as an extension the ability to do memory mapped reads but are
otherwise perfectly normal SPI controllers and which rely on that for
everything except reads.


signature.asc
Description: Digital signature

Re: [PATCH 2/5] spi: spi-ti-qspi: add mmap mode read support

[Mark Brown]

On Fri, Sep 04, 2015 at 01:59:59PM +0530, Vignesh R wrote:

> +static int ti_qspi_spi_mtd_mmap_read(struct  spi_device *spi,
> +  loff_t from, size_t len,
> +  size_t *retlen, u_char *buf,
> +  u8 read_opcode, u8 addr_width,
> +  u8 dummy_bytes)
> +{
> + struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
> + int ret = 0;
> +
> + spi_bus_lock(qspi->master);

I suspect I'm going to see the answer to this in another patch but the
fact that we're having to take this lock in a driver when it's an op the
core should be calling.

> + ret = pm_runtime_get_sync(qspi->dev);
> + if (ret < 0) {
> + dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
> + return ret;
> + }

This would be better outside the lock, there's no need to have the lock
before we power on and this fixes the fact that you don't release the
lock here.

> + memcpy(buf, (__force void *)(qspi->mmap_base + from), len);

The fact that you're having to cast here should be a warning that
there's someting wrong here.  I think you're looking for
memcpy_fromio().

> @@ -479,6 +576,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
>   master->setup = ti_qspi_setup;
>   master->auto_runtime_pm = true;
>   master->transfer_one_message = ti_qspi_start_transfer_one;
> + master->spi_mtd_mmap_read = ti_qspi_spi_mtd_mmap_read;
>   master->dev.of_node = pdev->dev.of_node;
>   master->bits_per_word_mask = SPI_BPW_MASK(32) | SPI_BPW_MASK(16) |
>SPI_BPW_MASK(8);

Don't we need to map a resource somewhere?


signature.asc
Description: Digital signature

Re: [PATCH 3/5] mtd: devices: m25p80: add support for mmap read request

[Mark Brown]

On Fri, Sep 04, 2015 at 02:00:00PM +0530, Vignesh R wrote:

> + if (spi->master->spi_mtd_mmap_read) {
> + return  spi->master->spi_mtd_mmap_read(spi, from, len,
> +retlen, buf,
> +nor->read_opcode,
> +nor->addr_width,
> +dummy);
> + }

We should be calling some API provided by the SPI core here, not peering
directly into the ops struture.


signature.asc
Description: Digital signature

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

[Mark Brown]

On Fri, Sep 04, 2015 at 01:59:58PM +0530, Vignesh R wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special memory mapped port
> to accesses SPI flash devices in order to increase read performance.
> This means the controller can automatically send the SPI signals
> required to read data from the SPI flash device.

Sorry, also meant to say here: as I kind of indicated in response to the
flash patch I'd expect to see the SPI core know something about this and
export an API for this which is integrated with things like the existing
message queue.


signature.asc
Description: Digital signature

Re: [PATCH] ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410

[Tony Lindgren]

* Nishanth Menon  [150903 12:27]:
> With the support in the generic PM framework for wakeirq and capability
> added to the rtc-ds1307 driver to support this, we can now define the
> optional wakeup irq to allow the RTC to wakeup the system from low power
> modes as part of suspend.
> 
> Signed-off-by: Nishanth Menon 
> ---
> 
> This patch depends on upcoming merge for RTC
> https://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=rtc-next=50
> 
> merge to master of:
> 9901c41bd019 rtc: ds1307: Support optional wakeup interrupt source
> 496a7ede6cac rtc: ds1307: Sort the headers
> e28475b15b65 rtc: ds1307: Switch to managed irq allocation
> 27a1dce6528a rtc: ds1307: Convert to threaded IRQ
> 
> Tested with the above commits from linux-next: 
> http://pastebin.ubuntu.com/12265857/
> 
> Could probably go in round 2 of merges for 4.3?

Applying into omap-for-v4.3/fixes thanks.

Tony
 
>  arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index ede7fb73c717..8464f3cea280 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -526,7 +526,8 @@
>   mcp_rtc: rtc@6f {
>   compatible = "microchip,mcp7941x";
>   reg = <0x6f>;
> - interrupts = ;  /* IRQ_SYS_1N */
> + interrupts-extended = <_mpu GIC_SPI 2 
> IRQ_TYPE_EDGE_RISING>,
> +   <_pmx_core 0x424>;
>  
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins_default>;
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap2plus_defconfig: make PCF857x built-in

[Tony Lindgren]

* Kishon Vijay Abraham I  [150805 06:47]:
> One of the lines from PCF857x is connected to the vdd line of MMC1
> in DRA74x and DRA72x EVMs and is modelled as a regulator. If PCF857x
> is not made as built-in, the regulator_get in omap_hsmmc fails making
> it difficult to use MMC1 as rootfs.
> 
> Make PCF857x built-in.

OK applying as it's a common boot device. But once we're done with
the legacy code removal and initcall clean-up, let's plan on making
everything modular and using a initramfs. People can still change
their .config files to have things built in and the modular .config
should be usable as is for distros.

Regards,

Tony
 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Sekhar Nori 
> ---
>  arch/arm/configs/omap2plus_defconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index ac521e7..7cedfe9 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -236,7 +236,7 @@ CONFIG_SSI_PROTOCOL=m
>  CONFIG_PINCTRL_SINGLE=y
>  CONFIG_DEBUG_GPIO=y
>  CONFIG_GPIO_SYSFS=y
> -CONFIG_GPIO_PCF857X=m
> +CONFIG_GPIO_PCF857X=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_W1=m
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mysterious crashes on OMAP5 uevm

[Dr. H. Nikolaus Schaller]

Am 14.09.2015 um 21:02 schrieb Tony Lindgren :

> * Russell King - ARM Linux  [150914 05:16]:
>> On Fri, Sep 11, 2015 at 03:03:07PM +0100, Russell King - ARM Linux wrote:
>>> 
>>> Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the problem,
>>> and I doubt there's any ARMv6 non-T2 systems out there that would be
>>> affected by clearing the IT state bits.
>> 
>> Please test the following patch:
> 
> While we're waiting for Grazvydas to test.. Looks good to me:
> 
> Acked-by: Tony Lindgren 

I have tested on:
* GTA04 with DM3730 (OMAP3)
* Pyra prototype with OMAP5432
No X server crashes seen any more.

Tested-by: H. Nikolaus Schaller 

--
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: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi

[Tony Lindgren]

* Enric Balletbo Serra  [150907 12:43]:
> 2015-09-07 18:24 GMT+02:00 Javier Martinez Canillas :
> > Only the IGEPv2 boards have a LAN9221i chip connected to the GPMC
> > so the pinmux configuration for the GPIO connected to the IRQ line
> > of the LAN chip should not be defined in the IGEP common dtsi but
> > in the one common to the IGEPv2 boards.
> >
> > While there, use the OMAP3_CORE1_IOPAD() macro for the padconf reg.
> >
> > Suggested-by: Ladislav Michl 
> > Signed-off-by: Javier Martinez Canillas 
...
> 
> Looks good to me.
> 
> Acked-by: Enric Balletbo i Serra 

Applying into omap-for-v4.3/fixes thanks.

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: mysterious crashes on OMAP5 uevm

[Tony Lindgren]

* Russell King - ARM Linux  [150914 05:16]:
> On Fri, Sep 11, 2015 at 03:03:07PM +0100, Russell King - ARM Linux wrote:
> > 
> > Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the problem,
> > and I doubt there's any ARMv6 non-T2 systems out there that would be
> > affected by clearing the IT state bits.
> 
> Please test the following patch:

While we're waiting for Grazvydas to test.. Looks good to me:

Acked-by: Tony Lindgren 
--
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 0/4] ARM: OMAP5/DRA7: minor fixes

[Tony Lindgren]

* Nishanth Menon  [150909 14:21]:
> Hi,
> 
> While doing a SoC only build for DRA7, a few bugs did pop up. The
> following series provides necessary fixups for the same.
> 
> Nishanth Menon (4):
>   ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well
>   ARM: omap2+: board-generic: Remove stale of_irq macros
>   ARM: DRA7: Select missing options for SoC only build
>   ARM: OMAP5: Cleanup options for SoC only build
> 
>  arch/arm/mach-omap2/Kconfig |6 +-
>  arch/arm/mach-omap2/board-generic.c |7 ---
>  arch/arm/mach-omap2/pm.h|3 ++-
>  3 files changed, 7 insertions(+), 9 deletions(-)

Applying all into omap-for-v4.3/fixes thanks.

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 0/3] ARM: OMAP2+: Optimize soc_is calls

[Keerthy]

Hi Tony,

On Monday 07 September 2015 12:35 PM, Keerthy wrote:

The series implements optimizing soc_is calls for DRA7 and AM43XX
family of SoCs. Originally the soc_is calls for DRA7 involved parsing
device tree nodes and some repetitive string comparisons. Optimizing
to store the result and use the result in the subsequent calls.

The series is boot tested on am437x-gp-evm, dra7-evm, dra72-evm.



A gentle ping on this series. This series would be good to include rtc 
hwmods selectively for non-epos evms. Let me know if you have any 
comments on this.


-Keerthy



Keerthy (3):
   ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls
   ARM: dts: AM43x-epos-evm: Add AM438x compatible string for epos
   ARM: OMAP2: AM43XX: Modify optimize string comparisons in soc_is calls

  .../devicetree/bindings/arm/omap/omap.txt  |  5 +++-
  arch/arm/boot/dts/am43x-epos-evm.dts   |  2 +-
  arch/arm/mach-omap2/id.c   | 28 ++
  arch/arm/mach-omap2/soc.h  | 25 +++
  4 files changed, 53 insertions(+), 7 deletions(-)


--
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/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

[Peter Ujfalusi]

Hi Tony,

On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
> Hi,
> 
> this series will enable analog audio (via onboard aic310x codec) for dra7-evm,
> dra72-evm and am57xx-beagle-x15 boards.
> In these board McASP3 is connected to the codec and for the McASP3 we needed 
> to
> have the DMA crossbar in place since the request lines are not mapped by
> default.

Did you had a chance to look at this series?

> Regars,
> Peter
> ---
> Peter Ujfalusi (11):
>   ARM: OMAP: DRA7: hwmod: Add data for McASP3
>   ARM: DTS: dra7: Add McASP3 node
>   ARM: DTS: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw
>   ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
>   ARM: DTS: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus
>   ARM: DTS: dra7-evm: Audio support
>   ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for
> aic3106
>   ARM: DTS: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio
>   ARM: DTS: dra72-evm: Audio support
>   ARM: DTS: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD
>   ARM: DTS: am57xx-beagle-x15: Enable analog audio support
> 
>  arch/arm/boot/dts/am57xx-beagle-x15.dts   |  95 
>  arch/arm/boot/dts/dra7-evm.dts| 142 
> +-
>  arch/arm/boot/dts/dra7.dtsi   |  15 
>  arch/arm/boot/dts/dra72-evm.dts   | 138 +
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  41 +
>  5 files changed, 428 insertions(+), 3 deletions(-)
> 


-- 
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] clk: ti: clk-7xx: Remove hardwired ABE clock configuration

[Peter Ujfalusi]

Hi Tero,

On 08/24/2015 10:35 AM, Peter Ujfalusi wrote:
> The ABE related clocks should be configured via DT and not have it wired
> inside of the kernel.

can you take a look at this patch? It will not cause any regression since we
do not have audio support mainline and the pending series does not need this
part anymore.

> Signed-off-by: Peter Ujfalusi 
> ---
> Hi Tero,
> 
> the ABE PLL configuration can, and will be done for dra7xx in DT with the
> assigned-clocks/rate/parent feature so no need to have this anymore.
> 
> Regards,
> Peter
> 
>  drivers/clk/ti/clk-7xx.c | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
> diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
> index 9b5b289e6334..a911d7de3377 100644
> --- a/drivers/clk/ti/clk-7xx.c
> +++ b/drivers/clk/ti/clk-7xx.c
> @@ -18,7 +18,6 @@
>  
>  #include "clock.h"
>  
> -#define DRA7_DPLL_ABE_DEFFREQ180633600
>  #define DRA7_DPLL_GMAC_DEFFREQ   10
>  #define DRA7_DPLL_USB_DEFFREQ96000
>  
> @@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
>  int __init dra7xx_dt_clk_init(void)
>  {
>   int rc;
> - struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
> + struct clk *dpll_ck, *hdcp_ck;
>  
>   ti_dt_clocks_register(dra7xx_clks);
>  
>   omap2_clk_disable_autoidle_all();
>  
> - abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
> - sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
> - dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
> -
> - rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
> - if (!rc)
> - rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
> - if (rc)
> - pr_err("%s: failed to configure ABE DPLL!\n", __func__);
> -
> - dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
> - rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
> - if (rc)
> - pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
> -
>   dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
>   rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
>   if (rc)
> 


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