Re: OMAP* Latest build failures

[Russell King - ARM Linux]

On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
> OMAP* allnoconfig fails:
> 
> arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
> twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput'
> arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup':
> twl-common.c:(.init.text+0x8f8): undefined reference to 
> `omap_pm_if_early_init'
> arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port':
> twl-common.c:(.init.text+0x1284): undefined reference to 
> `omap_pm_get_dev_context_loss_count'
> arch/arm/mach-omap2/built-in.o: In function `omap_timer_init':
> twl-common.c:(.init.text+0x1544): undefined reference to 
> `omap_pm_get_dev_context_loss_count'
> arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init':
> twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init'
> arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
> twl-common.c:(.init.text+0x2168): undefined reference to 
> `omap_pm_get_dev_context_loss_count'
> arch/arm/mach-omap2/built-in.o: In function `omap_display_init':
> twl-common.c:(.init.text+0x25cc): undefined reference to 
> `omap_pm_get_dev_context_loss_count'

These are now gone, but we have a new warning:

arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but 
not used

And the randconfig found:

drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_readl':
drivers/staging/omap-thermal/omap-bandgap.c:46:2: error: implicit declaration 
of function 'readl'
drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_writel':
drivers/staging/omap-thermal/omap-bandgap.c:51:2: error: implicit declaration 
of function 'writel'

Which, as its in staging, maybe its not important but it's another source
of unnecessary failure.
--
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: Fix errata 751472 handling on Cortex-A9 r1p*

[Catalin Marinas]

On 16 November 2012 18:39, Russell King - ARM Linux
 wrote:
> On Fri, Nov 16, 2012 at 06:09:28PM +, Catalin Marinas wrote:
>> On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote:
>> > On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote:
>> > > So we should make all these work-arounds depend on !MULTI_PLATFORM then.
>> >
>> > No, because some of the work-arounds don't require setting bits in magic
>> > registers.
>> >
>> > Also realise this: we test for the revision of the CPU to which they're
>> > applicable before attempting to set them.  If you have a work-around
>> > enabled in the kernel, and it fails at boot, _that_ is an indicator not
>> > that the kernel is doing something wrong, but that you need to ensure
>> > that the work-around has been applied by the earlier stages.
>> >
>> > It's not about "but platform X doesn't need it" - it's about platform X
>> > not having the earlier stages updated to fix the errata.
>>
>> There is another aspect. Many CPUs in the field, even if they are a
>> certain rxpy revision, have ECO fixes applied for critical bugs and
>> don't require the workaround. Sometimes those undocumented bits have
>> considerable performance impact and vendors may apply an ECO (unless
>> they are very late in the tape-out process). But the ECO fix does not
>> change the CPU revision, hence the workaround becomes platform specific.
>>
>> That's why I think it's better if those workarounds are just pushed to
>> the boot-loader for multi-platform kernels. Linux could still check the
>> bits and warn about them rather than failing to boot.
>
> ... and that's a U-turn if ever there was one... it's ARM Ltd who've been
> pushing to have these work-arounds in the kernel in the first place.

I wouldn't say it's a U-turn. ARM Ltd never had an official position
(i.e. document) on where the secure-only workarounds should be
implemented (but I think there should have been one). The most
convenient for me and SoC vendors was to push the workarounds into the
kernel, together with other run-time workarounds (which we must keep
in the kernel anyway).

> Should we just remove all the work-arounds, and require boot loaders,
> including the one on Versatile platforms, to implement this?  Why should
> we treat secure platforms be any different from the non-secure ones in
> this regard?  After all, this _does_ stand in the way of a single kernel
> image working properly on secure and non-secure platforms.

I'll ack this (but not all SoC vendors will agree). ARM Ltd, with the
introduction of TZ in ARMv6, made it clear that a general-purpose OS
should not differentiate between secure and non-secure worlds (no
register to read the state from). Furthermore, with the virtualisation
extensions (ARMv7, ARMv8), the general-purpose OS is supposed to run
in non-secure mode. This means that the place for secure-only
workarounds is outside the OS kernel.

> The more this thread progresses, the more I think the decision to put
> errata into the kernel was the wrong one.

Not entirely. This started at a time when we didn't have TZ (ARM1136).
We may also use Linux as a bootloader (kexec) and it's not clear
whether we need a pre-bootloader. But I think for now we could just
make the secure-only boot-time workarounds depend on
!ARCH_MULTIPLATFORM. For newer cores like Cortex-A15/A7 where we know
that Linux always runs in NS mode, don't add new secure-only
workarounds.

For AArch64 I will not merge any secure-only errata workarounds. I'll
leave this to the firmware (can be UEFI or a bootloader). The same for
other implementation-defined bits like SMP/nAMP which Linux can't
touch while in NS mode.

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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Russell King - ARM Linux]

On Fri, Oct 19, 2012 at 02:45:55PM +0200, Péter Ujfalusi wrote:
> Hi,
> 
> On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
> > I'm merely pointing out here that we need their feedback here before
> > deciding if there's anything further that needs to happen.
> 
> Thanks Russell, I'll take a look at the implication of the prefetch for audio.

Péter, any news?
--
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 v5 0/6] Move rest of omap-iommu to live in drivers/iommu

[Joerg Roedel]

On Mon, Nov 12, 2012 at 02:00:34PM -0800, Tony Lindgren wrote:
> Assuming Joerg is OK with these changes, I can push them into
> an immutable branch that Joerg can merge in as needed.
> 
> Further patches on top of this series can then be queued by
> Joerg as arch/arm/*omap* and me are then out of the way of
> iommu development.

Okay, from my side:

Acked-by: Joerg Roedel 

Please let me know which branch I need to pull into my tree when you
merged these patches.


Joerg


--
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: [PATCHv3] i2c: omap: Move the remove constraint

[Shubhrajyoti Datta]

On Fri, Nov 16, 2012 at 7:50 PM, Wolfram Sang  wrote:
> On Thu, Nov 15, 2012 at 02:19:21PM +0530, Shubhrajyoti D wrote:
>> Currently we just queue the transfer and release the
>> qos constraints, however we do not wait for the transfer
>> to complete to release the constraint. Move the remove
>> constraint after the bus busy as we are sure that the
>> transfers are completed by then.
>>
>> Acked-by: Jean Pihet 
>> Signed-off-by: Shubhrajyoti D 
>
> Applied to for-next. Please let me know if it should go to for-current.

I feel for-next should be fine.

>
> --
> Pengutronix e.K.   | Wolfram Sang|
> 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] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration

[Linus Walleij]

On Tue, Nov 13, 2012 at 10:35 AM, Peter Ujfalusi  wrote:

> Avoid using the TWL4030_MODULE_PWMA/B as module ID. The LEDEN, PWMA ON/OFF
> and PWMB ON/OFF registers are in a continuous range starting from LED base.
> This is going to be helpful for further cleanup in the twl stack.
>
> No functional changes.
>
> Signed-off-by: Peter Ujfalusi 

OK if you say so.

Patch applied!

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

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:23 Fri 09 Nov , Stephen Warren wrote:
> On 11/09/2012 09:28 AM, Grant Likely wrote:
> > On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren  
> > wrote:
> ...
> >> I do rather suspect this use-case is quite common. NVIDIA certainly has
> >> a bunch of development boards with pluggable
> >> PMIC/audio/WiFi/display/..., and I believe there's some ability to
> >> re-use the pluggable components with a variety of base-boards.
> >>
> >> Given people within NVIDIA started talking about this recently, I asked
> >> them to enumerate all the boards we have that support pluggable
> >> components, and how common it is that some boards support being plugged
> >> into different main boards. I don't know when that enumeration will
> >> complete (or even start) but hopefully I can provide some feedback on
> >> how common the use-case is for us once it's done.
> > 
> > From your perspective, is it important to use the exact same .dtb
> > overlays for those add-on boards, or is it okay to have a separate
> > build of the overlay for each base tree?
> 
> I certainly think it'd be extremely beneficial to use the exact same
> child board .dtb with arbitrary base boards.
> 
> Consider something like the Arduino shield connector format, which I
> /believe/ has been re-used across a wide variety of Arduino boards and
> other compatible or imitation boards. Now consider a vendor of an
> Arduino shield. The shield vendor probably wants to publish a single
> .dtb file that works for users irrespective of which board they're using
> it with.
> 
> (Well, I'm not sure that Arduino can run Linux; perhaps that's why you
> picked BeagleBone capes for your document!)
> 
> I suppose it would be acceptable for the shield vendor to ship the .dts
> file rather than the .dtb, and hence need to build the shield .dtb for a
> specific base board.
> 
> However, I think the process for an end-user needs to be as simple as
> "drop this .dts/.dtb file into some standard directory", and I imagine
> it'll be much easier for distros/... to make that process work if
> they're dealing with a .dtb that they can just blast into the kernel's
> firmware loader interface, rather than having to also locate the
> base-board .dts/.dtb file, and run dtc and/or other tools on both .dts
> files together.
I've exactly the same issue on Calao or the new atmel boards

We have lego boards

with different cpu-modues running on differetn mother boards with
diferrentdaugther boards

on atmel we are lucky enough we can identity via 1-wire all of them but
on Calao no

On Somfy platform we can detect hardware version and need different pinctrl

So personally I'll prefer to be able to request dtb from the kernel or push
them from the userspace as it will depends where you will detect the hardware
present

The main concern will which part of the kenel will now handle hw detection?

Best Regards,
J.
--
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/5] mmc: omap_hsmmc: Few patches for omap_hsmmc

[Chris Ball]

Hi Venkat,

On Tue, Nov 06 2012, Venkatraman S wrote:
> Hi Chris,
>   Please review and merge the below patches.
> The first one is a bug fix that would be required to be sent
> for 3.7-rcX, others are intended for 3.8.

There have been some changes requested to these -- could you resend your
3.8 queue to me, please?

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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

OMAP baseline test results for v3.7-rc6

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.7-rc6.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc6/20121117093152/


Passing tests
-

Boot to userspace (9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone
  
PM ret/off, suspend + dynamic idle (3/4): 3530es3beagle, 3730beaglexm,
37xxevm


Failing tests: fixed by posted patches
--

Boot tests:

* 3530ES3 Beagle: I2C timeouts during userspace init
  - Intermittent, appears on 5 out of 6 boots here
  - Aaro Koskinen observes this also on N900
  - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
- http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
- http://marc.info/?l=linux-omap&m=135197877112220&w=2
  - Revert posted, pending I2C maintainers:
- http://marc.info/?l=linux-arm-kernel&m=135221953727077&w=2

Other:

* 2420N800: powers down 30 seconds after boot
  - Presumably due to missing CBUS patches for watchdog control
  - http://lkml.org/lkml/2012/9/3/265
  - http://marc.info/?l=linux-omap&m=135274739624125&w=2


Failing tests: needing investigation


Boot tests:

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC

* CM-T3517: boot hangs with MMC root
  - Due to missing MMC setup in board file

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
  - Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent


Failing tests: needing local investigation (may be due to testbed issues)
-

Boot tests:

* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
  - May be fixed now, pending retest:
- http://marc.info/?l=linux-omap&m=135082257727502&w=2
  - Not yet part of the automated test suite
  * May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test

* 4460pandaes: boot fails early
  - Appears to be due to X-loader problems here
  - Need to note the X-loader version so we know it's broken

PM tests:

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock gate ("debug ignore_loglevel")
  - Not shown in the current test logs; cause unknown
  - Pending re-test



vmlinux object size
(delta in bytes from test_v3.7-rc5 (77b67063bb6bce6d475e910d3b886a606d0d91f7)):
   text data  bsstotal  kernel
  +1088   +80+1096  am33xx_only
  +492800+4928  n800_multi_omap2xxx
   +828   +80 +836  n800_only_a
   +932  -24  +32 +940  omap1_defconfig
   +932  -24  +32 +940  omap1_defconfig_1510innovator_only
   +932   +8  +32 +972  omap1_defconfig_5912osk_only
  +1044  +640+1108  omap2plus_defconfig
  +101600+1016  omap2plus_defconfig_2430sdp_only
  +1044 +1280+1172  omap2plus_defconfig_cpupm
  +1044  +640+1108  omap2plus_defconfig_no_pm
  +1044  +640+1108  omap2plus_defconfig_omap2_4_only
  +1168 +1120+1280  omap2plus_defconfig_omap3_4_only
   +760  +40 -396 +404  rmk_omap3430_ldp_allnoconfig
   +984   +80 +992  rmk_omap3430_ldp_oldconfig
   +760  +40 -396 +404  rmk_omap4430_sdp_allnoconfig
   +976 +1120+1088  rmk_omap4430_sdp_oldconfig



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