Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning
On 11/26/2014 09:27 PM, Felipe Balbi wrote:
> commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> si4713 platform data) updated board-rx51-peripherals.c
> so that si4713 could be easily used on DT boot, but
> it ended up introducing a build warning whenever
> si4713 isn't enabled.
>
> This patches fixes that warning:
>
> arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
> static struct si4713_platform_data rx51_si4713_platform_data = {
>
> Cc: Sebastian Reichel
> Cc: Tony Lindgren
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Felipe Balbi
Acked-by: Hans Verkuil
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index d18a5cf..bda20c5 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -997,9 +997,11 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
> .gpio_reset = 60,
> };
>
> +#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> static struct si4713_platform_data rx51_si4713_platform_data = {
> .is_platform_device = true
> };
> +#endif
>
> static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[]
> = {
> #if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
>
--
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] mailbox/omap: adapt to the new mailbox framework
On 4 November 2014 at 04:35, Suman Anna wrote: > The OMAP mailbox driver and its existing clients (remoteproc > for OMAP4+) are adapted to use the generic mailbox framework. > > The main changes for the adaptation are: > - The tasklet used for Tx is replaced with the state machine from > the generic mailbox framework. The workqueue used for processing > the received messages stays intact for minimizing the effects on > the OMAP mailbox clients. > - The existing exported client API, omap_mbox_get, omap_mbox_put and > omap_mbox_send_msg are deleted, as the framework provides equivalent > functionality. A OMAP-specific omap_mbox_request_channel is added > though to support non-DT way of requesting mailboxes. > - The OMAP mailbox driver is integrated with the mailbox framework > through the proper implementations of mbox_chan_ops, except for > .last_tx_done and .peek_data. The OMAP mailbox driver does not need > these ops, as it is completely interrupt driven. > - The OMAP mailbox driver uses a custom of_xlate controller ops that > allows phandles for the pargs specifier instead of indexing to avoid > any channel registration order dependencies. > - The new framework does not support multiple clients operating on a > single channel, so the reference counting logic is simplified. > - The remoteproc driver (current client) is adapted to use the new API. > The notifier callbacks used within this client is replaced with the > regular callbacks from the newer framework. > - The exported OMAP mailbox API are limited to omap_mbox_save_ctx, > omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq, > with the signature modified to take in the new mbox_chan handle instead > of the OMAP specific omap_mbox handle. The first 2 will be removed when > the OMAP mailbox driver is adapted to runtime_pm. The other exported > API omap_mbox_request_channel will be removed once existing legacy > users are converted to DT. > > Cc: Jassi Brar > Cc: Ohad Ben-Cohen > Signed-off-by: Suman Anna > --- > v3->v4: No code changes, switched the example to use the DSP node instead of > WkupM3 in the bindings document & minor commit description changes. Other than > that, this is a repost of the driver adaptation patch [1] from the OMAP > Mailbox > framework adaptation series [2]. This patch is intended for the 3.19 merge > window, > all the dependent patches in [2] are merged as of 3.18-rc2. The DTS patch in > [2] > will be posted separately. > > [1] http://marc.info/?l=linux-omap&m=141038453917790&w=2 > [2] http://marc.info/?l=linux-omap&m=141038447817775&w=2 > > .../devicetree/bindings/mailbox/omap-mailbox.txt | 23 ++ > drivers/mailbox/omap-mailbox.c | 346 > - > drivers/remoteproc/omap_remoteproc.c | 51 +-- > include/linux/omap-mailbox.h | 16 +- > 4 files changed, 256 insertions(+), 180 deletions(-) > Applied to mailbox-devel, Thanks -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Hi Paul, On Wednesday 26 November 2014 12:34 PM, Paul Walmsley wrote: > Hi Lokesh > > On Tue, 25 Nov 2014, Lokesh Vutla wrote: > >> Hi Paul, >> On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: >>> On Thu, 20 Nov 2014, Lokesh Vutla wrote: >>> On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: > RTC IP have kicker feature which prevents spurious writes to its > registers. > In order to write into any of the RTC registers, KICK values has te be > written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc > sysconfig register without writing into any kick register which is a noop. > When autoidle is allowed for rtc, interruts are not received until > IDLEMODE > is set to SIDLE_SMART_WKUP. > Adding a reset function to unlock RTC registers so that IDLEMODE is > updated. Ping..!! Is this patch acceptable? >>> >>> Lokesh >>> >>> 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, >>> or against v3.19? If so it would be very helpful for the maintainers if >>> you were to state that somewhere. >> Yes. This is a fix, intended to go in 3.18-rc. Sorry should have >> mentioned it. > > A few questions. Do you know when this problem started (in terms of > kernel versions)? This is introduced in v3.18 by commit (6af16a1da ARM: DRA7: Add hook in SoC initcalls to enable pm initialization) > > Also: the patch description states that this is only a problem when > autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS > driver? Or does hwmod wind up doing this after the RTCSS driver unlocks > it? Autoidle is enabled by hwmod by omap2_clk_enable_autoidle_all(). The above patch does it. > >>> 2. Your patch unlocks the RTC registers, but never relocks it. This seems >>> to defeat the point of the spurious write protection. Shouldn't your >>> patch only unlock the RTC immediately before the hwmod code touches the >>> RTC registers, and then relock it immediately afterwards, per SPRUHZ6 >>> section 23.4.3.3? If so then the .reset function pointer is the wrong >>> place for this; I would suggest adding some .lock and .unlock function >>> pointers that are to be called before and after any register write to the >>> IP block. >> Yeah I agree with you. >> Currently rtc driver unlocks these kick registers in probe and leaves it >> unlocks for >> further use. >> But if hwmod does unlock and lock for every sysconfig write driver should >> also >> implement unlock and lock for every rtc register write, which adds an extra >> overhead. >> I am not sure if some one writes into rtc registers other than hwmod and >> driver. >> IMO we can leave it unlocked as the driver does. > > I would think that the best approach would be to set up .lock and .unlock > function pointers, then add a temporary hwmod flag that, if set, would > prevent the .lock function from ever being called. Then once the driver > is fixed, that flag can be dropped. Okay will update it and repost. > >>> 3. Your macros don't mention DRA7xx specifically. Does this sequence >>> apply to some other TI chips, or just DRA7xx? Please document this in a >>> comment above the macros, and possibly change the name of the macros to >>> refer to DRA7XX. >> This sequence applies to AM43xx and AM33xx also. So made it generic. >> Ill document it. > > OK but it would need more than just documentation, right? Wouldn't the > hwmod data also need to be modified for AM33xx/AM43xx to add the .reset > function pointer? Any reason why folks wouldn't have seen this problem on > AM33xx/AM43xx? PRCM in AM33xx and AM43xx does not support HW AUTO for clock domains. It is either SW_SLEEP/SW_WKUP or NO_SLEEP. So RTC is still getting interrupts even IDLEMODE is kept in SMART_IDLE(which is reset value). Thanks and regards, Lokesh > > > - 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
Re: [PATCH v4 0/6] Touchscreen performance related fixes
On Monday 24 November 2014 06:05 PM, Sebastian Andrzej Siewior wrote: > On 11/24/2014 01:16 PM, Vignesh R wrote: > >> I have tried running both IIO and TSC at the same time. But I have never >> seen WARN_ON() even after running for close to 30 min. Can you send me >> the exact script, so that it will be easy to reproduce? > > Sure thing. > - one shell > evtest /dev/input/event2 > - second shell > ./iio-test.sh > with: > > |#!/bin/sh > | > |while [ 1 = 1 ] > |do > |cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw > |done > > > the kernel config: https://breakpoint.cc/am335x-config > I was able to reproduce this issue. When ADC hits WARN_ON(), the TSC steps should be disabled. But, in this case, TSC is sampling the first Y co-ordinate and all TSC steps are enabled. REG_SE: 0x1ffc1 ADC_STAT: 0x24 Any idea why this may be happening? Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/19] usb: dwc3: host: Pass the XHCI_DRD_SUPPORT and XHCI_NEEDS_LHC_RESET quirk
On 2014年11月25日 21:11, George Cherian wrote:
Pass the quir flag XHCI_DRD_SUPPORT from DWC3 host to xhci platform driver.
"quir" to "quirk"
Regards,
Baolu
This enables xhci driver to handle deallocation's differently while in DRD mode.
Pass the quirk flag XHCI_NEEDS_LHC_RESET from DWC3 host to xhci platform
driver. This enables to do LHRESET during xhci_reset().
Signed-off-by: George Cherian
---
drivers/usb/dwc3/host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..257b5b5 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,8 @@ int dwc3_host_init(struct dwc3 *dwc)
#ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
pdata.usb3_lpm_capable = 1;
#endif
+ pdata.usb_drd_support = 1;
+ pdata.usb_needs_lhc_reset = 1;
ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
if (ret) {
--
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+: Warn about deprecated legacy booting mode
* Pali Rohár [141126 15:40]: > > With enabled CONFIG_ARM_APPENDED_DTB=y file /proc/atags is > missing. OK I guess it should not be needed for DT based booting. > > The build_tag_list() should parse ATAG_REVISION and then > > parse_tag_revision() should copy it to system_rev. Maybe try > > adding some printks to see if those functions get called? > > Now I see... Problem is that build_tag_list() is called from > convert_to_tag_list() which is called from setup_machine_tags() > which is called from setup_arch() only if setup_machine_fdt() > call fails. And it fails for *non* DT boot. You can check this > chain too. Thinking about this probably the best long term solution is to pass optional board_revision in the kernel cmdline that can be parsed early and copied to system_rev variable. Or if you can think of some other way to get it, we can set system_rev in pdata-quirks.c. Or maybe add some code to copy the ATAGs somewhere where they are out of the way and don't conflict with the device tree data? Then we can query ATAG_REVISION from pdata-quirks.c and set system_rev. 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Thursday 27 November 2014 00:14:36 Tony Lindgren wrote: > * Pali Rohár [141126 15:03]: > > On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote: > > > > With your patch I'm getting: > > > > Hardware: Nokia RX-51 board > > > > So patch is good. > > Is that a Tested-by: then? :) > Yes for Hardware line you can add my: Tested-by: Pali Rohár > > > > Revision comes from bootloader (via ATAG) and it is HW > > > > revision of N900 device. It cannot be hardcoded into > > > > kernel or DTS as it it depends on HW. > > > > > > Well for the "Revision" line problem, we could pass the > > > revision in cmdline or .dts if not passed in the legacy > > > ATAGs. It sounds like were just not copying it to > > > system_rev for DT based booting? Maybe it's just some > > > missing CONFIG_ATAG option that needs to be enabled? > > > > Yes it looks like DT code does not read Revision ATAG... I > > tried to enable everything but always same problem... > > Maybe check if it shows up properly in /proc/atags or whatever > the interface for it was? > With enabled CONFIG_ARM_APPENDED_DTB=y file /proc/atags is missing. > The build_tag_list() should parse ATAG_REVISION and then > parse_tag_revision() should copy it to system_rev. Maybe try > adding some printks to see if those functions get called? > > Regards, > > Tony Now I see... Problem is that build_tag_list() is called from convert_to_tag_list() which is called from setup_machine_tags() which is called from setup_arch() only if setup_machine_fdt() call fails. And it fails for *non* DT boot. You can check this chain too. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: n900: kernel cmdline from bootloader in DT mode
On Wednesday 26 November 2014 16:22:00 Pavel Machek wrote: > On Wed 2014-11-26 14:36:42, Pali Rohár wrote: > > On Wednesday 26 November 2014 14:28:01 Pavel Machek wrote: > > > Hi! > > > > > > > for some unknown reasons when I compile kernel for n900 > > > > in DT mode it ignore cmdline passed by bootloader. When > > > > I comment > > > > > > > > CONFIG_ARM_APPENDED_DTB=y > > > > > > > > then it boots into legacy board mode and cmdline is used > > > > from bootloader. > > > > > > > > When is problem? > > > > > > It seems to work for me, I'm booting using 0x, with > > > attached config. > > > > > > Pavel > > > > Can you try to set some "root=something" into CONFIG_CMDLINE > > and then add real "root=" param via 0x? > > > > My problem is that I have specified ubifs mtd root in > > CONFIG_CMDLINE and when I set correct root via bootloader > > (from 0x or flasher-3.5) it is ignored and used only > > what is specified in CONFIG_CMDLINE. > > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > CONFIG_CMDLINE="console=ttyO2,115200 console=tty" > > Um.. Internal commandline should be completely ignored for me. > > Do you have > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER? > > Pavel Can you try to set: CONFIG_USE_OF=y CONFIG_ATAGS=y # CONFIG_DEPRECATED_PARAM_STRUCT is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set CONFIG_CMDLINE="init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0" CONFIG_CMDLINE_FROM_BOOTLOADER=y # CONFIG_CMDLINE_EXTEND is not set # CONFIG_CMDLINE_FORCE is not set CONFIG_KEXEC=y CONFIG_ATAGS_PROC=y # CONFIG_CRASH_DUMP is not set CONFIG_AUTO_ZRELADDR=y and then boot kernel 3.18-rc6 with cmdline specified in bootloader? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár [141126 15:03]: > On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote: > > With your patch I'm getting: > > Hardware: Nokia RX-51 board > > So patch is good. Is that a Tested-by: then? :) > > > Revision comes from bootloader (via ATAG) and it is HW > > > revision of N900 device. It cannot be hardcoded into kernel > > > or DTS as it it depends on HW. > > > > Well for the "Revision" line problem, we could pass the > > revision in cmdline or .dts if not passed in the legacy > > ATAGs. It sounds like were just not copying it to system_rev > > for DT based booting? Maybe it's just some missing > > CONFIG_ATAG option that needs to be enabled? > > Yes it looks like DT code does not read Revision ATAG... I tried > to enable everything but always same problem... Maybe check if it shows up properly in /proc/atags or whatever the interface for it was? The build_tag_list() should parse ATAG_REVISION and then parse_tag_revision() should copy it to system_rev. Maybe try adding some printks to see if those functions get called? 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote: > * Pali Rohár [141126 11:24]: > > On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote: > > > * Pali Rohár [141126 10:59]: > > > > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote: > > > > > Maybe Pali can try to restart that discussion? To me > > > > > it seems the /proc/cpuinfo should be the same as it's > > > > > a user interface. Sorry forgot the details of the > > > > > previous discussion.. > > > > > > > > Yes, two days ago I again wrote emails about this > > > > problem... > > > > > > > > E.g. one of them, see: > > > > https://lkml.org/lkml/2014/11/24/774 > > > > > > > > > And with which app was that? Sorry I forgot.. > > > > > > > > More applications/libraries for N900 which running on > > > > Maemo 5 system. Some of them are Nokia proprietary, > > > > some of them are open source and some are mine. > > > > > > > > Basically problem is that non DT boot provides this info > > > > in /proc/cpuinfo: > > > > > > > > Hardware: Nokia RX-51 board > > > > Revision: 0012 > > > > > > > > New DT boot provides this: > > > > > > > > Hardware: Generic OMAP3 (Flattened Device Tree) > > > > Revision: > > > > > > Oh you can easily fix that by adding a n900 specific > > > DT_MACHINE_START entry to mach-omap2/board-generic.c. > > > > I would like to see some solution which does not depend on > > distributing addition patch which will not be in mainline > > kernel... > > Yes mainline of course. Maybe you misunderstood what I was > suggesting, maybe try the attached patch to fix the "Hardware" > line problem in /proc/cpuinfo? > With your patch I'm getting: Hardware: Nokia RX-51 board So patch is good. > > For this problem I proposed patch (which was rejected): > > https://lkml.org/lkml/2014/6/18/853 > > Yes I think that should continue as a separate discussion > too if there are other differences in /proc/cpuinfo. > > > Basically Hardware is used to check if application is > > running on Nokia N900 or not. Also entry from Hardware is > > appended to Web browser user agent and some internet > > services using it as identifier (N900 device). > > > > > The revision entry you can populate too in pdata-quirks.c, > > > or maybe add something generic to populate it based on the > > > cmdline or a dts entry as I believe that comes from the > > > legacy ATAGs. I think that's just the system_rev or some > > > other *_rev global in the kernel. > > > > Revision comes from bootloader (via ATAG) and it is HW > > revision of N900 device. It cannot be hardcoded into kernel > > or DTS as it it depends on HW. > > Well for the "Revision" line problem, we could pass the > revision in cmdline or .dts if not passed in the legacy > ATAGs. It sounds like were just not copying it to system_rev > for DT based booting? Maybe it's just some missing > CONFIG_ATAG option that needs to be enabled? > > Regards, > > Tony > Yes it looks like DT code does not read Revision ATAG... I tried to enable everything but always same problem... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCHv2] rpmsg: compute number of buffers to allocate from vrings
Hi Ohad, > > On Thu, Nov 13, 2014 at 7:46 PM, Suman Anna wrote: >> Hi Ohad, >> >> On 09/16/2014 01:33 PM, Suman Anna wrote: >>> The buffers to be used for communication are allocated during the >>> rpmsg virtio driver's probe, and the total number of buffers is >>> currently hard-coded to 512. The vring configuration can vary from >>> one platform to another or between different remote processors. The >>> setup of the receive buffers will throw a WARN_ON if the associated >>> vrings are configured with less than 256 buffers (in each direction). >>> So, adjust this hard-coded value to rely on the number of buffers the >>> virtqueue vring is setup with, but also limit to use 256 buffers at >>> most in each direction to avoid wacky resource tables consuming up >>> unreasonable memory. >>> >>> NOTE: The number of buffers is already assumed to be symmetrical >>> in each direction, and that logic is not unchanged. >>> >>> Signed-off-by: Suman Anna >>> --- >>> v2 changes: >>> - add upper limit on buffers and update comments >>> - revise patch description >> >> Any comments on this one, if not can you pick this up for 3.19? > > Did some small changes - untested, not even compiled - can you please > make sure it works for you? Yep, I have reviewed and verified the changes, it is good to go. Thanks, 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 v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
Hello, Tony! 24.11.2014 22:47, Tony Lindgren *: > If you post a patch, I can test boot with it. Looks like the failing > ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx. > So I doubt we just want to change the test for for a higher rev number > for OMAP_I2C_REV_ON_3430_3530. You 100% right here. Functional mode bits are unimplemented in the SYSTEST register on omap3530. "10:5 Reserved Write 0s for future compatibility. Read returns 0." That was the reason. My fault. Thank you for giving right directions. Thanks Kevin for running test, so I could debug the reason. Regards, Alexander. -- 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] tty: serial: serial-omap: depend on !8250_omap
Technically speaking this is not required. If both are enabled then the Maikefile order says that 8250 one wins, the second is never probed. If we choose to enable 8250_omap via defconfig then one might get supprised that his console isn't working anymore since nothing says use ttySx instead ttyOx. This patch _tries_ to bring this to the users' attention by not showing the serial-omap driver once the 8250 one is enabled. So the user might choose to use the help text which says that this driver (8250_omap) uses ttySx instead ttyOx. Signed-off-by: Sebastian Andrzej Siewior --- This is my attempt to warn the defconfig user of the defconfig change (which did not yet happen). Any suggestions? drivers/tty/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index e71a28b4b94e..1b1bdf946fee 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1125,7 +1125,7 @@ config SERIAL_OF_PLATFORM config SERIAL_OMAP tristate "OMAP serial port support" - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS && !SERIAL_8250_OMAP select SERIAL_CORE help If you have a machine based on an Texas Instruments OMAP CPU you -- 2.1.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
Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning
On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> si4713 platform data) updated board-rx51-peripherals.c
> so that si4713 could be easily used on DT boot, but
> it ended up introducing a build warning whenever
> si4713 isn't enabled.
>
> This patches fixes that warning:
>
> arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
> static struct si4713_platform_data rx51_si4713_platform_data = {
>
> Cc: Sebastian Reichel
> Cc: Tony Lindgren
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Felipe Balbi
Acked-By: Sebastian Reichel
-- Sebastian
signature.asc
Description: Digital signature
[RFC PATCH v5 1/4] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
From: Vaibhav Bedia
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6b9946 ("timekeeping: Add suspend and resume
of clock event devices") introduced .suspend and .resume
callbacks for clock event devices. Leverage these
callbacks to have AM33XX clockevent timer behave properly
across system suspend.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/timer.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4f61148..5c7ecde 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -67,6 +67,9 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+/* Clockevent hwmod for am335x and am437x suspend */
+struct omap_hwmod *clockevent_gpt_hwmod;
+
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
static unsigned long arch_timer_freq;
@@ -128,6 +131,23 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_idle(struct clock_event_device *unused)
+{
+ if (!clockevent_gpt_hwmod)
+ return;
+
+ omap_hwmod_idle(clockevent_gpt_hwmod);
+}
+
+static void omap_clkevt_unidle(struct clock_event_device *unused)
+{
+ if (!clockevent_gpt_hwmod)
+ return;
+
+ omap_hwmod_enable(clockevent_gpt_hwmod);
+ __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
static struct clock_event_device clockevent_gpt = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
@@ -355,6 +375,14 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
+ if (soc_is_am33xx()) {
+ clockevent_gpt.suspend = omap_clkevt_idle;
+ clockevent_gpt.resume = omap_clkevt_unidle;
+
+ clockevent_gpt_hwmod =
+ omap_hwmod_lookup(clockevent_gpt.name);
+ }
+
pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
clkev.rate);
}
--
2.1.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
[RFC PATCH v5 4/4] ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds
With all the requisite changes in place we can now enable basic
PM support for AM33xx. This patch updates the various OMAP files
to enable suspend-resume on AM33xx.
Because the suspend resume functionality is different on AM33xx
than other OMAP platforms due to the need for M3 firmware and an
IPC channel to be in place, separate PM ops are used instead of
omap_pm_ops.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/Makefile | 2 ++
arch/arm/mach-omap2/common.h | 9 +
arch/arm/mach-omap2/io.c | 1 +
arch/arm/mach-omap2/pm.h | 6 ++
4 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d9e9412..6d1464d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -90,6 +90,7 @@ omap-4-5-pm-common= pm44xx.o
omap-mpuss-lowpower.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-pm-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common)
+obj-$(CONFIG_SOC_AM33XX) += pm33xx.o sleep33xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
@@ -97,6 +98,7 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 377eea8..64bf9a8 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -76,6 +76,15 @@ static inline int omap4_pm_init_early(void)
}
#endif
+#if defined(CONFIG_PM) && defined(CONFIG_SOC_AM33XX)
+int am33xx_pm_init(void);
+#else
+static inline int am33xx_pm_init(void)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_OMAP_MUX
int omap_mux_late_init(void);
#else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 03cbb16..4b7828a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -575,6 +575,7 @@ void __init am33xx_init_early(void)
void __init am33xx_init_late(void)
{
omap_common_late_init();
+ am33xx_pm_init();
}
#endif
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 425bfcd..9e19340 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,6 +81,12 @@ extern unsigned int omap3_do_wfi_sz;
/* ... and its pointer from SRAM after copy */
extern void (*omap3_do_wfi_sram)(void);
+/* am33xx_do_wfi function pointer and size, for copy to SRAM */
+extern void am33xx_do_wfi(void);
+extern unsigned int am33xx_do_wfi_sz;
+extern unsigned int am33xx_resume_offset;
+extern unsigned long am33xx_emif_sram_table;
+
/* save_secure_ram_context function pointer and size, for copy to SRAM */
extern int save_secure_ram_context(u32 *addr);
extern unsigned int save_secure_ram_context_sz;
--
2.1.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
[RFC PATCH v5 2/4] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
In preparation for suspend-resume support for AM33XX, add
the assembly file with the code which is copied to internal
memory (OCMC RAM) during bootup and runs from there.
As part of the low power entry (DeepSleep0 mode in AM33XX TRM),
the code running from OCMC RAM does the following
1. Calls routine to store the EMIF configuration
2. Calls routine to place external memory in self-refresh
3. Disables EMIF clock
4. Executes WFI after writing to MPU_CLKCTRL register.
If no interrupts have come, WFI execution on MPU gets registered
as an interrupt with the WKUP-M3. WKUP-M3 takes care of disabling
some clocks which MPU should not (L3, L4, OCMC RAM etc) and takes
care of clockdomain and powerdomain transitions as part of the
DeepSleep0 mode entry.
In case a late interrupt comes in, WFI ends up as a NOP and MPU
continues execution from internal memory. The 'abort path' code
undoes whatever was done as part of the low power entry and indicates
a suspend failure by passing a non-zero value to the cpu_resume routine.
The 'resume path' code is similar to the 'abort path' with the key
difference of MMU being enabled in the 'abort path' but being
disabled in the 'resume path' due to MPU getting powered off.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/sleep33xx.S | 216
1 file changed, 216 insertions(+)
create mode 100644 arch/arm/mach-omap2/sleep33xx.S
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
new file mode 100644
index 000..9399a16
--- /dev/null
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -0,0 +1,216 @@
+/*
+ * Low level suspend code for AM33XX SoCs
+ *
+ * Copyright (C) 2012-2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia, Dave Gerlach
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "iomap.h"
+#include "cm33xx.h"
+
+#define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003
+#define AM33XX_CM_CLKCTRL_MODULEMODE_ENABLE0x0002
+
+ .text
+ .align 3
+
+ENTRY(am33xx_do_wfi)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ /*
+* Flush all data from the L1 and L2 data cache before disabling
+* SCTLR.C bit.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ /*
+* Clear the SCTLR.C bit to prevent further data cache
+* allocation. Clearing SCTLR.C would make all the data accesses
+* strongly ordered and would not hit the cache.
+*/
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+* Invalidate L1 and L2 data cache.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ ldr r1, ti_emif_save_context
+ blx r1
+
+ ldr r1, ti_emif_enter_sr
+ blx r1
+
+ /* Disable EMIF */
+ ldr r1, virt_emif_clkctrl
+ ldr r2, [r1]
+ bic r2, r2, #AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE
+ str r2, [r1]
+
+ ldr r1, virt_emif_clkctrl
+wait_emif_disable:
+ ldr r2, [r1]
+ ldr r3, module_disabled_val
+ cmp r2, r3
+ bne wait_emif_disable
+
+ /*
+* For the MPU WFI to be registered as an interrupt
+* to WKUP_M3, MPU_CLKCTRL.MODULEMODE needs to be set
+* to DISABLED
+*/
+ ldr r1, virt_mpu_clkctrl
+ ldr r2, [r1]
+ bic r2, r2, #AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE
+ str r2, [r1]
+
+ /*
+* Execute an ISB instruction to ensure that all of the
+* CP15 register changes have been committed.
+*/
+ isb
+
+ /*
+* Execute a barrier instruction to ensure that all cache,
+* TLB and branch predictor maintenance operations issued
+* have completed.
+*/
+ dsb
+ dmb
+
+ /*
+* Execute a WFI instruction and wait until the
+* STANDBYWFI output is asserted to indicate that the
+* CPU is in idle and low power state. CPU can specualatively
+* prefetch the instructions so add NOPs after WFI. Thirteen
+* NOPs as per Cortex-A8 pipeline.
+*/
+ wfi
+
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+
+ /* We come here in case of an abort due to a late interrupt */
+
+ /* Set MP
[RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi, This series is v5 of the series to add suspend/resume support for Texas Instruments AM335x SoC. It has gone through a rather major overhaul since the last version and because of that has been split into multiple different sets of patches, on which this series depends. Previous discussion that influenced there changes can be found here [1]. This series depends on generic sram exec mapping patch here [2], emif series here [3], and wkup_m3_ipc series here [4]. I have pushed a branch containing the patches from ALL required series here [5] for testing or a view of the high level flow of the entire series. The largest change with this revision is the introduction of a wkup_m3_ipc driver which handles all communication with the Cortex M3 present on am335x for handling low power tasks. Previously this was handled in the wkup_m3_rproc driver (also sent in an earlier series) but that driver is now only responsible for booting the wkup_m3. The wkup_m3_ipc driver exposes an API with all required PM functionality needed by the PM code introduced by this series, so the PM code has shrunk considerably. Another major change is that the EMIF code previously present in the sleep33xx asm code and pm33xx code for save and restore of EMIF context and entry into low power mode has all been moved in to a separate EMIF driver, further reducing the size of the PM code. Because of this, moving the emif header defines into include/linux/ti_emif.h is no longer necessary. Other changes include clean up of the timer suspend/resume handlers, now look up hwmod in init and use that handle along with renaming to *_idle/*_unidle to avoid confusion with true suspend handlers. Suspend support requires: CONFIG_TI_EMIF_SRAM CONFIG_WKUP_M3_RPROC CONFIG_WKUP_M3_IPC And also requires AM335x USB support to be enabled to work for multiple cycles. If you want to load firmware from rootfs in /lib/firmware you now must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK. This code works with version 0x189 of the CM3 firmware found here [6] on the next branch, /bin/am335x-pm-firmware.elf. Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg109331.html [2] http://www.spinics.net/linux/lists/kernel/msg1876629.html [3] http://www.spinics.net/linux/lists/kernel/msg1876646.html [4] http://www.spinics.net/linux/lists/kernel/msg1876642.html [5] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6 [6] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next Dave Gerlach (3): ARM: OMAP2+: AM33XX: Add assembly code for PM operations ARM: OMAP2+: AM33XX: Basic suspend resume support ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds Vaibhav Bedia (1): ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device arch/arm/boot/dts/am33xx.dtsi | 2 + arch/arm/mach-omap2/Makefile| 2 + arch/arm/mach-omap2/common.h| 9 ++ arch/arm/mach-omap2/io.c| 1 + arch/arm/mach-omap2/pm.h| 6 + arch/arm/mach-omap2/pm33xx.c| 250 arch/arm/mach-omap2/sleep33xx.S | 216 ++ arch/arm/mach-omap2/timer.c | 28 + 8 files changed, 514 insertions(+) create mode 100644 arch/arm/mach-omap2/pm33xx.c create mode 100644 arch/arm/mach-omap2/sleep33xx.S -- 2.1.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
[RFC PATCH v5 3/4] ARM: OMAP2+: AM33XX: Basic suspend resume support
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x Technical Reference Manual.
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate the resume process. As part of
the boot process, the assembly code is copied over to OCMCRAM
so it can be executed to turn of the EMIF and put DDR into self
refresh.
AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care
of the clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep. This loading
is handled by the remoteproc driver wkup_m3_rproc.
Communication with the WKUP_M3 is handled by a wkup_m3_ipc
driver that exposes the specific PM functionality to be used
the PM code.
In the current implementation when the suspend process
is initiated, MPU interrupts the WKUP_M3 to let it know about
the intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM. The assembly code puts the external RAM in self-refresh
mode, gates the MPU clock, and then finally executes the WFI
instruction. Execution of the WFI instruction with MPU clock gated
triggers another interrupt to the WKUP_M3 which then continues
with the power down sequence wherein the clockdomain and
powerdomain transition takes place. As part of the sleep sequence,
WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
execution on WKUP_M3 causes the hardware to disable the main
oscillator of the SoC and from here system remains in sleep state
until a wake source brings the system into resume path.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
Code is based on work by Vaibhav Bedia.
Signed-off-by: Dave Gerlach
---
arch/arm/boot/dts/am33xx.dtsi | 2 +
arch/arm/mach-omap2/pm33xx.c | 250 ++
2 files changed, 252 insertions(+)
create mode 100644 arch/arm/mach-omap2/pm33xx.c
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b432499..c4210d2 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -80,6 +80,7 @@
mpu {
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
+ sram = <&ocmcram>;
};
};
@@ -744,6 +745,7 @@
ocmcram: ocmcram@4030 {
compatible = "mmio-sram";
reg = <0x4030 0x1>; /* 64k */
+ map-exec;
};
wkup_m3: wkup_m3@44d0 {
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
new file mode 100644
index 000..2baf810
--- /dev/null
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -0,0 +1,250 @@
+/*
+ * AM33XX Power Management Routines
+ *
+ * Copyright (C) 2012-2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia, Dave Gerlach
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "clockdomain.h"
+#include "cm33xx.h"
+#include "common.h"
+#include "pm.h"
+#include "powerdomain.h"
+#include "soc.h"
+
+static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
+static struct clockdomain *gfx_l4ls_clkdm;
+
+static int (*am33xx_do_wfi_sram)(unsigned long unused);
+static phys_addr_t am33xx_do_wfi_sram_phys;
+
+#ifdef CONFIG_SUSPEND
+static int am33xx_pm_suspend(void)
+{
+ int i, ret = 0;
+ int status = 0;
+
+ /* Try to put GFX to sleep */
+ omap_set_pwrdm_state(gfx_pwrdm, PWRDM_POWER_OFF);
+
+ ret = cpu_suspend(0, am33xx_do_wfi_sram);
+
+ status = pwrdm_read_pwrst(gfx_pwrdm);
+ if
Re: [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
On Wednesday 26 November 2014 15:38:09 Dave Gerlach wrote:
> +
> +static const struct wkup_m3_wakeup_src wakeups[] = {
> + {.irq_nr = 35, .src = "USB0_PHY"},
> + {.irq_nr = 36, .src = "USB1_PHY"},
> + {.irq_nr = 40, .src = "I2C0"},
> + {.irq_nr = 41, .src = "RTC Timer"},
> + {.irq_nr = 42, .src = "RTC Alarm"},
> + {.irq_nr = 43, .src = "Timer0"},
> + {.irq_nr = 44, .src = "Timer1"},
> + {.irq_nr = 45, .src = "UART"},
> + {.irq_nr = 46, .src = "GPIO0"},
> + {.irq_nr = 48, .src = "MPU_WAKE"},
> + {.irq_nr = 49, .src = "WDT0"},
> + {.irq_nr = 50, .src = "WDT1"},
> + {.irq_nr = 51, .src = "ADC_TSC"},
> + {.irq_nr = 0, .src = "Unknown"},
> +};
>
This seems awfully specific to some SoC version, and not aware of
IRQ domains. It also seems to be only used in a dev_dbg statement,
so I guess you could just kill this off entirely.
> +static struct rproc *wkup_m3_get_rproc(struct device *dev)
> +{
> + struct device_node *node;
> + struct rproc *rp;
> +
> + node = of_parse_phandle(dev->of_node, "ti,rproc", 0);
> + if (!node)
> + return NULL;
> +
> + dev = bus_find_device(&platform_bus_type, NULL, node, match);
> + if (!dev)
> + return NULL;
> +
> + rp = dev_get_drvdata(dev);
> + return rp;
This is wrong on a number of levels. I suspect what you really want
is an interface exported from drivers/remoteproc that looks up
a 'struct rproc' and performs the necessary reference counting.
That one can just use of_find_node_by_phandle() to get to
a device_node and use that to look up the rproc device in
a linked list it maintains.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
Introduce a wkup_m3_ipc driver to handle communication between the MPU
and Cortex M3 wkup_m3 present on am335x.
This driver is responsible for actually booting the wkup_m3_rproc and
also handling all IPC which is done using the IPC registers in the control
module, a mailbox, and a separate interrupt back from the wkup_m3. A small
API is exposed for executing specific power commands, which include
configuring for low power mode, request a transition to a low power mode,
and status info on a previous transition.
Signed-off-by: Dave Gerlach
---
drivers/soc/ti/Kconfig | 11 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/wkup_m3_ipc.c | 503 +++
include/linux/wkup_m3_ipc.h | 33 +++
4 files changed, 548 insertions(+)
create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
create mode 100644 include/linux/wkup_m3_ipc.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 7266b21..61cda85 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
If unsure, say N.
+config WKUP_M3_IPC
+ bool "TI AM33XX Wkup-M3 IPC Driver"
+ depends on WKUP_M3_RPROC
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ TI AM33XX has a Cortex M3 to handle low power transitions. This IPC
+ driver provides the necessary API to communicate and use the wkup m3
+ for PM features like Suspend/Resume and boots the wkup_m3 using
+ wkup_m3_rproc driver.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 6bed611..b6b8c8b 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
+obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
new file mode 100644
index 000..f915da6
--- /dev/null
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -0,0 +1,503 @@
+/*
+ * AMx3 Wkup M3 IPC driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AM33XX_CTRL_IPC_REG_COUNT 0x8
+#define AM33XX_CTRL_IPC_REG_OFFSET(m) (0x4 + 4 * (m))
+
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI 0x00
+
+#define AM33XX_M3_TXEV_ACK (0x1 << 0)
+#define AM33XX_M3_TXEV_ENABLE (0x0 << 0)
+
+#define IPC_CMD_DS00x4
+#define IPC_CMD_STANDBY0xc
+#define IPC_CMD_RESET 0xe
+#define DS_IPC_DEFAULT 0x
+#define M3_VERSION_UNKNOWN 0x
+#define M3_BASELINE_VERSION0x187
+#define M3_WAKE_SRC_MASK 0xFF
+#define M3_STATUS_RESP_MASK(0x << 16)
+#define M3_FW_VERSION_MASK 0x
+
+#define M3_STATE_UNKNOWN 0
+#define M3_STATE_RESET 1
+#define M3_STATE_INITED2
+#define M3_STATE_MSG_FOR_LP3
+#define M3_STATE_MSG_FOR_RESET 4
+
+struct wkup_m3_wakeup_src {
+ int irq_nr;
+ char src[10];
+};
+
+struct wkup_m3_ipc {
+ struct rproc *rproc;
+
+ void __iomem *ipc_mem_base;
+ struct device *dev;
+
+ int mem_type;
+ unsigned long resume_addr;
+ int state;
+
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox;
+};
+
+static struct wkup_m3_ipc m3_ipc_state;
+
+static DECLARE_COMPLETION(m3_ipc_sync);
+
+static const struct wkup_m3_wakeup_src wakeups[] = {
+ {.irq_nr = 35, .src = "USB0_PHY"},
+ {.irq_nr = 36, .src = "USB1_PHY"},
+ {.irq_nr = 40, .src = "I2C0"},
+ {.irq_nr = 41, .src = "RTC Timer"},
+ {.irq_nr = 42, .src = "RTC Alarm"},
+ {.irq_nr = 43, .src = "Timer0"},
+ {.irq_nr = 44, .src = "Timer1"},
+ {.irq_nr = 45, .src = "UART"},
+ {.irq_nr = 46, .src = "GPIO0"},
+ {.irq_nr = 48, .src = "MPU_WAKE"},
+ {.irq_nr = 49, .src = "WDT0"},
+ {.irq_nr = 50, .src = "WDT1"},
+ {.irq_nr = 51, .src = "ADC_TSC"},
+ {.irq_nr = 0, .src = "Unknown"},
+};
+
+static inline void am33xx_txev_eoi(struct wkup_m3_ipc *m3_ipc)
+{
+ writel(AM33XX_M3_TXEV_ACK,
+ m3_ipc->ipc_mem_base + AM33XX_CONTROL_M3_T
[RFC PATCH 1/3] Documentation: dt: add ti,am3352-emif bindings
Add the device tree bindings document for ti,am3352-emif which
is used by the ti-emif-sram driver to provide low-level PM
functionality.
Signed-off-by: Dave Gerlach
---
.../bindings/memory-controllers/ti/emif-sram.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
diff --git
a/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
new file mode 100644
index 000..72d6db0
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif-sram.txt
@@ -0,0 +1,31 @@
+EMIF SRAM Driver
+=
+
+TI AMx3 family of devices use a similar EMIF to other TI SoCs but have
+different PM requirements. Late suspend code runs from SRAM and requires
+save and restore of EMIF context and placing the SDRAM in and out of
+self-refresh. Because of this, the ti-emif-sram driver introduces
+relocatable PM function that can run from SRAM and place the EMIF in
+the proper state for low-power mode transition.
+
+EMIF Device Node:
+
+A emif node is used to represent an EMIF IP instance within an SoC. The node
+must contain a phandle to an sram node so the ti-emif-sram driver can allocate
+space within the sram and copy the relocatable PM functions.
+
+Required properties:
+
+- compatible: Should be "ti,am3352-emif" for AM33xx SoCs
+- reg: Contains the emif register address ranges.
+- sram:Phandle for generic sram node for the driver
+ to use to copy PM functions to.
+
+Example:
+
+/* AM33xx */
+emif: emif@4c00 {
+ compatible = "ti,am3352-emif";
+ reg = <0x4C00 0x1000>;
+ sram = <&ocmcram>;
+};
--
2.1.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
[RFC PATCH 3/3] ARM: dts: am33xx: Add emif node
Add node for Texas Instruments AM335x EMIF to make use of the
ti-emif-sram driver.
Signed-off-by: Dave Gerlach
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b86d8c0..b432499 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -153,6 +153,12 @@
#dma-cells = <1>;
};
+ emif: emif@4c00 {
+ compatible = "ti,am3352-emif";
+ reg = <0x4C00 0x1000>;
+ sram = <&ocmcram>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
2.1.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
[RFC PATCH 2/3] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
Certain SoCs like Texas Instruments AM335x and AM437x require parts
of the EMIF PM code to run late in the suspend sequence from SRAM,
such as saving and restoring the EMIF context and placing the memory
into self-refresh.
One requirement for these SoC's to suspend and enter it's lowest power
mode, called DeepSleep0, is that the PER power domain must be shut
off. Because the EMIF (DDR Controller) resides within this power
domain, it will lose context during a suspend operation, so we must
save it to restore once we resume. However, we cannot execute this
code from external memory, as it is not available at this point, so
the code must be executed late in the suspend path from SRAM.
This patch introduces a ti-emif-sram driver that includes several
functions written in ARM ASM that are relocatable so the PM SRAM
code can use them. It can export a table containing the absolute
addresses of the available PM functions so that other SRAM code
can branch to them. This code is required for suspend/resume on
AM335x and AM437x to work.
Signed-off-by: Dave Gerlach
---
drivers/memory/Kconfig | 10 ++
drivers/memory/Makefile | 3 +
drivers/memory/emif.h| 8 ++
drivers/memory/ti-emif-sram-pm.S | 233 +++
drivers/memory/ti-emif-sram.c| 195
include/linux/ti-emif-sram.h | 26 +
6 files changed, 475 insertions(+)
create mode 100644 drivers/memory/ti-emif-sram-pm.S
create mode 100644 drivers/memory/ti-emif-sram.c
create mode 100644 include/linux/ti-emif-sram.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6d91c27..02b778e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -41,6 +41,16 @@ config TI_EMIF
parameters and other settings during frequency, voltage and
temperature changes
+config TI_EMIF_SRAM
+ bool "Texas Instruments EMIF SRAM driver"
+ depends on SOC_AM33XX
+ help
+ This driver is for the EMIF module available on Texas Instruments
+ AM33XX SoCs and is required for PM. Certain parts of the EMIF PM
+ code must run from on-chip SRAM late in the suspend sequence so
+ this driver provides several relocatable PM functions for the SoC
+ PM code to use.
+
config MVEBU_DEVBUS
bool "Marvell EBU Device Bus Controller"
default y
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index c32d319..42888c2 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -13,3 +13,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
+obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o ti-emif-sram-pm.o
+
+AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h
index bfe08ba..8e86eb2 100644
--- a/drivers/memory/emif.h
+++ b/drivers/memory/emif.h
@@ -585,5 +585,13 @@ struct emif_regs {
u32 ext_phy_ctrl_3_shdw;
u32 ext_phy_ctrl_4_shdw;
};
+
+struct ti_emif_pm_functions;
+
+extern unsigned int ti_emif_sram;
+extern unsigned int ti_emif_sram_sz;
+extern void __iomem *ti_emif_base_addr_virt;
+extern void __iomem *ti_emif_base_addr_phys;
+extern struct ti_emif_pm_functions ti_emif_pm;
#endif /* __ASSEMBLY__ */
#endif /* __EMIF_H */
diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S
new file mode 100644
index 000..49b0be4
--- /dev/null
+++ b/drivers/memory/ti-emif-sram-pm.S
@@ -0,0 +1,233 @@
+/*
+ * Low level PM code for TI EMIF
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "emif.h"
+
+#define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES 0x00a0
+#define EMIF_POWER_MGMT_SR_TIMER_MASK 0x00f0
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE 0x0200
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK 0x0700
+
+#define EMIF_SDCFG_TYPE_DDR2 0x2 << SDRAM_TYPE_SHIFT
+#define EMIF_STATUS_READY 0x4
+
+ .text
+ .align 3
+
+ENTRY(ti_emif_sram)
+
+/*
+ * void ti_emif_save_context(void)
+ *
+ * Used during suspend to save the context of all required EMIF registers
+ * to local memory if the EMIF is going to lose context during the sleep
+ * transition. Operates on the VIRTUAL address of the E
[RFC PATCH 3/3] ARM: dts: am33xx: Add wkup_m3_ipc node
Add wkup_m3_ipc node for wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach
---
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 41659df..b86d8c0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -848,6 +848,15 @@
reg = <0x4831 0x2000>;
interrupts = <111>;
};
+
+ wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+ compatible = "ti,am3353-wkup-m3-ipc";
+ reg = <0x44e11324 0x0024>;
+ reg-names = "ipc_regs";
+ interrupts = <78>;
+ ti,rproc = <&wkup_m3>;
+ mboxes = <&mailbox &mbox_wkupm3>;
+ };
};
};
--
2.1.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
[RFC PATCH 1/3] Documentation: dt: add ti,am3353-wkup-m3-ipc bindings
Add the device tree bindings document for ti,am3353-wkup-m3-ipc which
is used by the wkup_m3_ipc driver.
Signed-off-by: Dave Gerlach
---
.../devicetree/bindings/soc/ti/wkup_m3_ipc.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
diff --git a/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
new file mode 100644
index 000..ceb6acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/wkup_m3_ipc.txt
@@ -0,0 +1,41 @@
+Wakeup M3 IPC Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU like suspend/resume
+and certain deep C-states for CPU Idle. Once the wkup_m3_ipc driver uses the
+wkup_m3_rproc driver to boot the wkup_m3, it handles communication with the
+CM3 using IPC registers present in the SoC's control module and a mailbox.
+The wkup_m3_ipc exposes an API to allow the SoC PM code to execute specific
+PM tasks.
+
+Wkup M3 Device Node:
+
+A wkup_m3_ipc device node is used to represent a wakeup M3 IP instance within
+an SoC. The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+
+- compatible: Should be "ti,am3353-wkup-m3-ipc" for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+ ipc-regs.
+- reg-names: Name for ipc-regs given above
+- interrupts: Contains the interrupt information for the wkup_m3
+ interrupt that signals the MPU.
+- ti,rproc:Phandle to the wkup_m3 rproc node so the IPC driver
+ can boot it.
+- mboxes: Phandles used by IPC framework to get correct mbox
+ channel for communication. Must point to appropriate
+ mbox_wkupm3 child node.
+
+Example:
+
+/* AM33xx */
+wkup_m3_ipc: wkup_m3_ipc@44e11324 {
+ compatible = "ti,am3353-wkup-m3-ipc";
+ reg = <0x44e11324 0x0024>;
+ reg-names = "ipc_regs";
+ interrupts = <78>;
+ ti,rproc = <&wkup_m3>;
+ mboxes = <&mailbox &mbox_wkupm3>;
+};
--
2.1.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 v2] omap: i2c: don't check bus state IP rev3.3 and earlier
Alexander Kochetkov writes: > 25 нояб. 2014 г., в 22:13, Kevin Hilman написал(а): > >> I'll test your patch on all my OMAP boards. Put whatever debug output >> you want, and I'll send you links to all the boot output. > > Hello, Kevin! > > I've sent the patch[1]. Could you be so kind to run it on all your OMAP > boards? > Thank you very much! > It is not urgent at all. Done. Built for omap2plus_defconfig, boot reports for all my OMAP boards here: http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/ > What is the preferred way for giving patches for you (for future)? Email is fine. I have things fully automated for primary upstream trees (mainline, linux-next, stable, etc.) but for stuff like this, I can trigger one-off tests. However, if Tony wants to have a branch (besides the one already goes to linux-next) which I would add to the automation cycle, I'm willing to do that. > I have one more fixes for i2c-omap (I think final). > I don't want to break tests anymore. > > And I found, that n900 boot test PASS, but in fact it doesn't[2]. > [2] > http://status.armcloud.us/boot/omap3-n900/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ Right. For these boot tests, PASS means it got to a userspace shell, which it did. The kernel got some warnings etc. during boot, but it still booted up to a shell. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] asm-generic: io: Add exec versions of ioremap
On Wednesday 26 November 2014 15:14:00 Dave Gerlach wrote: > @@ -66,6 +66,11 @@ extern void ioport_unmap(void __iomem *); > #define ioremap_wc ioremap_nocache > #endif > > +#ifndef ARCH_HAS_IOREMAP_EXEC > +#define ioremap_exec ioremap > +#define ioremap_exec_nocache ioremap_nocache > +#endif > + > #ifdef CONFIG_PCI > /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ > struct pci_dev; > ioremap and ioremap_nocache are the same, and there is no architecture-independent interface to map an MMIO range as cached because a lot of architectures can't do that. Also, I think there are architectures that cannot execute from uncached memory, so I think adding this as a generic API is not a good idea. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/3] remoteproc: Introduce wkup_m3_rproc driver
Hi, This patch series adds a wkup_m3_rproc driver for TI AM335x SoCs. This family of SoCs contains an ARM Cortex M3 coprocessor that is responsible for low-level power tasks that cannot be handled by the main ARM Cortex A8 so firmware running from the CM3 can be used instead. This driver handles loading of the firmware and reset of the CM3 once it is booted. This patch was split off from v4 of the am335x suspend series, found here [1]. Because of this it is a dependency for v5 of that series. I have pushed a branch based on v3.18-rc6 containing all dependencies here [2] for am33xx suspend for a higher level view of the entire series of patch sets. This patch set depends on series "couple of generic remoteproc enhancements" by Suman Anna found here [3] (Included already in previously mentioned branch) Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg109331.html [2] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6 [3] http://www.spinics.net/lists/arm-kernel/msg362961.html Dave Gerlach (3): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset Documentation: dt: add ti,am3353-wkup-m3 bindings remoteproc: wkup_m3: Add wkup_m3 remote proc driver .../bindings/remoteproc/wkup_m3_rproc.txt | 32 arch/arm/mach-omap2/pdata-quirks.c | 13 ++ drivers/remoteproc/Kconfig | 12 ++ drivers/remoteproc/Makefile| 1 + drivers/remoteproc/wkup_m3_rproc.c | 175 + include/linux/platform_data/wkup_m3.h | 23 +++ 6 files changed, 256 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt create mode 100644 drivers/remoteproc/wkup_m3_rproc.c create mode 100644 include/linux/platform_data/wkup_m3.h -- 2.1.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
[RFC PATCH 3/3] remoteproc: wkup_m3: Add wkup_m3 remote proc driver
Add a remoteproc driver to load the firmware for and boot the wkup_m3
present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control from
the MPU after it has gone into its own low power state and shutting off
any additional peripherals.
The driver expects a resource table to be present in the wkup_m3
firmware to define the required memory resources needed by the wkup_m3,
at least the data memory so that the firmware can be copied to the proper
place for execution.
Signed-off-by: Dave Gerlach
---
drivers/remoteproc/Kconfig | 12 +++
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/wkup_m3_rproc.c | 175 +
3 files changed, 188 insertions(+)
create mode 100644 drivers/remoteproc/wkup_m3_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 5e343ba..7fbdb53 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,6 +41,18 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config WKUP_M3_RPROC
+ bool "AM33xx wkup-m3 remoteproc support"
+ depends on SOC_AM33XX
+ select REMOTEPROC
+ help
+ Say y here to support AM33xx wkup-m3.
+
+ Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for
+ loading of firmware of CM3 PM coprocessor that is present
+ on AM33xx family of SoCs
+ If unsure say N.
+
config DA8XX_REMOTEPROC
tristate "DA8xx/OMAP-L13x remoteproc support"
depends on ARCH_DAVINCI_DA8XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ac2ff75..81b04d1 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o
remoteproc-y += remoteproc_elf_loader.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
+obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc/wkup_m3_rproc.c
new file mode 100644
index 000..8686ca2
--- /dev/null
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -0,0 +1,175 @@
+/*
+ * AMx3 Wkup M3 Remote Processor driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "remoteproc_internal.h"
+
+struct wkup_m3_rproc {
+ struct rproc *rproc;
+ struct platform_device *pdev;
+};
+
+static int wkup_m3_rproc_start(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *m3_rproc = rproc->priv;
+ struct platform_device *pdev = m3_rproc->pdev;
+ struct device *dev = &pdev->dev;
+ struct wkup_m3_platform_data *pdata = dev->platform_data;
+ int ret;
+
+ ret = pdata->deassert_reset(pdev, pdata->reset_name);
+ if (ret) {
+ dev_err(dev, "Unable to reset wkup_m3!\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int wkup_m3_rproc_stop(struct rproc *rproc)
+{
+ struct wkup_m3_rproc *m3_rproc = rproc->priv;
+ struct platform_device *pdev = m3_rproc->pdev;
+ struct device *dev = &pdev->dev;
+ struct wkup_m3_platform_data *pdata = dev->platform_data;
+ int ret;
+
+ ret = pdata->assert_reset(pdev, pdata->reset_name);
+ if (ret) {
+ dev_err(dev, "Unable to assert reset of wkup_m3!\n");
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static struct rproc_ops wkup_m3_rproc_ops = {
+ .start = wkup_m3_rproc_start,
+ .stop = wkup_m3_rproc_stop,
+};
+
+static const struct of_device_id wkup_m3_rproc_of_match[] = {
+ {
+ .compatible = "ti,am3353-wkup-m3",
+ .data = (void *)"am335x-pm-firmware.elf",
+ },
+ {},
+};
+
+static int wkup_m3_rproc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const char *fw_name;
+ struct wkup_m3_platform_data *pdata = dev->platform_data;
+ struct wkup_m3_rproc *m3_rproc;
+ const struct of_device_id *match;
+ struct rproc *rproc;
+ int ret;
+
+ if (!(pdata && pdata->deassert_reset && pdata->assert_reset &&
+ pdata
[RFC PATCH 2/3] Documentation: dt: add ti,am3353-wkup-m3 bindings
Add the device tree bindings document for ti,am3353-wkup-m3 which is
used by the wkup_m3_rproc driver.
Signed-off-by: Dave Gerlach
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..4d64a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,32 @@
+Wakeup M3 Remote Proc Driver
+=
+
+TI AMx3 family of devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this. The wkup_m3 remoteproc driver handles
+the loading of the firmware and booting of the CM3.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC.
+
+Required properties:
+
+- compatible: Should be "ti,am3353-wkup-m3" for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+ umem and dmem.
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,no-reset-on-init: Reset is handled after fw has been loaded, not at
+ init of hwmod.
+
+Example:
+
+/* AM33xx */
+wkup_m3: wkup_m3@44d0 {
+ compatible = "ti,am3353-wkup-m3";
+ reg = <0x44d0 0x4000/* M3 UMEM */
+ 0x44d8 0x2000>; /* M3 DMEM */
+ ti,hwmods = "wkup_m3";
+ ti,no-reset-on-init;
+};
--
2.1.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
[RFC PATCH 1/3] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to provide platform data required for reset
of the wkup_m3 during boot.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/pdata-quirks.c| 13 +
include/linux/platform_data/wkup_m3.h | 23 +++
2 files changed, 36 insertions(+)
create mode 100644 include/linux/platform_data/wkup_m3.h
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index cec9d6c..1c0bcdb 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include "am35xx.h"
#include "common.h"
@@ -260,6 +261,14 @@ static void __init omap3_tao3530_legacy_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+ .reset_name = "wkup_m3",
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
@@ -355,6 +364,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
&am35xx_emac_pdata),
#endif
+#ifdef CONFIG_SOC_AM33XX
+ OF_DEV_AUXDATA("ti,am3353-wkup-m3", 0x44d0, "44d0.wkup_m3",
+ &wkup_m3_data),
+#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux",
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux",
&pcs_pdata),
diff --git a/include/linux/platform_data/wkup_m3.h
b/include/linux/platform_data/wkup_m3.h
new file mode 100644
index 000..6ee33d7
--- /dev/null
+++ b/include/linux/platform_data/wkup_m3.h
@@ -0,0 +1,23 @@
+/*
+ * omap wkup_m3: platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach
+ *
+ * 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.
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_WKUP_M3_H
+#define _LINUX_PLATFORM_DATA_WKUP_M3_H
+
+struct wkup_m3_platform_data {
+ const char *reset_name;
+
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_WKUP_M3_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
Alexander Kochetkov writes: > NOT FOR UPSTREAM > > The patch checks if IP reset during probe could bring I2C bus > to a free state on omap2430 - omap3530 boards. > > I guess, IP hold one of I2C lines in a low state. > I guess, u-boot haven't sent a stop condition. > > The patch is rebased on branch 'i2c/for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > (6e79807443cba7397cd855ed29d6faba51d4c893) > > Signed-off-by: Alexander Kochetkov > Reported-by: Kevin Hilman > Tested-by: Kevin Hilman Built for omap2plus_defconfig and tested on all my OMAP boards. Results here: http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/ -- 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
[RFC PATCH] misc: SRAM: Add option to map SRAM to allow code execution
From: Russ Dill
Allow option for mapping SRAM as executable. This is useful for
platforms using the sram driver that need to run PM code from sram
like several ARM platforms.
Signed-off-by: Russ Dill
Signed-off-by: Dave Gerlach
---
This patch depends on the series here [1] and can be seen in context
as a dependency for am335x suspend in this branch based on v3.18-rc6
here [2].
[1] http://lkml.iu.edu/hypermail/linux/kernel/1411.3/02782.html
[2] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6
Documentation/devicetree/bindings/misc/sram.txt | 1 +
drivers/misc/sram.c | 13 -
include/linux/platform_data/sram.h | 8
3 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 include/linux/platform_data/sram.h
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/misc/sram.txt
index 36cbe5a..c5ecde4 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -33,6 +33,7 @@ Optional properties in the area nodes:
- compatible : standard definition, should contain a vendor specific string
in the form ,[-]
+- map-exec : Map range to allow code execution
Example:
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 21181fa..f5822de 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#define SRAM_GRANULARITY 32
@@ -56,6 +57,7 @@ static int sram_reserve_cmp(void *priv, struct list_head *a,
static int sram_probe(struct platform_device *pdev)
{
+ struct sram_platform_data *pdata = pdev->dev.platform_data;
void __iomem *virt_base;
struct sram_dev *sram;
struct resource *res;
@@ -64,12 +66,21 @@ static int sram_probe(struct platform_device *pdev)
struct sram_reserve *rblocks, *block;
struct list_head reserve_list;
unsigned int nblocks;
+ bool map_exec = false;
int ret;
INIT_LIST_HEAD(&reserve_list);
+ if (of_get_property(pdev->dev.of_node, "map-exec", NULL))
+ map_exec = true;
+ if (pdata && pdata->map_exec)
+ map_exec |= true;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- virt_base = devm_ioremap_resource(&pdev->dev, res);
+ if (map_exec)
+ virt_base = devm_ioremap_exec_resource(&pdev->dev, res);
+ else
+ virt_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(virt_base))
return PTR_ERR(virt_base);
diff --git a/include/linux/platform_data/sram.h
b/include/linux/platform_data/sram.h
new file mode 100644
index 000..8f5c4ba
--- /dev/null
+++ b/include/linux/platform_data/sram.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_SRAM_H
+#define _LINUX_SRAM_H
+
+struct sram_platform_data {
+ bool map_exec;
+};
+
+#endif
--
2.1.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
[RFC PATCH 1/2] asm-generic: io: Add exec versions of ioremap
From: Russ Dill If code is to be copied into and area (such as SRAM) and run, it needs to be marked as exec. Currently only an ARM version of this exists. Signed-off-by: Russ Dill Signed-off-by: Dave Gerlach --- arch/arm/include/asm/io.h | 2 ++ include/asm-generic/iomap.h | 5 + 2 files changed, 7 insertions(+) diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h index 1805674..1d99d42 100644 --- a/arch/arm/include/asm/io.h +++ b/arch/arm/include/asm/io.h @@ -344,6 +344,8 @@ extern void _memset_io(volatile void __iomem *, int, size_t); #define ioremap_nocache(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE) #define ioremap_cache(cookie,size) __arm_ioremap((cookie), (size), MT_DEVICE_CACHED) #define ioremap_wc(cookie,size)__arm_ioremap((cookie), (size), MT_DEVICE_WC) +#define ioremap_exec(cookie,size) __arm_ioremap_exec((cookie), (size), true) +#define ioremap_exec_nocache(cookie,size) __arm_ioremap_exec((cookie), (size), false) #define iounmap__arm_iounmap /* diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h index 1b41011..6648ff3 100644 --- a/include/asm-generic/iomap.h +++ b/include/asm-generic/iomap.h @@ -66,6 +66,11 @@ extern void ioport_unmap(void __iomem *); #define ioremap_wc ioremap_nocache #endif +#ifndef ARCH_HAS_IOREMAP_EXEC +#define ioremap_exec ioremap +#define ioremap_exec_nocache ioremap_nocache +#endif + #ifdef CONFIG_PCI /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev; -- 2.1.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
[RFC PATCH 2/2] lib: devres: Add exec versions of devm_ioremap_resource and friends
From: Russ Dill
Now that there is an _exec version of ioremap, add devm support for it.
Signed-off-by: Russ Dill
Signed-off-by: Dave Gerlach
---
include/linux/device.h | 19 +++-
include/linux/io.h | 9 +++-
lib/devres.c | 125 +++--
3 files changed, 147 insertions(+), 6 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..d336465 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -635,7 +635,24 @@ extern unsigned long devm_get_free_pages(struct device
*dev,
gfp_t gfp_mask, unsigned int order);
extern void devm_free_pages(struct device *dev, unsigned long addr);
-void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *__devm_ioremap_resource(struct device *dev, struct resource *res,
+ bool exec);
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+ struct resource *res)
+{
+ return __devm_ioremap_resource(dev, res, false);
+}
+void __iomem *devm_request_and_ioremap(struct device *dev,
+ struct resource *res);
+
+static inline void __iomem *devm_ioremap_exec_resource(struct device *dev,
+ struct resource *res)
+{
+ return __devm_ioremap_resource(dev, res, true);
+}
+
+void __iomem *devm_request_and_ioremap_exec(struct device *dev,
+ struct resource *res);
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index d5fc9b8..0c6405a 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -61,9 +61,14 @@ static inline void devm_ioport_unmap(struct device *dev,
void __iomem *addr)
#define IOMEM_ERR_PTR(err) (__force void __iomem *)ERR_PTR(err)
void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
- unsigned long size);
+ unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
- unsigned long size);
+ unsigned long size);
+void __iomem *devm_ioremap_exec(struct device *dev, resource_size_t offset,
+ unsigned long size);
+void __iomem *devm_ioremap_exec_nocache(struct device *dev,
+ resource_size_t offset,
+ unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index f4a195a..f5d0eac 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,64 @@ void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_exec - Managed ioremap_exec()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_exec(). Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_exec(struct device *dev, resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_exec(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_exec);
+
+/**
+ * devm_ioremap_exec_nocache - Managed ioremap_exec_nocache()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_exec_nocache(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_exec_nocache(struct device *dev,
+ resource_size_t offset,
+ unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_exec_nocache(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_exec_nocache);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
@@ -104,7 +162,8 @@ EXPORT_SYMBOL(devm_iounmap);
*
[RFC PATCH 0/2] Add ioremap_exec enhancements
Hi, Some platforms need the ability to ioremap memory for use with small chunks of code, like in certain PM applications that run from sram. This series provides a common way to call an arch's ioremap_exec, which currently only exists for ARM, so that we can use it in the generic sram driver in a forthcoming patch. This patch is part of a patch series split into several smaller sets for introducing suspend on AM335x. I plan to use it to copy several pieces of ASM code from an EMIF driver and the SoC PM code to run from SRAM on the SoC. I have pushed a branch here [1] based on v3.18-rc6 with all required patches so that the higher level plan for these patches can be seen. Regards, Dave [1] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6 Russ Dill (2): asm-generic: io: Add exec versions of ioremap lib: devres: Add exec versions of devm_ioremap_resource and friends arch/arm/include/asm/io.h | 2 + include/asm-generic/iomap.h | 5 ++ include/linux/device.h | 19 ++- include/linux/io.h | 9 +++- lib/devres.c| 125 ++-- 5 files changed, 154 insertions(+), 6 deletions(-) -- 2.1.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: omap2: rx51-peripherals: fix build warning
commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
si4713 platform data) updated board-rx51-peripherals.c
so that si4713 could be easily used on DT boot, but
it ended up introducing a build warning whenever
si4713 isn't enabled.
This patches fixes that warning:
arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
static struct si4713_platform_data rx51_si4713_platform_data = {
Cc: Sebastian Reichel
Cc: Tony Lindgren
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index d18a5cf..bda20c5 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -997,9 +997,11 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
};
+#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
static struct si4713_platform_data rx51_si4713_platform_data = {
.is_platform_device = true
};
+#endif
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
--
2.1.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] memory: gpmc: Move omap gpmc code to live under drivers
* Roger Quadros [141126 03:24]: > On 24/11/14 17:44, Tony Lindgren wrote: > > * Roger Quadros [141124 02:02]: > >> On 11/21/2014 08:34 PM, Tony Lindgren wrote: > >>> --- a/drivers/memory/Kconfig > >>> +++ b/drivers/memory/Kconfig > >>> @@ -41,6 +41,14 @@ config TI_EMIF > >>> parameters and other settings during frequency, voltage and > >>> temperature changes > >>> > >>> +config OMAP_GPMC > >>> + bool > >> > >> We should depend on ARCH_OMAP2PLUS. Other platforms won't benefit > >> anything from this driver. > > > > We can't do that yet until we have sorted out the remaining platform > > data issues with arch/arm/mach-omap2/*gpmc*.c files. > > > > So OMAP_GPMC is currently a silent Kconfig option that does not show > > up as the description after the bool is not there, we select > > OMAP_GPMC automatically based on ARCH_OMAP2PLUS. > > > > Once we have the remaining legacy code issues sorted out, we can > > make this into just a regular device driver. > > OK. In that case, > > Acked-by: Roger Quadros Thanks. FYI I did the move now based on what Arnd and I discussed on #armlinux as we were trying to figure out if the earlier gpmc changes should be merged to drivers branch. Arnd, to prettify the diffstats for the arm-soc drivers branch, I've just sent a pull request for these as: "[GIT PULL] move omap gpmc to drivers finally". 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár [141126 11:24]:
> On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:
> > * Pali Rohár [141126 10:59]:
> > > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> > > > Maybe Pali can try to restart that discussion? To me it
> > > > seems the /proc/cpuinfo should be the same as it's a user
> > > > interface. Sorry forgot the details of the previous
> > > > discussion..
> > >
> > > Yes, two days ago I again wrote emails about this problem...
> > >
> > > E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774
> > >
> > > > And with which app was that? Sorry I forgot..
> > >
> > > More applications/libraries for N900 which running on Maemo
> > > 5 system. Some of them are Nokia proprietary, some of them
> > > are open source and some are mine.
> > >
> > > Basically problem is that non DT boot provides this info in
> > > /proc/cpuinfo:
> > >
> > > Hardware: Nokia RX-51 board
> > > Revision: 0012
> > >
> > > New DT boot provides this:
> > >
> > > Hardware: Generic OMAP3 (Flattened Device Tree)
> > > Revision:
> >
> > Oh you can easily fix that by adding a n900 specific
> > DT_MACHINE_START entry to mach-omap2/board-generic.c.
> >
>
> I would like to see some solution which does not depend on
> distributing addition patch which will not be in mainline
> kernel...
Yes mainline of course. Maybe you misunderstood what I was
suggesting, maybe try the attached patch to fix the "Hardware"
line problem in /proc/cpuinfo?
> For this problem I proposed patch (which was rejected):
> https://lkml.org/lkml/2014/6/18/853
Yes I think that should continue as a separate discussion
too if there are other differences in /proc/cpuinfo.
> Basically Hardware is used to check if application is running on
> Nokia N900 or not. Also entry from Hardware is appended to Web
> browser user agent and some internet services using it as
> identifier (N900 device).
>
> > The revision entry you can populate too in pdata-quirks.c,
> > or maybe add something generic to populate it based on the
> > cmdline or a dts entry as I believe that comes from the
> > legacy ATAGs. I think that's just the system_rev or some
> > other *_rev global in the kernel.
>
> Revision comes from bootloader (via ATAG) and it is HW revision
> of N900 device. It cannot be hardcoded into kernel or DTS as it
> it depends on HW.
Well for the "Revision" line problem, we could pass the revision
in cmdline or .dts if not passed in the legacy ATAGs. It sounds
like were just not copying it to system_rev for DT based booting?
Maybe it's just some missing CONFIG_ATAG option that needs to be
enabled?
Regards,
Tony
8<
From: Tony Lindgren
Date: Wed, 26 Nov 2014 11:55:29 -0800
Subject: [PATCH] ARM: OMAP2+: Fix n900 board name for legacy user space
N900 legacy user space apps need the board name in
/proc/cpuinfo to work properly for the Hardware entry.
For other boards this should not be an issues and they
can use the generic Hardware entry.
Let's fix the issue by adding a custom DT_MACHINE_START
for n900.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -118,6 +118,24 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
+/* Some boards need board name for legacy userspace in /proc/cpuinfo */
+static const char *const n900_boards_compat[] __initconst = {
+ "nokia,omap3-n900",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3430_init_early,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = n900_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
+/* Generic omap3 boards, most boards can use these */
static const char *const omap3_boards_compat[] __initconst = {
"ti,omap3430",
"ti,omap3",
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] move omap gpmc to drivers finally
The following changes since commit 6f8782a7a1c826e1c013d6b7d5504af6bcc079e6: ARM: OMAP2+: Remove unnecesary include in GPMC driver (2014-11-06 10:51:06 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/gpmc-move for you to fetch changes up to d2c70f553d7203b9bb37730e577be29794ae3169: memory: gpmc: Move omap gpmc code to live under drivers (2014-11-26 11:11:19 -0800) We can finally move the GPMC code to live in drivers/memory for further clean up work. This series does the move with minimal changes to the code. Tony Lindgren (3): ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header ARM: OMAP2+: Move GPMC initcall to devices.c memory: gpmc: Move omap gpmc code to live under drivers MAINTAINERS| 8 + arch/arm/mach-omap2/Kconfig| 2 + arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-cm-t35.c | 3 +- arch/arm/mach-omap2/board-cm-t3517.c | 3 +- arch/arm/mach-omap2/board-flash.c | 4 +- arch/arm/mach-omap2/board-flash.h | 1 - arch/arm/mach-omap2/board-n8x0.c | 2 - arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +- arch/arm/mach-omap2/devices.c | 26 +++ arch/arm/mach-omap2/gpmc-nand.c| 3 +- arch/arm/mach-omap2/gpmc-onenand.c | 3 +- arch/arm/mach-omap2/gpmc-onenand.h | 24 --- arch/arm/mach-omap2/gpmc.h | 228 + arch/arm/mach-omap2/pm34xx.c | 2 +- drivers/memory/Kconfig | 8 + drivers/memory/Makefile| 1 + .../gpmc.c => drivers/memory/omap-gpmc.c | 91 +--- .../gpmc-nand.h => include/linux/omap-gpmc.h | 18 +- include/linux/platform_data/omap-gpmc.h| 177 22 files changed, 310 insertions(+), 302 deletions(-) delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h rename arch/arm/mach-omap2/gpmc.c => drivers/memory/omap-gpmc.c (95%) rename arch/arm/mach-omap2/gpmc-nand.h => include/linux/omap-gpmc.h (54%) create mode 100644 include/linux/platform_data/omap-gpmc.h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap: i2c: don't check bus state IP rev3.3 and earlier
25 нояб. 2014 г., в 22:13, Kevin Hilman написал(а): > I'll test your patch on all my OMAP boards. Put whatever debug output > you want, and I'll send you links to all the boot output. Hello, Kevin! I've sent the patch[1]. Could you be so kind to run it on all your OMAP boards? Thank you very much! It is not urgent at all. What is the preferred way for giving patches for you (for future)? I have one more fixes for i2c-omap (I think final). I don't want to break tests anymore. And I found, that n900 boot test PASS, but in fact it doesn't[2]. Alexander. [1] http://marc.info/?l=linux-i2c&m=141702877518332&w=2 [2] http://status.armcloud.us/boot/omap3-n900/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ -- 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+: Warn about deprecated legacy booting mode
On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote: > * Pali Rohár [141126 10:59]: > > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote: > > > Maybe Pali can try to restart that discussion? To me it > > > seems the /proc/cpuinfo should be the same as it's a user > > > interface. Sorry forgot the details of the previous > > > discussion.. > > > > Yes, two days ago I again wrote emails about this problem... > > > > E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774 > > > > > And with which app was that? Sorry I forgot.. > > > > More applications/libraries for N900 which running on Maemo > > 5 system. Some of them are Nokia proprietary, some of them > > are open source and some are mine. > > > > Basically problem is that non DT boot provides this info in > > /proc/cpuinfo: > > > > Hardware: Nokia RX-51 board > > Revision: 0012 > > > > New DT boot provides this: > > > > Hardware: Generic OMAP3 (Flattened Device Tree) > > Revision: > > Oh you can easily fix that by adding a n900 specific > DT_MACHINE_START entry to mach-omap2/board-generic.c. > I would like to see some solution which does not depend on distributing addition patch which will not be in mainline kernel... For this problem I proposed patch (which was rejected): https://lkml.org/lkml/2014/6/18/853 Basically Hardware is used to check if application is running on Nokia N900 or not. Also entry from Hardware is appended to Web browser user agent and some internet services using it as identifier (N900 device). > The revision entry you can populate too in pdata-quirks.c, > or maybe add something generic to populate it based on the > cmdline or a dts entry as I believe that comes from the > legacy ATAGs. I think that's just the system_rev or some > other *_rev global in the kernel. > > Regards, > > Tony Revision comes from bootloader (via ATAG) and it is HW revision of N900 device. It cannot be hardcoded into kernel or DTS as it it depends on HW. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár [141126 10:59]: > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote: > > > > Maybe Pali can try to restart that discussion? To me it seems > > the /proc/cpuinfo should be the same as it's a user > > interface. Sorry forgot the details of the previous > > discussion.. > > > > Yes, two days ago I again wrote emails about this problem... > > E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774 > > > And with which app was that? Sorry I forgot.. > > > > More applications/libraries for N900 which running on Maemo 5 > system. Some of them are Nokia proprietary, some of them are open > source and some are mine. > > Basically problem is that non DT boot provides this info in > /proc/cpuinfo: > > Hardware: Nokia RX-51 board > Revision: 0012 > > New DT boot provides this: > > Hardware: Generic OMAP3 (Flattened Device Tree) > Revision: Oh you can easily fix that by adding a n900 specific DT_MACHINE_START entry to mach-omap2/board-generic.c. The revision entry you can populate too in pdata-quirks.c, or maybe add something generic to populate it based on the cmdline or a dts entry as I believe that comes from the legacy ATAGs. I think that's just the system_rev or some other *_rev global in the kernel. 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
[RFC] i2c: omap: TEST: do IP reset during probe.
NOT FOR UPSTREAM
The patch checks if IP reset during probe could bring I2C bus
to a free state on omap2430 - omap3530 boards.
I guess, IP hold one of I2C lines in a low state.
I guess, u-boot haven't sent a stop condition.
The patch is rebased on branch 'i2c/for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
(6e79807443cba7397cd855ed29d6faba51d4c893)
Signed-off-by: Alexander Kochetkov
Reported-by: Kevin Hilman
Tested-by: Kevin Hilman
---
drivers/i2c/busses/i2c-omap.c | 41 +++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4563200..865c9a1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -282,6 +282,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
+static int omap_i2c_wait_for_bb_valid(struct omap_i2c_dev *dev);
+
+static inline void
+omap_i2c_dump_state(const char *func, int line, struct omap_i2c_dev *dev,
const char *msg)
+{
+ u16 systest = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ dev_info(dev->dev, "%s: STAT=0x%04x; IE=0x%04x; CON=0x%04x;
SYSTEST=0x%04x; SDA=%d%d [OI]; SCL=%d%d [OI] (%s:%d)\n",
+ msg,
+ omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG),
+ omap_i2c_read_reg(dev, OMAP_I2C_IE_REG),
+ omap_i2c_read_reg(dev, OMAP_I2C_CON_REG),
+ systest,
+ (systest & OMAP_I2C_SYSTEST_SDA_O_FUNC) ? 1 : 0,
+ (systest & OMAP_I2C_SYSTEST_SDA_I_FUNC) ? 1 : 0,
+ (systest & OMAP_I2C_SYSTEST_SCL_O_FUNC) ? 1 : 0,
+ (systest & OMAP_I2C_SYSTEST_SCL_I_FUNC) ? 1 : 0,
+ func, line);
+}
+#define OMAP_I2C_DUMP_STATE(dev, msg) omap_i2c_dump_state(__func__, __LINE__,
(dev), (msg))
+
static void __omap_i2c_init(struct omap_i2c_dev *dev)
{
@@ -469,6 +489,23 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
__omap_i2c_init(dev);
+ msleep(1);
+ OMAP_I2C_DUMP_STATE(dev, "init0");
+
+ dev->bb_valid = 0;
+ omap_i2c_wait_for_bb_valid(dev);
+ OMAP_I2C_DUMP_STATE(dev, "init1");
+ dev_info(dev->dev, "init1: bb_valid=%d\n", dev->bb_valid);
+
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
+ dev->bb_valid = 0;
+ omap_i2c_wait_for_bb_valid(dev);
+ OMAP_I2C_DUMP_STATE(dev, "init2");
+ dev_info(dev->dev, "init2: bb_valid=%d\n", dev->bb_valid);
+
+ dev->bb_valid = 1;
+
return 0;
}
@@ -1367,8 +1404,8 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_unuse_clocks;
}
- dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr,
-major, minor, dev->speed);
+ dev_info(dev->dev, "bus %d rev%d.%d at %d kHz (rev %08x)\n", adap->nr,
+major, minor, dev->speed, dev->rev);
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
--
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: OMAP2+: Warn about deprecated legacy booting mode
On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> * Pavel Machek [141126 09:31]:
> > On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren
wrote:
> > > > +
> > > > + if (!of_have_populated_dt())
> > > > + pr_warn("WARNING: legacy booting deprecated, please
> > > > update to boot with .dts\n"); +
> > >
> > > Maybe use WARN so that the warning is more verbose and
> > > kernel gets tainted?
> >
> > Well.. Pali still has regression where /proc/cpuinfo changes
> > in a way that breaks existing userspace, when dt is used on
> > N900.
> >
> > And rmk was less then helpfull...
>
> Maybe Pali can try to restart that discussion? To me it seems
> the /proc/cpuinfo should be the same as it's a user
> interface. Sorry forgot the details of the previous
> discussion..
>
Yes, two days ago I again wrote emails about this problem...
E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774
> And with which app was that? Sorry I forgot..
>
More applications/libraries for N900 which running on Maemo 5
system. Some of them are Nokia proprietary, some of them are open
source and some are mine.
Basically problem is that non DT boot provides this info in
/proc/cpuinfo:
Hardware: Nokia RX-51 board
Revision: 0012
New DT boot provides this:
Hardware: Generic OMAP3 (Flattened Device Tree)
Revision:
> It's weird that it's not been an issue for other though?
>
> > Should we maybe solve that before adding backtraces to our
> > boot messages?
>
> With this warning we want to notify the people actually using
> mainline kernel on omap3 that they should update their
> systems. And also let us know on this list about the
> regressions, so I think that's quite valuable.
>
> Regards,
>
> Tony
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pavel Machek [141126 09:31]:
> On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> > Hi,
> >
> > On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > > +
> > > + if (!of_have_populated_dt())
> > > + pr_warn("WARNING: legacy booting deprecated, please update to
> > > boot with .dts\n");
> > > +
> >
> > Maybe use WARN so that the warning is more verbose and kernel gets tainted?
>
> Well.. Pali still has regression where /proc/cpuinfo changes in a way
> that breaks existing userspace, when dt is used on N900.
>
> And rmk was less then helpfull...
Maybe Pali can try to restart that discussion? To me it seems the
/proc/cpuinfo should be the same as it's a user interface. Sorry
forgot the details of the previous discussion..
And with which app was that? Sorry I forgot..
It's weird that it's not been an issue for other though?
> Should we maybe solve that before adding backtraces to our boot
> messages?
With this warning we want to notify the people actually using
mainline kernel on omap3 that they should update their systems.
And also let us know on this list about the regressions, so I
think that's quite valuable.
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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Pali Rohár [141125 13:33]: > On Tuesday 25 November 2014 22:08:17 Pali Rohár wrote: > > On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote: > > > * Sebastian Reichel [131207 15:04]: > > > > On Sat, Dec 07, 2013 at 01:11:37PM -0800, Tony Lindgren > > > > wrote: > > > > > > I asked Pali to send me his copy of the updated NOLO > > > > > > bootloader, so that I can test this. I just checked > > > > > > the omap documentation (I only have access to the > > > > > > public one) and crypto related stuff is not > > > > > > documented for the L3_PM_READ_PERMISSION register. > > > > > > There are a couple of reserved bits, which may be > > > > > > used for this, though. > > > > > > > > > > > > I also CC'd Joel Fernandes, since he worked on the > > > > > > driver before and may have access to the > > > > > > documentation. > > > > > > > > > > Looks like at least the 36xx public version referenced > > > > > here has them: > > > > > > > > > > http://www.spinics.net/lists/linux-omap/msg21857.html > > > > > > > > > > I'd assume the registers are the same for 34xx since we > > > > > don't have them defined separately in the kernel. > > > > > > > > I can't find it in the omap36xx documentation either. > > > > Maybe I search at the wrong position. I tried to find > > > > something crypto related in > > > > > > > > Table 9-89. L3_PM_READ_PERMISSION_i > > > > > > Hmm maybe it's done based on the address in > > > L3_PM_ADDR_MATCH_k? > > > > > > I guess the thing to do would be to compare the register > > > output between the two different firmware versions. > > > > > > Regards, > > > > > > Tony > > > > Tony, if you can tell me how to read those registers I can > > provide output from both bootloaders (one that enable aes > > support in L3 firewall and one which not). > > > > Also I can test other patches or provide other logs if you > > need something more... > CCing Nishanth Menon Maybe just try dumping out the L3_PM_ADDR_MATCH_* registers during the boot? > Problem is that when L3 firewall is not configured by signed > bootloader then loading omap aes driver cause kernel crash. We > need some code which can check if omap aes is enabled or not at > runtime in kernel... > > More details with full email tread conversation is there: > http://thread.gmane.org/gmane.linux.ports.arm.omap/108397/ AFAIK we can't change the configuration, but it should be readable somewhere. Sorry don't know which registers would show the configuration other than the L3_PM_ADDR_MATCH_* registers. 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > +
> > + if (!of_have_populated_dt())
> > + pr_warn("WARNING: legacy booting deprecated, please update to
> > boot with .dts\n");
> > +
>
> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
Well.. Pali still has regression where /proc/cpuinfo changes in a way
that breaks existing userspace, when dt is used on N900.
And rmk was less then helpfull...
Should we maybe solve that before adding backtraces to our boot
messages?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCHv2] rpmsg: compute number of buffers to allocate from vrings
Hi Suman,
On Thu, Nov 13, 2014 at 7:46 PM, Suman Anna wrote:
> Hi Ohad,
>
> On 09/16/2014 01:33 PM, Suman Anna wrote:
>> The buffers to be used for communication are allocated during the
>> rpmsg virtio driver's probe, and the total number of buffers is
>> currently hard-coded to 512. The vring configuration can vary from
>> one platform to another or between different remote processors. The
>> setup of the receive buffers will throw a WARN_ON if the associated
>> vrings are configured with less than 256 buffers (in each direction).
>> So, adjust this hard-coded value to rely on the number of buffers the
>> virtqueue vring is setup with, but also limit to use 256 buffers at
>> most in each direction to avoid wacky resource tables consuming up
>> unreasonable memory.
>>
>> NOTE: The number of buffers is already assumed to be symmetrical
>> in each direction, and that logic is not unchanged.
>>
>> Signed-off-by: Suman Anna
>> ---
>> v2 changes:
>> - add upper limit on buffers and update comments
>> - revise patch description
>
> Any comments on this one, if not can you pick this up for 3.19?
Did some small changes - untested, not even compiled - can you please
make sure it works for you?
Thanks,
Ohad.
From b1b9891441fa33fd0d49b5cb3aa7f04bca1cc1db Mon Sep 17 00:00:00 2001
From: Suman Anna
Date: Tue, 16 Sep 2014 13:33:07 -0500
Subject: [PATCH] rpmsg: use less buffers when vrings are small
Adjust the number of rpmsg buffers to rely on the size of the
vring, instead of using the hard coded value of 512 (256 per
direction).
This is needed when small vrings are being used, where 256
buffers are too much to fit in a vring.
While considering the vring size, keep using the 512 hard coded
value as an upper limit to avoid wacky resource tables consuming
unreasonable amount of memory.
NOTE: The number of buffers is already assumed to be symmetrical
in each direction, and that logic is unchanged.
Signed-off-by: Suman Anna
[edit commit message, small code and comment simplification]
Signed-off-by: Ohad Ben-Cohen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 44 +++-
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index b6135d4..92f6af6 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -41,6 +41,7 @@
* @svq: tx virtqueue
* @rbufs: kernel address of rx buffers
* @sbufs: kernel address of tx buffers
+ * @num_bufs: total number of buffers for rx and tx
* @last_sbuf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
* @tx_lock: protects svq, sbufs and sleepers, to allow concurrent senders.
@@ -60,6 +61,7 @@ struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
void *rbufs, *sbufs;
+ unsigned int num_bufs;
int last_sbuf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
@@ -86,13 +88,14 @@ struct rpmsg_channel_info {
#define to_rpmsg_driver(d) container_of(d, struct rpmsg_driver, drv)
/*
- * We're allocating 512 buffers of 512 bytes for communications, and then
- * using the first 256 buffers for RX, and the last 256 buffers for TX.
+ * We're allocating buffers of 512 bytes each for communications. The
+ * number of buffers will be computed from the number of buffers supported
+ * by the vring, upto a maximum of 512 buffers (256 in each direction).
*
* Each buffer will have 16 bytes for the msg header and 496 bytes for
* the payload.
*
- * This will require a total space of 256KB for the buffers.
+ * This will utilize a maximum total space of 256KB for the buffers.
*
* We might also want to add support for user-provided buffers in time.
* This will allow bigger buffer size flexibility, and can also be used
@@ -102,9 +105,8 @@ struct rpmsg_channel_info {
* can change this without changing anything in the firmware of the remote
* processor.
*/
-#define RPMSG_NUM_BUFS (512)
+#define MAX_RPMSG_NUM_BUFS (512)
#define RPMSG_BUF_SIZE (512)
-#define RPMSG_TOTAL_BUF_SPACE (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)
/*
* Local addresses are dynamically allocated on-demand.
@@ -579,7 +581,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
* either pick the next unused tx buffer
* (half of our buffers are used for sending messages)
*/
- if (vrp->last_sbuf < RPMSG_NUM_BUFS / 2)
+ if (vrp->last_sbuf < vrp->num_bufs / 2)
ret = vrp->sbufs + RPMSG_BUF_SIZE * vrp->last_sbuf++;
/* or recycle a used one */
else
@@ -948,6 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
struct virtproc_info *vrp;
void *bufs_va;
int err = 0, i;
+ size_t total_buf_space;
vrp = kzalloc(sizeof(*vrp), GFP_KERNEL);
if (!vrp)
@@ -968,10 +971,22 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp->rvq = vqs[0];
vrp->svq = vqs[1];
+ /* we expect symmetric tx/rx vrings */
+ WARN_ON(virtqueue_get_vring_size(vrp->rvq) !=
+ virtqueue_get_vring_size(vrp->svq));
+
+ /* we ne
Fix Penguin Penalty 17th October2014 ( mail-archive.com )
Dear Sir Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin Update? It is actually a code name for Google algorithm which aims at decreasing your websites search engine rankings that violate Googles guidelines by using black hat SEO techniques to rank your webpage by giving number of spammy links to the page. We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and Panda. Our clients have survived all the previous and present updates with ease. They have never been hit because we use 100% white hat SEO techniques to rank Webpages. Simple thing that we do to keep websites away from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers to their queries. If you are looking to increase the quality of your websites and to get more targeted traffic or save your websites from these Google penalties email us back with your interest. We will be glad to serve you and help you grow your business. Regards Roshni Patel SEO Manager ( TOB ) B7 Green Avenue, Amritsar 143001 Punjab NO CLICK in the subject to STOP EMAILS -- 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: n900: kernel cmdline from bootloader in DT mode
On Wednesday 26 November 2014 16:22:00 Pavel Machek wrote: > On Wed 2014-11-26 14:36:42, Pali Rohár wrote: > > On Wednesday 26 November 2014 14:28:01 Pavel Machek wrote: > > > Hi! > > > > > > > for some unknown reasons when I compile kernel for n900 > > > > in DT mode it ignore cmdline passed by bootloader. When > > > > I comment > > > > > > > > CONFIG_ARM_APPENDED_DTB=y > > > > > > > > then it boots into legacy board mode and cmdline is used > > > > from bootloader. > > > > > > > > When is problem? > > > > > > It seems to work for me, I'm booting using 0x, with > > > attached config. > > > > > > Pavel > > > > Can you try to set some "root=something" into CONFIG_CMDLINE > > and then add real "root=" param via 0x? > > > > My problem is that I have specified ubifs mtd root in > > CONFIG_CMDLINE and when I set correct root via bootloader > > (from 0x or flasher-3.5) it is ignored and used only > > what is specified in CONFIG_CMDLINE. > > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set > CONFIG_CMDLINE="console=ttyO2,115200 console=tty" > > Um.. Internal commandline should be completely ignored for me. > > Do you have > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER? > > Pavel Yes, I have: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y CONFIG_CMDLINE="" CONFIG_CMDLINE_FROM_BOOTLOADER=y -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: n900: kernel cmdline from bootloader in DT mode
On Wed 2014-11-26 14:36:42, Pali Rohár wrote: > On Wednesday 26 November 2014 14:28:01 Pavel Machek wrote: > > Hi! > > > > > for some unknown reasons when I compile kernel for n900 in > > > DT mode it ignore cmdline passed by bootloader. When I > > > comment > > > > > > CONFIG_ARM_APPENDED_DTB=y > > > > > > then it boots into legacy board mode and cmdline is used > > > from bootloader. > > > > > > When is problem? > > > > It seems to work for me, I'm booting using 0x, with > > attached config. > > Pavel > > Can you try to set some "root=something" into CONFIG_CMDLINE and > then add real "root=" param via 0x? > > My problem is that I have specified ubifs mtd root in > CONFIG_CMDLINE and when I set correct root via bootloader (from > 0x or flasher-3.5) it is ignored and used only what is > specified in CONFIG_CMDLINE. CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set CONFIG_CMDLINE="console=ttyO2,115200 console=tty" Um.. Internal commandline should be completely ignored for me. Do you have CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: n900: kernel cmdline from bootloader in DT mode
On Wednesday 26 November 2014 14:28:01 Pavel Machek wrote: > Hi! > > > for some unknown reasons when I compile kernel for n900 in > > DT mode it ignore cmdline passed by bootloader. When I > > comment > > > > CONFIG_ARM_APPENDED_DTB=y > > > > then it boots into legacy board mode and cmdline is used > > from bootloader. > > > > When is problem? > > It seems to work for me, I'm booting using 0x, with > attached config. > Pavel Can you try to set some "root=something" into CONFIG_CMDLINE and then add real "root=" param via 0x? My problem is that I have specified ubifs mtd root in CONFIG_CMDLINE and when I set correct root via bootloader (from 0x or flasher-3.5) it is ignored and used only what is specified in CONFIG_CMDLINE. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: n900: kernel cmdline from bootloader in DT mode
Hi! > for some unknown reasons when I compile kernel for n900 in DT > mode it ignore cmdline passed by bootloader. When I comment > > CONFIG_ARM_APPENDED_DTB=y > > then it boots into legacy board mode and cmdline is used from > bootloader. > > When is problem? It seems to work for me, I'm booting using 0x, with attached config. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.18.0-rc6 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="-omap3" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 CONFIG_GENERIC_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set # CONFIG_UPROBES is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG
n900: kernel cmdline from bootloader in DT mode
Hello, for some unknown reasons when I compile kernel for n900 in DT mode it ignore cmdline passed by bootloader. When I comment CONFIG_ARM_APPENDED_DTB=y then it boots into legacy board mode and cmdline is used from bootloader. When is problem? In defconfig I have: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y CONFIG_CMDLINE="" CONFIG_CMDLINE_FROM_BOOTLOADER=y -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/3] ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
On 21/11/14 20:34, Tony Lindgren wrote: > We still need to support platform data for omap3 until it's booting > in device tree only mode. So let's add platform_data/omap-gpmc.h for > that, and a minimal linux/omap-gpmc.h for the save and restore used > by the PM code. > > Let's also keep a minimal mach-omap2/gpmc.h still around to avoid > churn on the board-*.c files. Once omap3 boots in device tree only > mode, we can drop mach-omap2/gpmc.h and we can make the data > structures in platform_data/omap-gpmc.h private to the GPMC driver. > > Note that we can now also remove gpmc-nand.h and gpmc-onenand.h. > > Cc: Arnd Bergmann > Cc: Roger Quadros > Signed-off-by: Tony Lindgren Acked-by: Roger Quadros 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 3/3] memory: gpmc: Move omap gpmc code to live under drivers
On 24/11/14 17:44, Tony Lindgren wrote: > * Roger Quadros [141124 02:02]: >> On 11/21/2014 08:34 PM, Tony Lindgren wrote: >>> --- a/drivers/memory/Kconfig >>> +++ b/drivers/memory/Kconfig >>> @@ -41,6 +41,14 @@ config TI_EMIF >>> parameters and other settings during frequency, voltage and >>> temperature changes >>> >>> +config OMAP_GPMC >>> + bool >> >> We should depend on ARCH_OMAP2PLUS. Other platforms won't benefit >> anything from this driver. > > We can't do that yet until we have sorted out the remaining platform > data issues with arch/arm/mach-omap2/*gpmc*.c files. > > So OMAP_GPMC is currently a silent Kconfig option that does not show > up as the description after the bool is not there, we select > OMAP_GPMC automatically based on ARCH_OMAP2PLUS. > > Once we have the remaining legacy code issues sorted out, we can > make this into just a regular device driver. OK. In that case, Acked-by: Roger Quadros 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On 25/11/14 20:10, Mark Brown wrote: > On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote: >> On 24/11/14 19:39, Mark Brown wrote: > The whole series is about HDMI audio, not video. > >>> You know exactly what I mean - the early patches are in drivers/video, >>> don't touch anything outside of that and have no obvious dependencies. > >> My point was, there's no particular reason to apply those patches >> individually. It's an independent series, about HDMI audio, and applying >> only some of the earlier patches does not improve the kernel in visible >> manner. > > Can you please apply them, I'll try to get round to reviewing the audio > bits soon but either these will need applying if the rest of it's OK or > if there does turn out to be a problem they cut down on the size of the > series. I really do want to read it closely, but hopefully by the > weekend. Ok, I've picked the following patches: OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() Tomi signature.asc Description: OpenPGP digital signature
[PATCH] rtc: omap: drop vendor-prefix from power-controller dt property
Drop the vendor-prefix from the "ti,system-power-controller" device-tree
property name.
It has been agreed to make "system-power-controller" a standard property
and to drop the vendor-prefix that is currently used by several drivers.
Note that drivers that have used ",system-power-controller" in a
released kernel will need to support both versions.
Signed-off-by: Johan Hovold
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 4 ++--
arch/arm/boot/dts/am335x-boneblack.dts | 2 +-
drivers/rtc/rtc-omap.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 750efd40c72e..4ba4dbd34289 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -13,7 +13,7 @@ Required properties:
- interrupt-parent: phandle for the interrupt controller
Optional properties:
-- ti,system-power-controller: whether the rtc is controlling the system power
+- system-power-controller: whether the rtc is controlling the system power
through pmic_power_en
Example:
@@ -24,5 +24,5 @@ rtc@1c23000 {
interrupts = <19
19>;
interrupt-parent = <&intc>;
- ti,system-power-controller;
+ system-power-controller;
};
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 0c8cdc9520b7..d4affb7e3b61 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -77,5 +77,5 @@
};
&rtc {
- ti,system-power-controller;
+ system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index fba13e53c278..4f1c6ca97211 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -502,7 +502,7 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
rtc->type = of_id->data;
rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
of_property_read_bool(pdev->dev.of_node,
- "ti,system-power-controller");
+ "system-power-controller");
} else {
id_entry = platform_get_device_id(pdev);
rtc->type = (void *)id_entry->driver_data;
--
2.0.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
