Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock
On 21/05/15 06:06, Paul Walmsley wrote: >> Enable falls under the "critical clocks" discussion that is ongoing. I >> assume that this is some sort of critical clock that can't be turned off? > > It only needs to be enabled for this particular display IP subsystem to > function: > > http://marc.info/?l=linux-omap&m=142071550111482&w=2 > > I believe Tomi is taking this approach (enabling it unconditionally) to > avoid adding support for a secondary IP block "main clock" to the hwmod Right. I don't think that would be a simple task (correct me if I'm wrong), and that would all be only for this one IP on this particular SoC type. > code. Apparently, the chips that contain this clock gating bit are not > intended to be used for power-critical use cases, so there's not much > motivation to switch it on and off with the display controller. Even in power-critical use cases the the power use difference should be negligible. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
On Thu, May 21, 2015 at 10:16:38PM +0100, Mark Brown wrote: > On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote: > > > Do you want to revert the patch and apply a new one or should I provide a > > patch that reverts the changes and fixes it all in one? > > Can you please send me separate revert and re-add patches, that's > probably going to be easier to review. So after reverting this patch I found there is a issue in that it is difficult to determine when a transfer is complete to properly drive the chipselect from within the transfer_one function. Then I figured that we could handle the case when GPIOs are being used with some conditional calls to omap2_mcspi_set_cs in the omap2_mcspi_work_one function. Near the beginning of the function I added: if (gpio_is_valid(spi->cs_gpio)) omap2_mcspi_set_cs(spi, 0); Near the end of the function I added: if (gpio_is_valid(spi->cs_gpio)) omap2_mcspi_set_cs(spi, 1); This makes GPIO chip select support work while leaving the native working as previous. Is this solution acceptible? In the process of reviewing the changes I found a few other things that should be changed as well. Here you will see a delay that is already handled by the core spi driver: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/spi/spi-omap2-mcspi.c#n1166 In the set_cs function the inversion of the enable that occurs in the core spi_set_cs function based on SPI_CS_HIGH needs to revert as the controller handles the inversion with OMAP2_MCSPI_CHCONF_EPOL bit in the CHCONF register. If you approve of the fix for the GPIO support, I will provide a patch series with all of these above mentioned fixes. -- 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 2.1/2] fixed up omap1 sparse irq support for v4.2
Here's this pull request updated for the randconfig errors found
by Arnd.
The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:
Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v4.2/omap1-v2
for you to fetch changes up to 7bf15c4360b384e34d685616a77a8abf7dd8aea5:
ARM: OMAP1: Fix section mismatch warnings for omap_cfg_reg (2015-05-21
14:50:23 -0700)
Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
to making omap1 support multiarch. After this series we still need to
make omap1 use the common clock framework and fix up the drivers to not
rely on includes from mach and plat directories.
Note that this branch depends on a GPIO driver fix in v4.1-rc3
d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
Tony Lindgren (6):
ARM: OMAP1: Move UART defines to prepare for sparse IRQ
ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ
ARM: omap1: Switch to use MULTI_IRQ
ARM: OMAP1: Change interrupt numbering for sparse IRQ
ARM: OMAP1: Fix randconfig builds if ARCH_OMAP15XX not selected
ARM: OMAP1: Fix section mismatch warnings for omap_cfg_reg
arch/arm/Kconfig | 2 +
arch/arm/mach-omap1/ams-delta-fiq-handler.S| 3 +-
arch/arm/mach-omap1/board-ams-delta.c | 1 +
arch/arm/mach-omap1/board-fsample.c| 1 +
arch/arm/mach-omap1/board-generic.c| 1 +
arch/arm/mach-omap1/board-h2.c | 1 +
arch/arm/mach-omap1/board-h3-mmc.c | 1 +
arch/arm/mach-omap1/board-h3.c | 1 +
arch/arm/mach-omap1/board-htcherald.c | 1 +
arch/arm/mach-omap1/board-innovator.c | 1 +
arch/arm/mach-omap1/board-nokia770.c | 1 +
arch/arm/mach-omap1/board-osk.c| 1 +
arch/arm/mach-omap1/board-palmte.c | 1 +
arch/arm/mach-omap1/board-palmtt.c | 1 +
arch/arm/mach-omap1/board-palmz71.c| 1 +
arch/arm/mach-omap1/board-perseus2.c | 1 +
arch/arm/mach-omap1/board-sx1.c| 1 +
arch/arm/mach-omap1/board-voiceblue.c | 1 +
arch/arm/mach-omap1/common.h | 7 +-
arch/arm/mach-omap1/dma.c | 2 +-
arch/arm/mach-omap1/gpio16xx.c | 2 +
arch/arm/mach-omap1/gpio7xx.c | 2 +
arch/arm/mach-omap1/i2c.c | 3 +-
arch/arm/mach-omap1/include/mach/entry-macro.S | 39 --
arch/arm/mach-omap1/include/mach/irqs.h| 124 ++-
arch/arm/mach-omap1/include/mach/memory.h | 4 +-
arch/arm/mach-omap1/include/mach/serial.h | 5 -
arch/arm/mach-omap1/include/mach/soc.h | 4 +
arch/arm/mach-omap1/irq.c | 157 +++--
arch/arm/mach-omap1/mux.c | 8 +-
arch/arm/mach-omap1/pm.c | 1 +
arch/arm/mach-omap1/serial.c | 1 +
arch/arm/mach-omap1/timer.c| 4 +-
arch/arm/plat-omap/dma.c | 4 +
include/uapi/linux/serial_reg.h| 3 +
35 files changed, 206 insertions(+), 185 deletions(-)
delete mode 100644 arch/arm/mach-omap1/include/mach/entry-macro.S
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
* Arnd Bergmann [150521 14:35]: > On Thursday 21 May 2015 11:36:30 Tony Lindgren wrote: > > > > > > OK got it triggered here too with randconfig builds now. > > > This seems to be related to not selecting some omap1 SoCs or > > > boards. I'll try to do a minimal fix for it today. > > > > > > It seems the include changes you posted would be better done > > > by replacing the the dependencies to mach/irqs.h where possible > > > rather than adding more includes? > > Yes, I guess we can do that too. FWIW, almost all the problems > were uses of cpu_is_omap*(), omap_read*() and omap_write*(). > > There are quite a lot of them overall, but at least they are > easy to grep for, and there should be an obvious fix for each > of them, following what you did on OMAP2 a couple of years ago. Yeah then that can be done one driver at a time. > > OK figured it out. We now rely on an indirect include selected > > with ARCH_OMAP15XX. Here's what I suggest as a fix for this > > issue, obviously the real fix is to fix the legacy drivers to not > > #include . > > Ok, I've put this patch in my randconfig build setup to replace > my older patch, let's see if there are still some corner cases > left. So far, everything looks good (50 random mach-omap1 builds > done). Can you send an updated pull request with the fix folded in? OK will do. I'll also include the secion warning I posted earlier today as that seems to get triggered with some randconfigs because of the __init_or_module. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
On Thursday 21 May 2015 11:36:30 Tony Lindgren wrote: > > > > OK got it triggered here too with randconfig builds now. > > This seems to be related to not selecting some omap1 SoCs or > > boards. I'll try to do a minimal fix for it today. > > > > It seems the include changes you posted would be better done > > by replacing the the dependencies to mach/irqs.h where possible > > rather than adding more includes? Yes, I guess we can do that too. FWIW, almost all the problems were uses of cpu_is_omap*(), omap_read*() and omap_write*(). There are quite a lot of them overall, but at least they are easy to grep for, and there should be an obvious fix for each of them, following what you did on OMAP2 a couple of years ago. > OK figured it out. We now rely on an indirect include selected > with ARCH_OMAP15XX. Here's what I suggest as a fix for this > issue, obviously the real fix is to fix the legacy drivers to not > #include . Ok, I've put this patch in my randconfig build setup to replace my older patch, let's see if there are still some corner cases left. So far, everything looks good (50 random mach-omap1 builds done). Can you send an updated pull request with the fix folded in? 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
Re: High CPU usage when video streaming on EHCI, 3.17.8 kernel with DMA enabled
On Mon, May 18, 2015 at 7:59 AM, Tony Lindgren wrote: > [PATCH] dmaengine: omap-dma: Add support for memcpy Hi Tom, To follow up on your corresponding mail to the gumstix list [1], I tried on the 3.17.8 kernel on an Overo COM (DM37390) with the suggested dmaengine patch applied. Using "hdparm -t --DIRECT /dev/sda" with a USB hard drive attached via the USB EHCI port, I see a read speed of ~24MB/s (vs ~33MB/s on my laptop). I see the same behaviour on a recent kernel (from tony/omap-for-v4.2/cleanup, otherwise works nicely on an Overo FWIW) with and without the dmaengine patch. What would be the expected USB read speed for an OMAP3 platform? --Ash [1] http://gumstix.8.x6.nabble.com/Low-USB-speed-on-Overo-td4969907.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote: > Do you want to revert the patch and apply a new one or should I provide a > patch that reverts the changes and fixes it all in one? Can you please send me separate revert and re-add patches, that's probably going to be easier to review. signature.asc Description: Digital signature
Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
On Thu, May 21, 2015 at 11:18:57AM +0100, Mark Brown wrote: > On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote: > > > My guess is that the set_cs needs to be called even when toggling as GPIO. > > > How should I handle this? > > It shouldn't be part of a set_cs() operation but rather part of the main > transfer operation. Okay then this patch should be reverted. Do you want to revert the patch and apply a new one or should I provide a patch that reverts the changes and fixes it all in one? Sorry for this mess. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap3-devkit8000: Add dm9000 support
Hi,
* Anthoine Bourgeois [150521 12:55]:
> Support dm9000 network interface in the device tree of devkit8000 board.
>
> Signed-off-by: Anthoine Bourgeois
> ---
> arch/arm/boot/dts/omap3-devkit8000.dts | 41
> ++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
> b/arch/arm/boot/dts/omap3-devkit8000.dts
> index 283db1d..b32eeda 100644
> --- a/arch/arm/boot/dts/omap3-devkit8000.dts
> +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
> @@ -158,3 +158,44 @@
> };
> };
> };
> +
> +&gpmc {
> + ranges = <6 0 0x2c00 0x100>; /* CS6: 16MB for DM9000 */
> +
> + ethernet@0,0 {
> + compatible = "davicom,dm9000";
> + reg = <6 0x000 3
> +6 0x400 3>;
So CS6 for GPMC and ioarea at offsets 0 and 0x400.. But the
size of 3 does not look right to me.. That's the size that
gets ioremapped by the Ethernet driver?
> + bank-width = <2>;
> + interrupt-parent = <&gpio1>;/* CS6 -> DM9000 */
Is this comment maybe on the wrong line or how is the GPIO
interrupt related to the CS6? :)
Otherwise looks good to me.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP: enable DM9000 in omap2plus_defconfig
This ethernet device is used on devkit8000 board. Signed-off-by: Anthoine Bourgeois --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 8e10859..08cd89c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -135,6 +135,7 @@ CONFIG_NETDEVICES=y # CONFIG_NET_CADENCE is not set # CONFIG_NET_VENDOR_BROADCOM is not set # CONFIG_NET_VENDOR_CIRRUS is not set +CONFIG_DM9000=y # CONFIG_NET_VENDOR_FARADAY is not set # CONFIG_NET_VENDOR_HISILICON is not set # CONFIG_NET_VENDOR_INTEL is not set -- 2.0.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
[PATCH 1/2] ARM: dts: omap3-devkit8000: Add dm9000 support
Support dm9000 network interface in the device tree of devkit8000 board.
Signed-off-by: Anthoine Bourgeois
---
arch/arm/boot/dts/omap3-devkit8000.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 283db1d..b32eeda 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -158,3 +158,44 @@
};
};
};
+
+&gpmc {
+ ranges = <6 0 0x2c00 0x100>; /* CS6: 16MB for DM9000 */
+
+ ethernet@0,0 {
+ compatible = "davicom,dm9000";
+ reg = <6 0x000 3
+ 6 0x400 3>;
+ bank-width = <2>;
+ interrupt-parent = <&gpio1>;/* CS6 -> DM9000 */
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ davicom,no-eeprom;
+
+ gpmc,mux-add-data = <0>;
+ gpmc,device-width = <1>;
+ gpmc,wait-pin = <0>;
+ gpmc,cycle2cycle-samecsen = <1>;
+ gpmc,cycle2cycle-diffcsen = <1>;
+
+ gpmc,cs-on-ns = <6>;
+ gpmc,cs-rd-off-ns = <180>;
+ gpmc,cs-wr-off-ns = <180>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <18>;
+ gpmc,adv-wr-off-ns = <48>;
+ gpmc,oe-on-ns = <54>;
+ gpmc,oe-off-ns = <168>;
+ gpmc,we-on-ns = <54>;
+ gpmc,we-off-ns = <168>;
+ gpmc,rd-cycle-ns = <186>;
+ gpmc,wr-cycle-ns = <186>;
+ gpmc,access-ns = <144>;
+ gpmc,page-burst-access-ns = <24>;
+ gpmc,bus-turnaround-ns = <90>;
+ gpmc,cycle2cycle-delay-ns = <90>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ gpmc,wr-access-ns = <0>;
+ };
+};
--
2.0.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 1/2] am335x-evm: add mmc3 and wlan definitions to dts
* Eyal Reizer [150503 05:20]: > This includes the wlan regulator, pinmux, DMA > and wlcore bindings. > > Signed-off-by: Arik Nemtsov > Signed-off-by: Eliad Peller > Signed-off-by: Eyal Reizer Applying only 1/2 of this series into omap-for-v4.2/dt thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: Fix section mismatch warnings for omap_cfg_reg
This is cleary used after init time too for example for
configuring UART wake-up events during runtime.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/mux.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 667ce50..599490a 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -36,7 +36,7 @@
static struct omap_mux_cfg arch_mux_cfg;
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
-static struct pin_config __initdata_or_module omap7xx_pins[] = {
+static struct pin_config omap7xx_pins[] = {
MUX_CFG_7XX("E2_7XX_KBR0",12, 21,0, 20, 1, 0)
MUX_CFG_7XX("J7_7XX_KBR1",12, 25,0, 24, 1, 0)
MUX_CFG_7XX("E1_7XX_KBR2",12, 29,0, 28, 1, 0)
@@ -82,7 +82,7 @@ MUX_CFG_7XX("UART_7XX_2", 8,1,6,0, 0,
0)
#endif /* CONFIG_ARCH_OMAP730 || CONFIG_ARCH_OMAP850 */
#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static struct pin_config __initdata_or_module omap1xxx_pins[] = {
+static struct pin_config omap1xxx_pins[] = {
/*
* descriptionmux mode mux pull pull pull pu_pd pu dbg
* reg offset mode reg bit ena reg
@@ -343,7 +343,7 @@ MUX_CFG("Y14_1610_CCP_DATAM",9, 21,6, 2,
3, 1,2, 0, 0)
#define OMAP1XXX_PINS_SZ 0
#endif /* CONFIG_ARCH_OMAP15XX || CONFIG_ARCH_OMAP16XX */
-static int __init_or_module omap1_cfg_reg(const struct pin_config *cfg)
+static int omap1_cfg_reg(const struct pin_config *cfg)
{
static DEFINE_SPINLOCK(mux_spin_lock);
unsigned long flags;
@@ -469,7 +469,7 @@ int __init omap_mux_register(struct omap_mux_cfg
*arch_mux_cfg)
/*
* Sets the Omap MUX and PULL_DWN registers based on the table
*/
-int __init_or_module omap_cfg_reg(const unsigned long index)
+int omap_cfg_reg(const unsigned long index)
{
struct pin_config *reg;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
* Nishanth Menon [150521 00:03]: > On 05/21/2015 01:38 AM, Tero Kristo wrote: > > On 05/21/2015 01:40 AM, Paul Walmsley wrote: > >> On Tue, 19 May 2015, Tero Kristo wrote: > >> > >>> Any news on this? As noted previously, I am not able to reproduce the > >>> issue > >>> you are seeing currently, can you give DEBUG_LL a shot? > >> > >> Yeah I just bisected it, it was caused by this: > >> > >> commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e > >> Author: Felipe Balbi > >> Date: Fri Jan 30 11:18:56 2015 -0600 > >> > >> arm: config: omap2plus_defconfig: switch over to LZMA compression > >> > >> LZMA compression makes about 33% smaller zImage > >> with just a slight extra decompression time. > >> > >> Before this patch, zImage built with o2+_dc > >> is 4.5MiB and after it's about 3.3MiB. > >> > >> Suggested-by: David Cohen > >> Signed-off-by: Felipe Balbi > >> Signed-off-by: Tony Lindgren > >> > >> > >> and the timeouts on the testbed being set to fail if a kernel takes > >> longer > >> than five seconds to start. Seems that the part about a "slight extra > >> decompression time" probably only applies to relatively recent chips. > >> > >> > >> - Paul > >> > > > > Oh, so this explains why I was thinking it took very long time to boot > > the recent kernels also. The boot lag is clearly noticeable without any > > measurement. I wonder if we should probably revert this patch. > > we already have issues with zImage size bloating up and running headlong > into dtb - esp on platforms like N900. Felipe spend quiet some time > getting things into a manageable size here -> loosing 33% sounds like > bad idea to me :( If it affects people using the slower 34xx systems we should probably revert it though. Or make the uncompress somehow faster :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
* Tony Lindgren [150521 09:55]:
> * Tony Lindgren [150521 08:52]:
> > * Arnd Bergmann [150521 08:41]:
> > > On Thursday 21 May 2015 07:58:41 Tony Lindgren wrote:
> > > > * Arnd Bergmann [150521 05:13]:
> > > > > On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > > > > > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit
> > > > > > closer
> > > > > > to making omap1 support multiarch. After this series we still need
> > > > > > to
> > > > > > make omap1 use the common clock framework and fix up the drivers to
> > > > > > not
> > > > > > rely on includes from mach and plat directories.
> > > > > >
> > > > > > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > > > > > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> > > > > >
> > > > >
> > > > > I'm getting lots of build errors in linux-next, which I think are
> > > > > caused by this series.
> > > >
> > > > Hmm is this with make randconfig?
> > >
> > > Yes, all sorts of randconfig builds hit different parts here
> > >
> > > > What's the Kconfig option enabling these errors?
> > >
> > > From what I can tell, this is simply a result of enabling
> > > CONFIG_SPARSE_IRQ, which results in linux/irq.h no longer
> > > implicitly including mach/hardware.h through mach/irqs.h.
> >
> > Hmm not seeing that here, well at least not with what I've
> > tried so far.
> >
> > > You should be able to see these errors by just enabling
> > > the respective drivers. The errors manifest as a long list
> > > of undefined symbols like
> > >
> > > /git/arm-soc/arch/arm/mach-omap1/io.c:33:28: error: 'OMAP1_IO_OFFSET'
> > > undeclared here (not in a function)
> > > /git/arm-soc/arch/arm/mach-omap1/io.c:43:14: error: 'OMAP7XX_DSP_BASE'
> > > undeclared here (not in a function)
> > > /git/arm-soc/arch/arm/mach-omap1/serial.c:114:33: note: each undeclared
> > > identifier is reported only once for each function it appears in
> > > /git/arm-soc/arch/arm/mach-omap1/pm.c:217:23: error:
> > > 'ULPD_SOFT_DISABLE_REQ_REG' undeclared (first use in this function)
> > > /git/arm-soc/drivers/video/fbdev/omap/sossi.c:608:17: error:
> > > 'MOD_CONF_CTRL_1' undeclared (first use in this function)
> > >
> > > Then again, it is possible that I only see the errors because of
> > > an interaction with another patch from my randconfig fixes
> > > series.
> >
> > I think there's something like that going on.. Maybe you're
> > now enabling multiarch for omap1 in your branch?
>
> OK got it triggered here too with randconfig builds now.
> This seems to be related to not selecting some omap1 SoCs or
> boards. I'll try to do a minimal fix for it today.
>
> It seems the include changes you posted would be better done
> by replacing the the dependencies to mach/irqs.h where possible
> rather than adding more includes?
OK figured it out. We now rely on an indirect include selected
with ARCH_OMAP15XX. Here's what I suggest as a fix for this
issue, obviously the real fix is to fix the legacy drivers to not
#include .
Regards,
Tony
8<
From: Tony Lindgren
Date: Thu, 21 May 2015 11:01:29 -0700
Subject: [PATCH] ARM: OMAP1: Fix randconfig builds if ARCH_OMAP15XX not
selected
With the omap1 SPARSE_IRQ changes mach/irqs.h is no longer
automatically included. Turns out now we rely on ARCH_OMAP15XX
including hardware.h from memory.h, so without ARCH_OMAP15XX
we get build failures.
As we have legacy drivers still relying on these indirect
includes, let's not add more mach includes to the drivers.
Those have to be removed anyways for multiplatform support.
Let's fix up mach-omap1 to include soc.h where cpu_is_omap
checks are done, and common.h for board-*.c files.
But let's keep the indirect memory.h include for now to avoid
unnecessary churn in the drivers.
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -16,6 +16,7 @@
#include
+#include "common.h"
#include "board-h3.h"
#include "mmc.h"
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -36,6 +36,8 @@
#include
+#include "soc.h"
+
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
void omap7xx_map_io(void);
#else
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -21,6 +21,8 @@
#include
+#include "soc.h"
+
#define OMAP1610_GPIO1_BASE0xfffbe400
#define OMAP1610_GPIO2_BASE0xfffbec00
#define OMAP1610_GPIO3_BASE0xfffbb400
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -21,6 +21,8 @@
#include
+#include "soc.h"
+
#define OMAP7XX_GPIO1_BASE 0xfffbc000
#define OMAP7XX_GPIO2_BASE 0xfffbc800
#define OMAP7XX_GPIO3_BASE 0xfffbd000
--- a/arch/arm/mach-omap1/include/mach/memory.h
+++ b/arch/arm/mach-omap1/include/mach/memory.h
@@ -5,6 +5,9 @@
#ifndef __ASM_ARCH_MEMORY_H
#define __ASM_ARCH_MEMORY_H
+/* REVISI
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
* Tony Lindgren [150521 08:52]:
> * Arnd Bergmann [150521 08:41]:
> > On Thursday 21 May 2015 07:58:41 Tony Lindgren wrote:
> > > * Arnd Bergmann [150521 05:13]:
> > > > On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > > > > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit
> > > > > closer
> > > > > to making omap1 support multiarch. After this series we still need to
> > > > > make omap1 use the common clock framework and fix up the drivers to
> > > > > not
> > > > > rely on includes from mach and plat directories.
> > > > >
> > > > > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > > > > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> > > > >
> > > >
> > > > I'm getting lots of build errors in linux-next, which I think are
> > > > caused by this series.
> > >
> > > Hmm is this with make randconfig?
> >
> > Yes, all sorts of randconfig builds hit different parts here
> >
> > > What's the Kconfig option enabling these errors?
> >
> > From what I can tell, this is simply a result of enabling
> > CONFIG_SPARSE_IRQ, which results in linux/irq.h no longer
> > implicitly including mach/hardware.h through mach/irqs.h.
>
> Hmm not seeing that here, well at least not with what I've
> tried so far.
>
> > You should be able to see these errors by just enabling
> > the respective drivers. The errors manifest as a long list
> > of undefined symbols like
> >
> > /git/arm-soc/arch/arm/mach-omap1/io.c:33:28: error: 'OMAP1_IO_OFFSET'
> > undeclared here (not in a function)
> > /git/arm-soc/arch/arm/mach-omap1/io.c:43:14: error: 'OMAP7XX_DSP_BASE'
> > undeclared here (not in a function)
> > /git/arm-soc/arch/arm/mach-omap1/serial.c:114:33: note: each undeclared
> > identifier is reported only once for each function it appears in
> > /git/arm-soc/arch/arm/mach-omap1/pm.c:217:23: error:
> > 'ULPD_SOFT_DISABLE_REQ_REG' undeclared (first use in this function)
> > /git/arm-soc/drivers/video/fbdev/omap/sossi.c:608:17: error:
> > 'MOD_CONF_CTRL_1' undeclared (first use in this function)
> >
> > Then again, it is possible that I only see the errors because of
> > an interaction with another patch from my randconfig fixes
> > series.
>
> I think there's something like that going on.. Maybe you're
> now enabling multiarch for omap1 in your branch?
OK got it triggered here too with randconfig builds now.
This seems to be related to not selecting some omap1 SoCs or
boards. I'll try to do a minimal fix for it today.
It seems the include changes you posted would be better done
by replacing the the dependencies to mach/irqs.h where possible
rather than adding more includes?
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
am33xx: ignore SYSBOOT 15:14 if board OSC is known
Currently the processor PLLs and Dividers are configured according to
SYSBOOT levels during boot [1][2].
In the case of boards with expansion capabitliy, like the Beaglebone,
the expansion board might touch this SYSBOOT pins a provide a wrong
clock information.
If we know the OSC on board as a fact (for example 24MHz for the
Beaglebone), the SYSBOOT information can be safely ignored and the
correct value hardcoded on the DT.
The patch following works for am33xx.
Anyway I have some reservations about this. Maybe overriding
"sys_clkin_ck" with "virt_2400_ck" is a better solution?
Regards,
Nuno
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx-clocks.dtsi#n11
[2] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
diff --git a/src/arm/am335x-bone-common.dtsi b/src/arm/am335x-bone-common.dtsi
index 77067d6..1ddaa58 100644
--- a/src/arm/am335x-bone-common.dtsi
+++ b/src/arm/am335x-bone-common.dtsi
@@ -356,6 +356,10 @@
status = "okay";
};
+&sys_clkin_ck {
+ clocks = <&virt_2400_ck>, <&virt_2400_ck>,
<&virt_2400_ck>, <&virt_2400_ck>;
+};
+
/* the cape manager */
/ {
bone_capemgr {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
* Arnd Bergmann [150521 08:41]:
> On Thursday 21 May 2015 07:58:41 Tony Lindgren wrote:
> > * Arnd Bergmann [150521 05:13]:
> > > On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > > > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> > > > to making omap1 support multiarch. After this series we still need to
> > > > make omap1 use the common clock framework and fix up the drivers to not
> > > > rely on includes from mach and plat directories.
> > > >
> > > > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > > > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> > > >
> > >
> > > I'm getting lots of build errors in linux-next, which I think are
> > > caused by this series.
> >
> > Hmm is this with make randconfig?
>
> Yes, all sorts of randconfig builds hit different parts here
>
> > What's the Kconfig option enabling these errors?
>
> From what I can tell, this is simply a result of enabling
> CONFIG_SPARSE_IRQ, which results in linux/irq.h no longer
> implicitly including mach/hardware.h through mach/irqs.h.
Hmm not seeing that here, well at least not with what I've
tried so far.
> You should be able to see these errors by just enabling
> the respective drivers. The errors manifest as a long list
> of undefined symbols like
>
> /git/arm-soc/arch/arm/mach-omap1/io.c:33:28: error: 'OMAP1_IO_OFFSET'
> undeclared here (not in a function)
> /git/arm-soc/arch/arm/mach-omap1/io.c:43:14: error: 'OMAP7XX_DSP_BASE'
> undeclared here (not in a function)
> /git/arm-soc/arch/arm/mach-omap1/serial.c:114:33: note: each undeclared
> identifier is reported only once for each function it appears in
> /git/arm-soc/arch/arm/mach-omap1/pm.c:217:23: error:
> 'ULPD_SOFT_DISABLE_REQ_REG' undeclared (first use in this function)
> /git/arm-soc/drivers/video/fbdev/omap/sossi.c:608:17: error:
> 'MOD_CONF_CTRL_1' undeclared (first use in this function)
>
> Then again, it is possible that I only see the errors because of
> an interaction with another patch from my randconfig fixes
> series.
I think there's something like that going on.. Maybe you're
now enabling multiarch for omap1 in your branch?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
On Thursday 21 May 2015 07:58:41 Tony Lindgren wrote:
> * Arnd Bergmann [150521 05:13]:
> > On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> > > to making omap1 support multiarch. After this series we still need to
> > > make omap1 use the common clock framework and fix up the drivers to not
> > > rely on includes from mach and plat directories.
> > >
> > > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> > >
> >
> > I'm getting lots of build errors in linux-next, which I think are
> > caused by this series.
>
> Hmm is this with make randconfig?
Yes, all sorts of randconfig builds hit different parts here
> What's the Kconfig option enabling these errors?
>From what I can tell, this is simply a result of enabling
CONFIG_SPARSE_IRQ, which results in linux/irq.h no longer
implicitly including mach/hardware.h through mach/irqs.h.
You should be able to see these errors by just enabling
the respective drivers. The errors manifest as a long list
of undefined symbols like
/git/arm-soc/arch/arm/mach-omap1/io.c:33:28: error: 'OMAP1_IO_OFFSET'
undeclared here (not in a function)
/git/arm-soc/arch/arm/mach-omap1/io.c:43:14: error: 'OMAP7XX_DSP_BASE'
undeclared here (not in a function)
/git/arm-soc/arch/arm/mach-omap1/serial.c:114:33: note: each undeclared
identifier is reported only once for each function it appears in
/git/arm-soc/arch/arm/mach-omap1/pm.c:217:23: error:
'ULPD_SOFT_DISABLE_REQ_REG' undeclared (first use in this function)
/git/arm-soc/drivers/video/fbdev/omap/sossi.c:608:17: error: 'MOD_CONF_CTRL_1'
undeclared (first use in this function)
Then again, it is possible that I only see the errors because of
an interaction with another patch from my randconfig fixes
series.
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
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
* Arnd Bergmann [150521 05:13]:
> On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> > to making omap1 support multiarch. After this series we still need to
> > make omap1 use the common clock framework and fix up the drivers to not
> > rely on includes from mach and plat directories.
> >
> > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> >
>
> I'm getting lots of build errors in linux-next, which I think are
> caused by this series.
Hmm is this with make randconfig? What's the Kconfig option enabling
these errors?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
On Thursday 21 May 2015 14:14:12 Arnd Bergmann wrote:
> On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> > Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> > to making omap1 support multiarch. After this series we still need to
> > make omap1 use the common clock framework and fix up the drivers to not
> > rely on includes from mach and plat directories.
> >
> > Note that this branch depends on a GPIO driver fix in v4.1-rc3
> > d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
> >
>
> fwiw, I have another patch in my 'multiplatform' series that will add
> another baby step.
>
> 8<---
> ARM: OMAP1: make header files local if possible
>
> A number of header files in mach-omap1 are never included from outside
> of mach-omap1, so we can move them directly to that directory.
>
> Signed-off-by: Arnd Bergmann
and three more:
diff --git a/arch/arm/mach-omap1/board-h3.h b/arch/arm/mach-omap1/board-h3.h
index 78de535be3c5..f70c42801969 100644
--- a/arch/arm/mach-omap1/board-h3.h
+++ b/arch/arm/mach-omap1/board-h3.h
@@ -27,6 +27,8 @@
#ifndef __ASM_ARCH_OMAP_H3_H
#define __ASM_ARCH_OMAP_H3_H
+#include
+
#define H3_TPS_GPIO_BASE (OMAP_MAX_GPIO_LINES + 16 /* MPUIO */)
# define H3_TPS_GPIO_MMC_PWR_EN (H3_TPS_GPIO_BASE + 4)
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index e2fcdb8e5596..8a3690b2acbd 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -45,6 +45,7 @@
#include
+#include
#include
#include "omap_udc.h"
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 6bb623a2a4df..1f6c8d91f738 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -34,6 +34,7 @@
#include
#ifdef CONFIG_ARCH_OMAP1
+#include
#define pcm_omap1510() cpu_is_omap1510()
#else
#define pcm_omap1510() 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: [GIT PULL 2/2] omap1 sparse irq support for v4.2
On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> to making omap1 support multiarch. After this series we still need to
> make omap1 use the common clock framework and fix up the drivers to not
> rely on includes from mach and plat directories.
>
> Note that this branch depends on a GPIO driver fix in v4.1-rc3
> d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
>
fwiw, I have another patch in my 'multiplatform' series that will add
another baby step.
8<---
ARM: OMAP1: make header files local if possible
A number of header files in mach-omap1 are never included from outside
of mach-omap1, so we can move them directly to that directory.
Signed-off-by: Arnd Bergmann
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..9fc70978823b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -41,7 +41,7 @@
#include
#include
-#include
+#include "camera.h"
#include
#include "iomap.h"
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 0fb51d22c8b5..fad95b74bb65 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -29,7 +29,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 8340d684d8b6..cd146ed0538d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -42,7 +42,7 @@
#include
#include
#include
-#include
+#include "flash.h"
#include
#include
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 086ff34e072b..f7c8c63dd532 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -44,7 +44,7 @@
#include
#include
#include
-#include
+#include "flash.h"
#include
#include
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index ed4e045c2ad8..ae90bd02b3bf 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -32,7 +32,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 0efd165b8227..209aecb0df68 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -46,7 +46,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmte.c
b/arch/arm/mach-omap1/board-palmte.c
index 1142ae431fe0..e5288cda1a6a 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -34,7 +34,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmtt.c
b/arch/arm/mach-omap1/board-palmtt.c
index 54a547a96950..d672495f7441 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -34,7 +34,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmz71.c
b/arch/arm/mach-omap1/board-palmz71.c
index 87ec04ae40dd..aaf741b0aff6 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -36,7 +36,7 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-perseus2.c
b/arch/arm/mach-omap1/board-perseus2.c
index 3d76f05407f0..150b57ba42bf 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -30,7 +30,7 @@
#include
#include
-#include
+#include "flash.h"
#include
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 4fcf19c78a08..a9373570bbb1 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -16,7 +16,7 @@
#include
#include
-#include
+#include "board-sx1.h"
#include "mmc.h"
diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch/arm/mach-omap1/board-sx1.c
index 939991ea33d5..6c482254b37c 100644
--- a/arch/arm/mach-omap1/board-sx1.c
+++ b/arch/arm/mach-omap1/board-sx1.c
@@ -34,11 +34,11 @@
#include
#include
-#include
+#include "flash.h"
#include
#include
#include
-#include
+#include "board-sx1.h"
#include
#include
diff --git a/arch/arm/mach-omap1/include/mach/board-sx1.h
b/arch/arm/mach-omap1/board-sx1.h
similarity index 100%
rename from arch/arm/mach-omap1/include/mach/board-sx1.h
rename to arch/arm/mach-omap1/board-sx1.h
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index e960687d0cb1..2c01147a27f9 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -32,8 +32,8 @@
#includ
Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2
On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
> Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
> to making omap1 support multiarch. After this series we still need to
> make omap1 use the common clock framework and fix up the drivers to not
> rely on includes from mach and plat directories.
>
> Note that this branch depends on a GPIO driver fix in v4.1-rc3
> d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts").
>
I'm getting lots of build errors in linux-next, which I think are
caused by this series.
Here is my fixup. Unfortunately, this again gets us a little further
from making the drivers standalone, or at least it documents the
dependencies.
Arnd
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 9525ef9bc6c0..ac9bd88c6b05 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -42,6 +42,7 @@
#include
#include
+#include
#include
#include "mmc.h"
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 6e6ec93dcbb3..404f3f55726f 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#define OMAP1610_GPIO1_BASE0xfffbe400
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 4612d2506a2d..1bb38a4aec8f 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#define OMAP7XX_GPIO1_BASE 0xfffbc000
diff --git a/arch/arm/mach-omap1/iomap.h b/arch/arm/mach-omap1/iomap.h
index f4e2d7a21365..23686204df45 100644
--- a/arch/arm/mach-omap1/iomap.h
+++ b/arch/arm/mach-omap1/iomap.h
@@ -27,6 +27,7 @@
* Omap1 specific IO mapping
*
*/
+#include
#define OMAP1_IO_PHYS 0xFFFB
#define OMAP1_IO_SIZE 0x4
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index d1ac08016f0b..652ba6b9385e 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -22,6 +22,7 @@
#include
+#include
#include
#include "pm.h"
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db50d5e8..1f28b5e8d6ca 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -26,6 +26,7 @@
#include
+#include
#include
#include
diff --git a/drivers/input/keyboard/omap-keypad.c
b/drivers/input/keyboard/omap-keypad.c
index 7502e46165fa..32c8fc0fdc15 100644
--- a/drivers/input/keyboard/omap-keypad.c
+++ b/drivers/input/keyboard/omap-keypad.c
@@ -38,6 +38,10 @@
#include
#include
+#ifdef CONFIG_ARCH_OMAP1
+#include
+#endif
+
#undef NEW_BOARD_LEARNING_MODE
static void omap_kp_tasklet(unsigned long);
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index c43f74c53cd9..c73297bd7ed4 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -15,6 +15,10 @@
#include
#include
+#ifdef CONFIG_ARCH_OMAP1
+#include
+#endif
+
struct uart_8250_dma {
int (*tx_dma)(struct uart_8250_port *p);
int (*rx_dma)(struct uart_8250_port *p, unsigned int iir);
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 3af263cc0caa..1c05541bbeee 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include
#include
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c
index 6efa2591eaa8..4e01fbbeb52f 100644
--- a/drivers/video/fbdev/omap/lcdc.c
+++ b/drivers/video/fbdev/omap/lcdc.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
diff --git a/drivers/video/fbdev/omap/sossi.c b/drivers/video/fbdev/omap/sossi.c
index d4e7684e7045..39d9d7050d78 100644
--- a/drivers/video/fbdev/omap/sossi.c
+++ b/drivers/video/fbdev/omap/sossi.c
@@ -27,6 +27,8 @@
#include
+#include
+
#include "omapfb.h"
#include "lcdc.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 01/10] ARM: OMAP2+: Return correct error values from device and hwmod
On Thursday 26 February 2015 14:49:51 Pali Rohár wrote:
> Without this patch function pm_runtime_get_sync() returns 0 even when some
> omap subfunction fails. This patch properly propagate error codes from omap
> functions back to caller.
>
> This patch fix problem, when loading omap-aes driver in qemu cause kernel
> oops.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-omap2/omap_device.c | 30 +-
> arch/arm/mach-omap2/omap_hwmod.c | 10 ++
> 2 files changed, 23 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
> index be9541e..9fd47a9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -224,13 +224,13 @@ static int _omap_device_notifier_call(struct
> notifier_block *nb,
> */
> static int _omap_device_enable_hwmods(struct omap_device *od)
> {
> + int ret = 0;
> int i;
>
> for (i = 0; i < od->hwmods_cnt; i++)
> - omap_hwmod_enable(od->hwmods[i]);
> + ret |= omap_hwmod_enable(od->hwmods[i]);
>
> - /* XXX pass along return value here? */
> - return 0;
> + return ret;
> }
>
> /**
> @@ -241,13 +241,13 @@ static int _omap_device_enable_hwmods(struct
> omap_device *od)
> */
> static int _omap_device_idle_hwmods(struct omap_device *od)
> {
> + int ret = 0;
> int i;
>
> for (i = 0; i < od->hwmods_cnt; i++)
> - omap_hwmod_idle(od->hwmods[i]);
> + ret |= omap_hwmod_idle(od->hwmods[i]);
>
> - /* XXX pass along return value here? */
> - return 0;
> + return ret;
> }
>
> /* Public functions for use by core code */
> @@ -595,18 +595,20 @@ static int _od_runtime_suspend(struct device *dev)
> int ret;
>
> ret = pm_generic_runtime_suspend(dev);
> + if (ret)
> + return ret;
>
> - if (!ret)
> - omap_device_idle(pdev);
> -
> - return ret;
> + return omap_device_idle(pdev);
> }
>
> static int _od_runtime_resume(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> + int ret;
>
> - omap_device_enable(pdev);
> + ret = omap_device_enable(pdev);
> + if (ret)
> + return ret;
>
> return pm_generic_runtime_resume(dev);
> }
> @@ -740,7 +742,8 @@ int omap_device_enable(struct platform_device *pdev)
>
> ret = _omap_device_enable_hwmods(od);
>
> - od->_state = OMAP_DEVICE_STATE_ENABLED;
> + if (ret == 0)
> + od->_state = OMAP_DEVICE_STATE_ENABLED;
>
> return ret;
> }
> @@ -770,7 +773,8 @@ int omap_device_idle(struct platform_device *pdev)
>
> ret = _omap_device_idle_hwmods(od);
>
> - od->_state = OMAP_DEVICE_STATE_IDLE;
> + if (ret == 0)
> + od->_state = OMAP_DEVICE_STATE_IDLE;
>
> return ret;
> }
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 92afb72..870e984 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3350,16 +3350,17 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
> */
> int omap_hwmod_idle(struct omap_hwmod *oh)
> {
> + int r;
> unsigned long flags;
>
> if (!oh)
> return -EINVAL;
>
> spin_lock_irqsave(&oh->_lock, flags);
> - _idle(oh);
> + r = _idle(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> - return 0;
> + return r;
> }
>
> /**
> @@ -3372,16 +3373,17 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
> */
> int omap_hwmod_shutdown(struct omap_hwmod *oh)
> {
> + int r;
> unsigned long flags;
>
> if (!oh)
> return -EINVAL;
>
> spin_lock_irqsave(&oh->_lock, flags);
> - _shutdown(oh);
> + r = _shutdown(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> - return 0;
> + return r;
> }
>
> /*
Hello Paul, can you apply this patch?
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs
On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote: > My guess is that the set_cs needs to be called even when toggling as GPIO. > How should I handle this? It shouldn't be part of a set_cs() operation but rather part of the main transfer operation. signature.asc Description: Digital signature
Re: [PATCHv2 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On 05/21/2015 01:38 AM, Tero Kristo wrote: > On 05/21/2015 01:40 AM, Paul Walmsley wrote: >> On Tue, 19 May 2015, Tero Kristo wrote: >> >>> Any news on this? As noted previously, I am not able to reproduce the >>> issue >>> you are seeing currently, can you give DEBUG_LL a shot? >> >> Yeah I just bisected it, it was caused by this: >> >> commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e >> Author: Felipe Balbi >> Date: Fri Jan 30 11:18:56 2015 -0600 >> >> arm: config: omap2plus_defconfig: switch over to LZMA compression >> >> LZMA compression makes about 33% smaller zImage >> with just a slight extra decompression time. >> >> Before this patch, zImage built with o2+_dc >> is 4.5MiB and after it's about 3.3MiB. >> >> Suggested-by: David Cohen >> Signed-off-by: Felipe Balbi >> Signed-off-by: Tony Lindgren >> >> >> and the timeouts on the testbed being set to fail if a kernel takes >> longer >> than five seconds to start. Seems that the part about a "slight extra >> decompression time" probably only applies to relatively recent chips. >> >> >> - Paul >> > > Oh, so this explains why I was thinking it took very long time to boot > the recent kernels also. The boot lag is clearly noticeable without any > measurement. I wonder if we should probably revert this patch. we already have issues with zImage size bloating up and running headlong into dtb - esp on platforms like N900. Felipe spend quiet some time getting things into a manageable size here -> loosing 33% sounds like bad idea to me :( -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
