Re: [BISECTED] v4.3-rc5: OMAP1 boot hang
On 13/11/15 00:57, Russell King - ARM Linux wrote: > On Wed, Nov 11, 2015 at 11:44:44PM +0200, Aaro Koskinen wrote: >> Hi, >> >> Any suggestions how to debug this further? This happens also with v4.3 >> final. Is the CPU_SW_DOMAIN_PAN supposed to work with this CPU? >> >> I tried to disable various drivers (e.g. NAND, USB) and it still >> hangs... And it seems always at the same printk time stamp (roughly at >> 25 seconds). > > No idea what so ever, and I have zero knowledge of this ARM925 thing - > never had one, and never seen any specs on it. The weird thing is > that it's not producing any oops dump - I guess the kernel is totally > dead and unresponsive. I'd ask if you have a heartbeat LED, but I'd > guess the answer will be that the hardware is too limited. Both the 1510 and 5910 had the ARM925T CPU. Probably the best source of info is the 5910 documentation [0], specifically the MPU subsystem document [1]. Hope this helps. Jon [0] http://www.ti.com/product/OMAP5910/technicaldocuments [1] http://www.ti.com/lit/pdf/spru671 -- 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 0/5] arm: dts: complete dm816x device tree
On 11/12/2015 06:47 PM, Tony Lindgren wrote: > * Neil Armstrong [151112 06:08]: >> In order to fix support for the dm816x platform, add missing bits in >> the dm816x dtsi and cleanup OCP. > > Which ones are needed as fixes for the v4.4-rc kernel? > > Regards, > > Tony > >> The last patch adds support for the omap4-hwspinlock. >> >> v2: add ocp hwmod cleanup >> >> Neil Armstrong (5): >> arm: dts: add dm816x missing #mbox-cells >> arm: dts: add dm816x missing spi DT dma handles Tony, The two first are fixes for v4.4-rc. >> arm: dts: add dm816x pwm property to timers >> arm: dts: remove dm816x invalid DT l3_main hwmod >> arm: dts: Add omap4-hwspinlock support in dm816x the 3 following can wait. >> >> arch/arm/boot/dts/dm816x.dtsi | 20 +--- >> 1 file changed, 17 insertions(+), 3 deletions(-) >> >> -- >> 1.9.1 Thanks, Neil -- 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/6] ARM: OMAP2+: dts: cm-t335: add initial support
Hi Uri, On 10/27/15 14:14, Uri Mashiach wrote: > From: Ilya Ledvich > > Add basic support for CompuLab cm-t335 module based on AM335X SoC. > > CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM) > The module is built around the Texas Instruments Sitara AM3352/4 > system-on-chip. > > The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board > NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit > Ethernet, CAN bus. > > Current patch adds support: > UART0 and GPIO LED > > Detailed description can be found at the module site: > http://www.compulab.co.il/products/computer-on-modules/cm-t335/ [...] > diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts > b/arch/arm/boot/dts/am335x-cm-t335.dts > new file mode 100644 > index 000..197d5ce > --- /dev/null > +++ b/arch/arm/boot/dts/am335x-cm-t335.dts > @@ -0,0 +1,62 @@ [...] > +&am33xx_pinmux { > + pinctrl-names = "default"; > + pinctrl-0 = <>; > + > + gpio_led_pins: pinmux_gpio_led_pins { > + pinctrl-single,pins = < > + 0x88 (PIN_OUTPUT | MUX_MODE7) /* gpmc_csn3.gpio2_0 */ > + >; > + }; > + > + uart0_pins: pinmux_uart0_pins { > + pinctrl-single,pins = < > + /* uart0_rxd.uart0_rxd */ > + 0x170 (PIN_INPUT_PULLUP | MUX_MODE0) > + /* uart0_txd.uart0_txd */ > + 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) Can we use AM33XX_IOPAD macro here? and may be other patches too? [...] -- Regards, Igor. -- 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] video:omap2:dss: fix timings for VENC to match what omapdrm expects
Otherwise check_timings fails and we get a "has no modes" message from xrandr. This fix makes the venc assume PAL and NTSC timings that match the timings synthetized by copy_timings_drm_to_omap() from omapdrm mode settings so that check_timings() succeeds. Tested on: BeagleBoard XM, GTA04 and OpenPandora Signed-off-by: H. Nikolaus Schaller --- drivers/video/fbdev/omap2/dss/venc.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/venc.c b/drivers/video/fbdev/omap2/dss/venc.c index 99ca268..d05a549 100644 --- a/drivers/video/fbdev/omap2/dss/venc.c +++ b/drivers/video/fbdev/omap2/dss/venc.c @@ -275,6 +275,12 @@ const struct omap_video_timings omap_dss_pal_timings = { .vbp= 41, .interlace = true, + + .hsync_level = OMAPDSS_SIG_ACTIVE_LOW, + .vsync_level = OMAPDSS_SIG_ACTIVE_LOW, + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE, }; EXPORT_SYMBOL(omap_dss_pal_timings); @@ -290,6 +296,12 @@ const struct omap_video_timings omap_dss_ntsc_timings = { .vbp= 31, .interlace = true, + + .hsync_level = OMAPDSS_SIG_ACTIVE_LOW, + .vsync_level = OMAPDSS_SIG_ACTIVE_LOW, + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE, }; EXPORT_SYMBOL(omap_dss_ntsc_timings); -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix omap VENC (PAL/NTSC TV out) operation with omapdrm driver
This patch set fixes some issues with the OMAP VENC when used with the omapdrm driver. Tested on: BeagleBoard XM, GTA04 and OpenPandora H. Nikolaus Schaller (2): video:omap2:dss: fix timings for VENC to match what omapdrm expects video:omapdrm: make omapdrm assume the tv-out cable is always connected drivers/gpu/drm/omapdrm/omap_connector.c | 1 + drivers/video/fbdev/omap2/dss/venc.c | 12 2 files changed, 13 insertions(+) -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
Include VENC in the set of drivers where it is assimed that the cable is always connected. Like DPI, DSI, DBI and SDI do. Otherwise, the VENC will return cable status "unknown" and is not enabled by the X-server. So there is no video output signal. Tested on: BeagleBoard XM, GTA04 and OpenPandora Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/omapdrm/omap_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644 --- a/drivers/gpu/drm/omapdrm/omap_connector.c +++ b/drivers/gpu/drm/omapdrm/omap_connector.c @@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect( else ret = connector_status_disconnected; } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || + dssdev->type == OMAP_DISPLAY_TYPE_VENC || dssdev->type == OMAP_DISPLAY_TYPE_DBI || dssdev->type == OMAP_DISPLAY_TYPE_SDI || dssdev->type == OMAP_DISPLAY_TYPE_DSI) { -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.16.y-ckt 08/94] clk: ti: fix dual-registration of uart4_ick
3.16.7-ckt20 -stable review patch. If anyone has any objections, please let me know. -- From: Ben Dooks commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream. On the OMAP AM3517 platform the uart4_ick gets registered twice, causing any power management to /dev/ttyO3 to fail when trying to wake the device up. This solves the following oops: [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008 [] PC is at serial_omap_pm+0x48/0x15c [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file") Cc: mturque...@baylibre.com Cc: sb...@codeaurora.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-ker...@lists.codethink.co.uk Signed-off-by: Ben Dooks Signed-off-by: Tero Kristo Signed-off-by: Luis Henriques --- drivers/clk/ti/clk-3xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c index 0d1750a8aea4..088930c3ee4b 100644 --- a/drivers/clk/ti/clk-3xxx.c +++ b/drivers/clk/ti/clk-3xxx.c @@ -170,7 +170,6 @@ static struct ti_dt_clk omap3xxx_clks[] = { DT_CLK(NULL, "gpio2_ick", "gpio2_ick"), DT_CLK(NULL, "wdt3_ick", "wdt3_ick"), DT_CLK(NULL, "uart3_ick", "uart3_ick"), - DT_CLK(NULL, "uart4_ick", "uart4_ick"), DT_CLK(NULL, "gpt9_ick", "gpt9_ick"), DT_CLK(NULL, "gpt8_ick", "gpt8_ick"), DT_CLK(NULL, "gpt7_ick", "gpt7_ick"), @@ -313,6 +312,7 @@ static struct ti_dt_clk am35xx_clks[] = { static struct ti_dt_clk omap36xx_clks[] = { DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"), DT_CLK(NULL, "uart4_fck", "uart4_fck"), + DT_CLK(NULL, "uart4_ick", "uart4_ick"), { .node_name = NULL }, }; -- 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: Minimal support for dm814x
On 13 November 2015 at 08:14, Matthijs van Duin wrote: > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL Never mind, wasn't paying attention and managed to overlook that google had found me the u-boot tree instead of the kernel tree I intended to search for. -.- Sorry about that, when I find a moment I'll locate the correct files and check those. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
On 13/11/15 12:29, H. Nikolaus Schaller wrote: > Include VENC in the set of drivers where it is assimed that the cable > is always connected. Like DPI, DSI, DBI and SDI do. > > Otherwise, the VENC will return cable status "unknown" and is not enabled > by the X-server. So there is no video output signal. > > Tested on: BeagleBoard XM, GTA04 and OpenPandora > > Signed-off-by: H. Nikolaus Schaller > --- > drivers/gpu/drm/omapdrm/omap_connector.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c > b/drivers/gpu/drm/omapdrm/omap_connector.c > index 83f2a91..98ddb5d 100644 > --- a/drivers/gpu/drm/omapdrm/omap_connector.c > +++ b/drivers/gpu/drm/omapdrm/omap_connector.c > @@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect( > else > ret = connector_status_disconnected; > } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || > + dssdev->type == OMAP_DISPLAY_TYPE_VENC || > dssdev->type == OMAP_DISPLAY_TYPE_DBI || > dssdev->type == OMAP_DISPLAY_TYPE_SDI || > dssdev->type == OMAP_DISPLAY_TYPE_DSI) { > I have no idea why VENC is not working for you when using connector_status_unknown, but I just tested DPI with connector_status_unknown (i.e. changed the above func to return unknown for DPI), and it works fine with X and X omap driver. And xrandr confirms that the connection status is unknown: # xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048 HDMI-1 disconnected (normal left inverted right x axis y axis) None-1 unknown connection 1920x1200+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1920x1200 60.00*+ 60.00 + Grep also shows that there are many drivers using connector_status_unknown, so I'm guessing it should work fine... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: > On 13/11/15 12:29, H. Nikolaus Schaller wrote: > > Include VENC in the set of drivers where it is assimed that the cable > > is always connected. Like DPI, DSI, DBI and SDI do. > > > > Otherwise, the VENC will return cable status "unknown" and is not enabled > > by the X-server. So there is no video output signal. > > > > Tested on: BeagleBoard XM, GTA04 and OpenPandora > > > > Signed-off-by: H. Nikolaus Schaller > > --- > > > > drivers/gpu/drm/omapdrm/omap_connector.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c > > b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644 > > --- a/drivers/gpu/drm/omapdrm/omap_connector.c > > +++ b/drivers/gpu/drm/omapdrm/omap_connector.c > > @@ -120,6 +120,7 @@ static enum drm_connector_status > > omap_connector_detect( > > else > > ret = connector_status_disconnected; > > } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || > > + dssdev->type == OMAP_DISPLAY_TYPE_VENC || > > dssdev->type == OMAP_DISPLAY_TYPE_DBI || > > dssdev->type == OMAP_DISPLAY_TYPE_SDI || > > dssdev->type == OMAP_DISPLAY_TYPE_DSI) { > > I have no idea why VENC is not working for you when using > connector_status_unknown, but I just tested DPI with > connector_status_unknown (i.e. changed the above func to return unknown > for DPI), and it works fine with X and X omap driver. And xrandr > confirms that the connection status is unknown: > > # xrandr > Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048 > HDMI-1 disconnected (normal left inverted right x axis y axis) > None-1 unknown connection 1920x1200+0+0 (normal left inverted right x > axis y axis) 0mm x 0mm >1920x1200 60.00*+ 60.00 + > > Grep also shows that there are many drivers using > connector_status_unknown, so I'm guessing it should work fine... And beside it's not right to consider VENC as always connected, as it isn't. The unknown status is there for a reason, to describe connectors for which we can't get any status information. The situation is different for DPI, DBI, SDI and DSI as those are on-board busses that connect to a non-removable panel, so we can say with a good confidence that the panel is connected (the situation could be changed with a hammer and a chisel, but that's unlikely to happen, hence the confidence). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices
On 11/12/2015 08:06 PM, Felipe Balbi wrote: > Make sure to tell the kernel that AM437x has > TWD and global timers. > > Signed-off-by: Felipe Balbi > --- > > Hi Tony, > > now that all dependencies are in place, we can > finally enable twd and global_timer for AM437x. > I'd appreciated if someone can clarify if all described below is valid. (may be some questions are dummy - sorry). After all last changes related to TI OMAP clock source/clock event/sched clock's devices configuration we will have the following for am437x case: clockevents: "timer1", clockevent_gpt, .rating = 300, CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT, ti,timer-alwon, "arm,twd-timer", twd_evt,.rating = 350, CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP "arm_global_timer", gt_evt, rating = 300, CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU clocksources: "jiffies", clocksource_jiffies, rating = 1 if use_gptimer_clksrc "timer2", clocksource_gpt, .rating = 300, CLOCK_SOURCE_IS_CONTINUOUS, |-sched_clock_register(dmtimer_read_sched_clock, 32, clksrc.rate); else "ti,omap-counter32k", ti_32k_timer, .rating = 250, CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP, |-sched_clock_register(omap_32k_read_sched_clock, 32, 32768); "arm,global-timer", gt_clocksource, .rating = 300, CLOCK_SOURCE_IS_CONTINUOUS |-sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate); 1) current clockevent device will be registered during registration of clockevent devices and it will be "arm,twd-timer" - processing sequence follows the way they are listed above. 2) current clocksource will be selected from fs_initcall(clocksource_done_booting); and it will be "arm,global-timer" or "timer2" if use_gptimer_clksrc 3) sched clock: "arm,global-timer" will be selected as sched_clock *always*, because it depend on Makefile order (if someone will decide to sort entries in drivers/clocksource/Makefile then "ti,omap-counter32k" most probably will be always selected as sched clock). Uh.. As for me, "timer1" is selected as clockevent device incorrectly, because it's ti,timer-alwon. I think, "ti,omap-counter32k" will crash if use_gptimer_clksrc == true, because corresponding HWmod will not be enabled (not tested this case). Not sure if "timer2" is selected correctly when both "arm,global-timer" and GP timer registered as clocksources. ? Also, It looks like the way sched clock is selected is a little bit unsafe/unclear (especially taking into account that clocksource dev can be changed through the sysfs and TI multiSoC kernel). What is the policy/right way to configure all this clocks? - should only one clock source be selected for each of them in config file? - how to dial with sched clock if it depends only on Makefile order ? :( - should we convert all of them to modules and load depending on current hw? Could it be reasonable to configure sched clock together with clocksource dev registration/selection? - add read_sched field struct clocksource { u64 (*read_sched_clock)(void); - configure sched clock from clocksource core if read_sched != null Thanks. > arch/arm/mach-omap2/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 5076d3f334d2..bb3daf0fa7f7 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -65,6 +65,9 @@ config SOC_AM43XX > select MACH_OMAP_GENERIC > select MIGHT_HAVE_CACHE_L2X0 > select HAVE_ARM_SCU > + select HAVE_ARM_TWD > + select ARM_GLOBAL_TIMER > + select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK > > config SOC_DRA7XX > bool "TI DRA7XX" > -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am35xx memory management issues
Hi, On 12.11.2015 19:06, Tony Lindgren wrote: > Hi, > > * Markku Ahvenjärvi [151112 07:26]: >> Hello everyone, >> >> We have am3517 based board and are experiencing sporadic corruption of mm >> structures. We've had this problem for months now and haven't really got >> bottom of it. >> >> Our board is currently using 3.18.20, but with am3517-evm we've tried pretty >> much everything between v3.14 and v4.2. So far we've been able to reproduce >> it on am3517-evm, craneboard and beagleboard (rev. C3 and C4). We have also >> tested am/dm37x-evm, am335x-evm and beagle bone black, no problems seen. >> >> Usually kernel it panics in 'kernel BUG at mm/rmap.c:406!', but occasionally >> there's 'BUG: Bad rss-counter state' prints followed by NULL pointer deref >> or another BUG statement in mm/slab.c. Sometimes spinlock lockup or already >> unlocked reported, so it is quite random. >> >> Reproducing can take from half hour up to few days. We are using stress-ng >> with options: >> stress-ng --cpu 1 --vm 3 --vm-bytes 64M --fork 4 >> >> In our tests we have noticed that kernel configuration affect frequency of >> the problem. So far we haven't seen any with omap2plus_defconfig, but with >> slimmer defconfig like the one we are using for our board we can get it in >> few hours. We bisected our defconfig and omap2plus_defconfig, but couldn't >> pinpoint any specific config that would cause these problems: it just got >> less frequent until stopped occurring. To rule out any bad behaving drivers, >> we basically disabled everything but serial and it just kept crashing. > > Adding also LAKML to Cc. Can you check if it starts happening if you > leave out other omaps from .config other than CONFIG_ARCH_OMAP3? > That's to compile code only for ARMv7 and leave out ARMv6. > > Also please check if leaving out CONFIG_SMP_ON_UP affects things. Alright, will do. >> Someone was having quite similar problems back in 2012, but other than that >> we've found nothing: >> http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/ >> >> Anyone seen this kind of issues before? Any ideas what might cause this? > > If it starts happening after after leaving out ARMv6 or SMP_ON_UP, > it could be a cache bug or missing errata that's needed. Right. Regards, Markku > > Regards, > > Tony > > >> [0.00] Booting Linux on physical CPU 0x0 >> [0.00] Linux version 3.18.24 (markku@thinkpad) (gcc version 4.9.3 >> 20141031 (prerelease) (Linaro GCC 2014.11) ) #2 PREEMPT Wed Nov 4 09:51:36 >> EET 2015 >> [0.00] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), >> cr=10c5387d >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing >> instruction cache >> [0.00] Machine model: TI AM3517 EVM (AM3517/05 TMDSEVM3517) >> [0.00] cma: Reserved 8 MiB at 0x8f40 >> [0.00] Memory policy: Data cache writeback >> [0.00] On node 0 totalpages: 65280 >> [0.00] free_area_init_node: node 0, pgdat c09be980, node_mem_map >> cfce7000 >> [0.00] Normal zone: 512 pages used for memmap >> [0.00] Normal zone: 0 pages reserved >> [0.00] Normal zone: 65280 pages, LIFO batch:15 >> [0.00] HighMem zone: 1048574 pages exceeds freesize 0 >> [0.00] CPU: All CPU(s) started in SVC mode. >> [0.00] AM3517 ES1.1 (l2cache sgx neon ) >> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >> [0.00] pcpu-alloc: [0] 0 >> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 64768 >> [0.00] Kernel command line: console=ttyO2,115200 >> [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) >> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 >> bytes) >> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) >> [0.00] Memory: 239940K/261120K available (4809K kernel code, 341K >> rwdata, 1816K rodata, 2996K init, 353K bss, 21180K reserved, 0K highmem) >> [0.00] Virtual kernel memory layout: >> [0.00] vector : 0x - 0x1000 ( 4 kB) >> [0.00] fixmap : 0xffc0 - 0xffe0 (2048 kB) >> [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) >> [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) >> [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) >> [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) >> [0.00] .text : 0xc0008000 - 0xc0680984 (6627 kB) >> [0.00] .init : 0xc0681000 - 0xc096e000 (2996 kB) >> [0.00] .data : 0xc096e000 - 0xc09c354c ( 342 kB) >> [0.00].bss : 0xc09c354c - 0xc0a1b97c ( 354 kB) >> [0.00] Preemptible hierarchical RCU implementation. >> [0.00] NR_IRQS:16 nr_irqs:16 16 >> [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 >> interrupts >> [0.00] Clocking rate (Crystal/Core
Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices
On 13/11/2015 13:48, Grygorii Strashko wrote: > On 11/12/2015 08:06 PM, Felipe Balbi wrote: >> Make sure to tell the kernel that AM437x has >> TWD and global timers. >> >> Signed-off-by: Felipe Balbi >> --- >> >> Hi Tony, >> >> now that all dependencies are in place, we can >> finally enable twd and global_timer for AM437x. >> > > I'd appreciated if someone can clarify if all described below is valid. > (may be some questions are dummy - sorry). > > After all last changes related to TI OMAP clock source/clock event/sched > clock's > devices configuration we will have the following for am437x case: > > clockevents: > "timer1",clockevent_gpt, .rating = 300, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT, ti,timer-alwon, > "arm,twd-timer", twd_evt,.rating = 350, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP > "arm_global_timer", gt_evt, rating = 300, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU NB: AFAIU/IIUC the global timer ticks at cpuclk/N but the driver does not deal with frequency updates (unlike smp_twd.c) I'm not sure global timer can be used reliably together with cpufreq. > clocksources: > "jiffies", clocksource_jiffies, rating = 1 > if use_gptimer_clksrc > "timer2", clocksource_gpt, .rating = 300, CLOCK_SOURCE_IS_CONTINUOUS, > |-sched_clock_register(dmtimer_read_sched_clock, 32, clksrc.rate); > else > "ti,omap-counter32k", ti_32k_timer, .rating = 250, > CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP, > |-sched_clock_register(omap_32k_read_sched_clock, 32, 32768); > > "arm,global-timer", gt_clocksource, .rating = 300, CLOCK_SOURCE_IS_CONTINUOUS If using cpufreq, I don't think the global timer can be used as a clock source. Again AFAIU and IIUC and I may be wrong. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
Hi Laurent and Tomi, Am 13.11.2015 um 13:01 schrieb Laurent Pinchart : > On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: >> On 13/11/15 12:29, H. Nikolaus Schaller wrote: >>> Include VENC in the set of drivers where it is assimed that the cable >>> is always connected. Like DPI, DSI, DBI and SDI do. >>> >>> Otherwise, the VENC will return cable status "unknown" and is not enabled >>> by the X-server. So there is no video output signal. >>> >>> Tested on: BeagleBoard XM, GTA04 and OpenPandora >>> >>> Signed-off-by: H. Nikolaus Schaller >>> --- >>> >>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c >>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644 >>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c >>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c >>> @@ -120,6 +120,7 @@ static enum drm_connector_status >>> omap_connector_detect( >>> else >>> ret = connector_status_disconnected; >>> } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || >>> + dssdev->type == OMAP_DISPLAY_TYPE_VENC || >>> dssdev->type == OMAP_DISPLAY_TYPE_DBI || >>> dssdev->type == OMAP_DISPLAY_TYPE_SDI || >>> dssdev->type == OMAP_DISPLAY_TYPE_DSI) { >> >> I have no idea why VENC is not working for you when using >> connector_status_unknown, I agree that it should... >> but I just tested DPI with >> connector_status_unknown (i.e. changed the above func to return unknown >> for DPI Good hint. I can do the same check. Maybe it highlights the real issue. >> ), and it works fine with X and X omap driver. And xrandr >> confirms that the connection status is unknown: >> >> # xrandr >> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048 >> HDMI-1 disconnected (normal left inverted right x axis y axis) >> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x >> axis y axis) 0mm x 0mm >> 1920x1200 60.00*+ 60.00 + Which configs, drivers and system are you using for this results? >> >> Grep also shows that there are many drivers using >> connector_status_unknown, so I'm guessing it should work fine... > > And beside it's not right to consider VENC as always connected, as it isn't. Hm. Well, the VENC (meaning the D/A converter inside the OMAP3 chip) is always connected. But the monitor or cable isn't. > The unknown status is there for a reason, to describe connectors for which we > can't get any status information. The situation is different for DPI, DBI, > SDI > and DSI as those are on-board busses that connect to a non-removable panel, > so > we can say with a good confidence that the panel is connected (the situation > could be changed with a hammer and a chisel, but that's unlikely to happen, > hence the confidence). Well, it may be that the omapdrm and X11 combination (unfortuantely I don't understand either and have not found a good description how they interwork), keeps the VENC disabled if the connector is unknown. And since there is no code to detect that a cable has been connected, there might be missing some trigger to enable the interface. The symptom I see is that the status of this card is "disabled" while the LCD panel is "enabled". After doing my proposed patch, both come up "enabled". So my patch appears to be a work around some other still hidden problem. Any hint from the experts how to debug / find the real issue & solution is welcome. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
On 11-11-15 07:50, R, Vignesh wrote: Hi Brain, On 11/11/2015 4:53 AM, Brian Norris wrote: Hi Vignesh, ... Also, this API doesn't actually have anything to do with memory mapping. It has to do with the de facto standard flash protocol. So I don't think mmap belongs in the name; it should be something about flash. (I know of at least one other controller that could probably use this API, excpet it doesn't use memory mapping to accomplish the accelerated flash read.) The Zynq has a similar way of accessing QSPI flash through a memory map. The memory window is only 16MB, so some form of paging would be needed. It's why I have been following this thread with great interest, since the QSPI performance on the Zynq is way below what it could potentially be. As far as TI QSPI controller is concerned, the accelerated read happens via mmap port whereby a predefined memory address space of SoC is exposed as QSPI mmap region. This region can be accessed like normal RAM(via memcpy()) and the QSPI controller interface takes care of fetching data from flash on SPI bus automatically hence, I named it as above. But, I have no hard feelings if it needs to be generalized to spi_mtd_read() or something else. I know that on the Zynq, you can even let the DMA controller access the QSPI flash via this memory mapping. The QSPI controller itself doesn't support any DMA at all. If something similar applies to the TI platform (most of the TI procs have nice DMA controllers) one could go one step further and implement a generic DMA-through-mmap access to QSPI flash. Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand number C65 http://www.aesexpo.eu -- 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/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
* Neil Armstrong [151112 06:16]: > On 10/24/2015 12:09 PM, Neil Armstrong wrote: > > Hi, > > > > 2015-10-24 3:21 GMT+02:00 Tony Lindgren : > >> > >> Hi, > >> > >> * Neil Armstrong [151022 02:19]: > >>> Add missing HWMOD_NO_IDLEST hwmod flag for entries no > >>> having omap4 clkctrl values. > >> > >> Have you checked this is the case both in dm814x and dm816x TRM? > >> Also the documentation may not be complete FYI, might be also > >> worth checking the legacy TI kernel tree to be sure. > >> > >> Regards, > >> > >> Tony > >> > >>> Cc: Brian Hutchinson > >>> Signed-off-by: Neil Armstrong > >>> --- > >>> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++ > >>> 1 file changed, 3 insertions(+) > >>> > >>> diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > >>> b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > >>> index b1288f5..6256052 100644 > >>> --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > >>> +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > >>> @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = { > >>> .name = "l4_ls", > >>> .clkdm_name = "alwon_l3s_clkdm", > >>> .class = &l4_hwmod_class, > >>> + .flags = HWMOD_NO_IDLEST, > >>> }; > > In DM814x TRM, the CM_ALWON_L3_SLOW_CLKSTCTRL does not have IDLEST field. > > Same in DM816x TRM. > > > >>> > >>> /* > >>> @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = { > >>> .name = "l4_hs", > >>> .clkdm_name = "alwon_l3_med_clkdm", > >>> .class = &l4_hwmod_class, > >>> + .flags = HWMOD_NO_IDLEST, > >>> }; > > In DM814x TRM, the CM_ALWON_L3_MED_CLKSTCTRL does not have IDLEST field. > > Same in DM816x TRM. > > > >>> > >>> /* L3 slow -> L4 ls peripheral interface running at 125MHz */ > >>> @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = { > >>> .name = "emac0", > >>> .clkdm_name = "alwon_ethernet_clkdm", > >>> .class = &dm816x_emac_hwmod_class, > >>> + .flags = HWMOD_NO_IDLEST, > >>> }; > > In this particular case, the IDLEST is handled in the MDIO hwmod. > > > >>> > >>> static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = { > >>> -- > >>> 1.9.1 > > > > I'll check the TI tree to be sure... > > > > Regards, > > Neil > > > Tony, > > In TI's tree, there is no L3_MED hwmod but the L3_SLOW hwmod has NO_IDLEST > flag. > > Is there any other issue about this patchset ? Thanks for checking. Well one thing, if this is needed as fix, then a description of what happens without it would be good to have. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/39] ARM: dts: Convert OMAP boards to use IOPAD pinmux macros
* Javier Martinez Canillas [151112 20:55]: > Hello Tony, > > This series converts all the remaining OMAP boards that didn't use the > IOPAD macros to specify the padconf register addresses. The only board > that I left was arch/arm/boot/dts/am335x-boneblack.dts because Andrew > already posted a patch for that DTS [0]. > > I built tested all the DTBs that are build by omap2plus_defconfig and > the md5 checksum was the same before and after the patches so there's > no functional change and is only to make the DTS more readable. Yes great. Being able to compare the register against the documentation helps quite a bit. I plan on applying this series before anything else after -rc1 as it may require other patches to be rebased. > Patch #1 should be acked by the pinctrl maintainer and picked through > the linux-omap tree to maintain bisectability. > > [0]: https://lkml.org/lkml/2015/10/24/114 OK let's wait for Linus to take a look at it. Tony > Javier Martinez Canillas (39): > pinctrl: Move am4372 and dra7 macros to the the SoC header files > ARM: dts: am335x-baltos-ir5221: Remove leftover pinctrl lines > ARM: dts: am335x-baltos-ir5221: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-bone-common: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-bonegreen: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-chiliboard: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-chilisom: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-evm: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-evmsk: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-lxm: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-nano: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-pepper: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-phycore-som: Use AM33XX_IOPAD pinmux macro > ARM: dts: am335x-wega: Use AM33XX_IOPAD pinmux macro > ARM: dts: am3517-craneboard: Use OMAP3_CORE1_IOPAD pinmux macro > ARM: dts: am437x-gp-evm: Use AM4372_IOPAD pinmux macro > ARM: dts: am437x-idk-evm: Use AM4372_IOPAD pinmux macro > ARM: dts: am437x-sk-evm: Use AM4372_IOPAD pinmux macro > ARM: dts: am43x-epos-evm: Use AM4372_IOPAD pinmux macro > ARM: dts: am57xx-beagle-x15: Use DRA7XX_CORE_IOPAD pinmux macro > ARM: dts: dra7-evm: Use DRA7XX_CORE_IOPAD pinmux macro > ARM: dts: dra72-evm: Use DRA7XX_CORE_IOPAD pinmux macro > ARM: dts: omap3-beagle: Use OMAP3_*_IOPAD pinmux macros > ARM: dts: omap3-beagle-xm: Use OMAP3_*_IOPAD pinmux macros > ARM: dts: omap3-evm-37xx: Use OMAP3_*_IOPAD pinmux macros > ARM: dts: omap3-ldp: Use OMAP3_CORE1_IOPAD pinmux macro > ARM: dts: omap3-n900: Use OMAP3_CORE1_IOPAD pinmux macro > ARM: dts: omap3-n9: Use OMAP3_CORE1_IOPAD pinmux macro > ARM: dts: omap3-zoom3: Use OMAP3_*_IOPAD pinmux macros > ARM: dts: twl4030: Use OMAP3_CORE1_IOPAD pinmux macro > ARM: dts: omap4-panda-a4: Use OMAP4_IOPAD pinmux macro > ARM: dts: omap4-panda-common: Use OMAP4_IOPAD pinmux macro > ARM: dts: omap4-panda-es: Use OMAP4_IOPAD pinmux macro > ARM: dts: omap4-sdp: Use OMAP4_IOPAD pinmux macro > ARM: dts: omap4-sdp-es23plus: Use OMAP4_IOPAD pinmux macro > ARM: dts: twl6030: Use OMAP4_IOPAD pinmux macro > ARM: dts: omap5-board-common: Use OMAP5_IOPAD pinmux macro > ARM: dts: omap5-cm-t54: Use OMAP5_IOPAD pinmux macro > ARM: dts: omap5-uevm.dts: Use OMAP5_IOPAD pinmux macro > > arch/arm/boot/dts/am335x-baltos-ir5221.dts | 186 +++--- > arch/arm/boot/dts/am335x-bone-common.dtsi | 104 > arch/arm/boot/dts/am335x-bonegreen.dts | 4 +- > arch/arm/boot/dts/am335x-chiliboard.dts| 20 +- > arch/arm/boot/dts/am335x-chilisom.dtsi | 80 +++--- > arch/arm/boot/dts/am335x-evm.dts | 220 - > arch/arm/boot/dts/am335x-evmsk.dts | 278 ++--- > arch/arm/boot/dts/am335x-lxm.dts | 120 - > arch/arm/boot/dts/am335x-nano.dts | 140 +-- > arch/arm/boot/dts/am335x-pepper.dts| 200 +++ > arch/arm/boot/dts/am335x-phycore-som.dtsi | 60 ++--- > arch/arm/boot/dts/am335x-wega.dtsi | 58 ++--- > arch/arm/boot/dts/am3517-craneboard.dts| 2 +- > arch/arm/boot/dts/am437x-gp-evm.dts| 380 > ++--- > arch/arm/boot/dts/am437x-idk-evm.dts | 128 +- > arch/arm/boot/dts/am437x-sk-evm.dts| 298 +++--- > arch/arm/boot/dts/am43x-epos-evm.dts | 246 +-- > arch/arm/boot/dts/am57xx-beagle-x15.dts| 198 +++ > arch/arm/boot/dts/dra7-evm.dts | 254 +-- > arch/arm/boot/dts/dra72-evm.dts| 200 +++ > arch/arm/boot/dts/omap3-beagle-xm.dts | 18 +- > arch/arm/boot/dts/omap3-beagle.dts | 64 ++--- > arch/arm/boot/dts/omap3-evm-37xx.dts | 54 ++-- > arch/arm/boot/dts/omap3-ldp.dts| 42 ++-- > arch/arm/boot/dts/omap3-n900.dts | 106 > arch/arm/boot/dts/omap3-n950-n9.dtsi
Re: Minimal support for dm814x
* Matthijs van Duin [151113 03:00]: > On 13 November 2015 at 08:14, Matthijs van Duin > wrote: > > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL > > Never mind, wasn't paying attention and managed to overlook that > google had found me the u-boot tree instead of the kernel tree I > intended to search for. -.- > > Sorry about that, when I find a moment I'll locate the correct files > and check those. I think this is the most recent TI git repo for dm81xx changes: http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary git://arago-project.org/git/projects/linux-omap3.git 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: Minimal support for dm814x
* Tony Lindgren [151113 06:53]: > * Matthijs van Duin [151113 03:00]: > > On 13 November 2015 at 08:14, Matthijs van Duin > > wrote: > > > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL > > > > Never mind, wasn't paying attention and managed to overlook that > > google had found me the u-boot tree instead of the kernel tree I > > intended to search for. -.- > > > > Sorry about that, when I find a moment I'll locate the correct files > > and check those. > > I think this is the most recent TI git repo for dm81xx changes: > > http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary > git://arago-project.org/git/projects/linux-omap3.git Oh and the adpll code is under arch/arm/mach-omap2 in that kernel: http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/adpll_ti814x.c;h=27877268f3598f7a253b578674208ab406c44524;hb=HEAD 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] dmaengine: edma: Add dummy driver skeleton for edma3-tptc
* Vinod Koul [151104 08:38]: > On Wed, Nov 04, 2015 at 10:33:27AM -0600, Felipe Balbi wrote: > > Peter Ujfalusi writes: > > > > > The eDMA3 TPTC does not need any software configuration, but it is a > > > separate IP block in the SoC. In order the omap hwmod core to be able to > > > handle the TPTC resources correctly in regards of PM we need to have a > > > driver loaded for it. > > > This patch will add a dummy driver skeleton without probe or remove > > > callbacks provided. > > > > > > Signed-off-by: Peter Ujfalusi > > > Reported-by: Olof Johansson > > > > This fixes the problem I also reported on linux-omap [1] > > > > Tested-by: Felipe Balbi > > > > [1] http://marc.info/?l=linux-omap&m=144665429032014&w=2 > > Great, I was about to point you to this series, I will push this in -next > now Soungd good to me, thanks for fixing it up Peter. 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 RFC v2 2/2] drm/atomic: Disable planes on blanked CRTC and enable on unblank
Disable planes if they are on to be blanked CRTC and enable them when the CRTC is turned back on by DMPS. This is desirable on HW that loses its context on blanking. When planes are enabled and disabled with the associated CRTCs, there is no need to restore the plane context in runtime_resume callback. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/drm_atomic_helper.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d03e2ac..5cd8016 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2027,8 +2027,8 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip); * * This is the main helper function provided by the atomic helper framework for * implementing the legacy DPMS connector interface. It computes the new desired - * ->active state for the corresponding CRTC (if the connector is enabled) and - * updates it. + * ->active state for the corresponding CRTC and planes on it (if the connector + * is enabled) and updates it. * * Returns: * Returns 0 on success, negative errno numbers on failure. @@ -2041,6 +2041,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector *connector, struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; struct drm_connector *tmp_connector; + struct drm_plane *tmp_plane; int ret; bool active = false; int old_mode = connector->dpms; @@ -2079,6 +2080,20 @@ retry: } crtc_state->active = active; + /* Collect associated plane states to global state object. */ + list_for_each_entry(tmp_plane, &config->plane_list, head) { + struct drm_plane_state *plane_state; + + if (tmp_plane->state->crtc != crtc) + continue; + + plane_state = drm_atomic_get_plane_state(state, tmp_plane); + if (IS_ERR(plane_state)) { + ret = PTR_ERR(plane_state); + goto fail; + } + } + ret = drm_atomic_commit(state); if (ret != 0) goto fail; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank
Since first RFC version: - Added "drm/atomic: Track drm_plane's active state"-patch We would need something like this to get rid off OMAPDSS somewhat messy runtime_resume code. How does this look, could this generic solution be refined to be acceptable for mainline, or should we start looking a local solution to omapdrm? Jyri Sarha (2): drm/atomic: Track drm_plane's active state drm/atomic: Disable planes on blanked CRTC and enable on unblank drivers/gpu/drm/drm_atomic_helper.c | 82 + drivers/gpu/drm/drm_plane_helper.c | 10 + include/drm/drm_atomic_helper.h | 39 +- include/drm/drm_crtc.h | 2 + 4 files changed, 70 insertions(+), 63 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 1/2] drm/atomic: Track drm_plane's active state
Track drm_plane's active state with a new boolean in struct drm_plane_state. The patch replaces drm_atomic_plane_disabling() with drm_atomic_helper_update_plane_state(). In addition to all the same things the drm_atomic_plane_disabling() used to do the new function updates the active-flag and calls atomic_update() or atomic_disable() from the plane's helper funcs as needed. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/drm_atomic_helper.c | 63 - drivers/gpu/drm/drm_plane_helper.c | 10 +- include/drm/drm_atomic_helper.h | 39 ++- include/drm/drm_crtc.h | 2 ++ 4 files changed, 53 insertions(+), 61 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index aecb5d6..d03e2ac 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1197,15 +1197,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev, if (!funcs) continue; - /* -* Special-case disabling the plane if drivers support it. -*/ - if (drm_atomic_plane_disabling(plane, old_plane_state) && - funcs->atomic_disable) - funcs->atomic_disable(plane, old_plane_state); - else if (plane->state->crtc || -drm_atomic_plane_disabling(plane, old_plane_state)) - funcs->atomic_update(plane, old_plane_state); + drm_atomic_helper_update_plane_state(plane, old_plane_state); } for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) { @@ -1266,12 +1258,7 @@ drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state *old_crtc_state) WARN_ON(plane->state->crtc && plane->state->crtc != crtc); - if (drm_atomic_plane_disabling(plane, old_plane_state) && - plane_funcs->atomic_disable) - plane_funcs->atomic_disable(plane, old_plane_state); - else if (plane->state->crtc || -drm_atomic_plane_disabling(plane, old_plane_state)) - plane_funcs->atomic_update(plane, old_plane_state); + drm_atomic_helper_update_plane_state(plane, old_plane_state); } if (crtc_funcs && crtc_funcs->atomic_flush) @@ -1279,6 +1266,52 @@ drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state *old_crtc_state) } EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc); +/* + * drm_atomic_helper_update_plane_state - update plane's atomic state + * @plane: plane object + * @old_state: previous atomic state + * + * Update plane's atomic state, disables it if that is required, and + * updates drm_palnes_state's active-flag. This also WARNs if it + * detects an invalid state (both CRTC and FB need to either both be + * NULL or both be non-NULL). + */ +void drm_atomic_helper_update_plane_state(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + const struct drm_plane_helper_funcs *funcs = plane->helper_private; + + /* +* When disabling a plane, CRTC and FB should always be NULL together. +* Anything else should be considered a bug in the atomic core, so we +* gently warn about it. +*/ + WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) || + (plane->state->crtc != NULL && plane->state->fb == NULL)); + + if (!funcs) + return; + + /* +* The plane needs to be active only if it has an associated CRTC +* and the CRTC is active. Use atomic_disable() if available. +*/ + if (plane->state->active) { + if (!plane->state->crtc || !plane->state->crtc->state->active) { + plane->state->active = false; + if (funcs->atomic_disable) { + funcs->atomic_disable(plane, old_state); + return; + } + } + funcs->atomic_update(plane, old_state); + } else if (plane->state->crtc && plane->state->crtc->state->active) { + plane->state->active = true; + funcs->atomic_update(plane, old_state); + } +} +EXPORT_SYMBOL(drm_atomic_helper_update_plane_state); + /** * drm_atomic_helper_cleanup_planes - cleanup plane resources after commit * @dev: DRM device diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c index 5e5a07a..93052de 100644 --- a/drivers/gpu/drm/drm_plane_helper.c +++ b/drivers/gpu/drm/drm_plane_helper.c @@ -440,15 +440,7 @@ int drm_plane_helper_commit(struct drm_plane *plane, crtc_funcs[i]->atomic_begin(crtc[i], crtc[i]->state); } - /* -* Drivers may optionally implement the ->ato
Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Hi Brian, Le 11/11/2015 08:20, Brian Norris a écrit : > Hi, > > On Wed, Nov 11, 2015 at 12:20:46PM +0530, R, Vignesh wrote: >> On 11/11/2015 4:53 AM, Brian Norris wrote: >>> On Tue, Nov 10, 2015 at 10:59:55AM +0530, Vignesh R wrote: diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index cce80e6dc7d1..2f2c431b8917 100644Hi --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * @handle_err: the subsystem calls the driver to handle an error that occurs *in the generic implementation of transfer_one_message(). * @unprepare_message: undo any work done by prepare_message(). + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory. + * Flash drivers (like m25p80) can request memory + * mapped read via this method. This interface + * should only be used by mtd flashes and cannot be + * used by other spi devices. * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS *number. Any individual value may be -ENOENT for CS lines that *are not GPIOs (driven by the SPI controller itself). @@ -507,6 +512,11 @@ struct spi_master { struct spi_message *message); int (*unprepare_message)(struct spi_master *master, struct spi_message *message); + int (*spi_mtd_mmap_read)(struct spi_device *spi, + loff_t from, size_t len, + size_t *retlen, u_char *buf, + u8 read_opcode, u8 addr_width, + u8 dummy_bytes); >>> >>> Is this API really sufficient? There are actually quite a few other >>> flash-related parameters that might be relevant to a controller. I >>> presume you happen not hit them because of the particular cases you're >>> using this for right now, but: >>> >>> * How many I/O lines are being used? These can vary depending on the >>>type of flash and the number of I/O lines supported by the controller >>>and connected on the board. >>> >> >> This API communicates whatever data is currently communicated via >> spi_message through spi_sync/transfer_one interfaces. > > No it doesn't. A spi_message consists of a list of spi_transfer's, and > each spi_transfer has tx_nbits and rx_nbits fields. > >>> * The previous point can vary across parts of the message. There are >>>various combinations of 1/2/4 lines used for opcode/address/data. We >>>only support a few of those combinations in m25p80 right now, but >>>you're not specifying any of that in this API. I guess you're just >>>making assumptions? (BTW, I think there are others having problems >>>with the difference between different "quad" modes on Micron flash; I >>>haven't sorted through all the discussion there.) >>> >> >> How is the spi controller currently being made aware of this via >> m25p80_read / spi_sync() interface? AFAIK, mode field of spi_device >> struct tell whether to do normal/dual/quad read but there is no info >> communicated wrt 1/2/4 opcode/address/data combinations. > > Yes there is. m25p80 fills out spi_transfer::rx_nbits. Currently, we > only use this for the data portion, but it's possible to support more > lines for the address and opcode portions too, using the rx_nbits for > the opcode and address spi_transfer struct(s) (currently, m25p80_read() > uses 2 spi_transfers per message, where the first one contains opcode + > address + dummy on a single line, and the second transfer receives the > data on 1, 2, or 4 lines). > In September I've sent a series of patches to enhance the support of QSPI flash memories. Patch 4 was dedicated to the m25p80 driver and set the rx_nbits / tx_nbits fields of spi_transfer struct(s) in order to configure the number of I/O lines independently for the opcode, address and data parts. The work was done for m25p80_read() but also for _read_reg(), _write_reg() and _write(). The patched m25p80 driver was then tested with an at25 memory to check non- regression. This series of patches also added 4 enum spi_protocol fields inside struct spi_nor so the spi-nor framework can tell the (Q)SPI controller driver what SPI protocol should be use for erase, read, write and register read/write operations, depending on the memory manufacturer and the command opcode. This was done to better support Micron, Spansion and Macronix QSPI memories. I have tested the series with Micron QSPI memories and Atmel QSPI controller and I guess Marek also tested it on his side with Spansion QSPI memories and another QSPI controller. So if it can help other developers to develop QSPI controller drivers, the series is still available there: for the whole series: http://
Re: [PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
On 11/13/2015 03:41 PM, Tony Lindgren wrote: > * Neil Armstrong [151112 06:16]: >> On 10/24/2015 12:09 PM, Neil Armstrong wrote: >>> Hi, >>> >>> 2015-10-24 3:21 GMT+02:00 Tony Lindgren : Hi, * Neil Armstrong [151022 02:19]: > Add missing HWMOD_NO_IDLEST hwmod flag for entries no > having omap4 clkctrl values. Have you checked this is the case both in dm814x and dm816x TRM? Also the documentation may not be complete FYI, might be also worth checking the legacy TI kernel tree to be sure. Regards, Tony > Cc: Brian Hutchinson > Signed-off-by: Neil Armstrong > --- > arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > index b1288f5..6256052 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c > @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = { > .name = "l4_ls", > .clkdm_name = "alwon_l3s_clkdm", > .class = &l4_hwmod_class, > + .flags = HWMOD_NO_IDLEST, > }; >>> In DM814x TRM, the CM_ALWON_L3_SLOW_CLKSTCTRL does not have IDLEST field. >>> Same in DM816x TRM. >>> > > /* > @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = { > .name = "l4_hs", > .clkdm_name = "alwon_l3_med_clkdm", > .class = &l4_hwmod_class, > + .flags = HWMOD_NO_IDLEST, > }; >>> In DM814x TRM, the CM_ALWON_L3_MED_CLKSTCTRL does not have IDLEST field. >>> Same in DM816x TRM. >>> > > /* L3 slow -> L4 ls peripheral interface running at 125MHz */ > @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = { > .name = "emac0", > .clkdm_name = "alwon_ethernet_clkdm", > .class = &dm816x_emac_hwmod_class, > + .flags = HWMOD_NO_IDLEST, > }; >>> In this particular case, the IDLEST is handled in the MDIO hwmod. >>> > > static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = { > -- > 1.9.1 >>> >>> I'll check the TI tree to be sure... >>> >>> Regards, >>> Neil >>> >> Tony, >> >> In TI's tree, there is no L3_MED hwmod but the L3_SLOW hwmod has NO_IDLEST >> flag. >> >> Is there any other issue about this patchset ? > > Thanks for checking. Well one thing, if this is needed as fix, then a > description of what happens without it would be good to have. > > Regards, > > Tony > Tony, I'll send a patchset with the error lines in a few minutes. Neil -- 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] clocksource: arm_global_timer: fix suspend resume
Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that ARM Global timer loses its contexts. The reason of stall is that ARM Global timer loses its contexts during System suspend: GT_CONTROL.TIMER_ENABLE = 0 (unbanked) GT_COUNTERx = 0 Hence, update ARM Global timer driver to reflect above behaviour - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; - ensure clocksource and clockevent devices have coresponding flags (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set depending on presence of "always-on" DT property. CC: Arnd Bergmann Cc: John Stultz Cc: Felipe Balbi Cc: Tony Lindgren Signed-off-by: Grygorii Strashko --- drivers/clocksource/arm_global_timer.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index a2cb6fa..1bbaf64 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -51,6 +51,8 @@ static void __iomem *gt_base; static unsigned long gt_clk_rate; static int gt_ppi; static struct clock_event_device __percpu *gt_evt; +static bool gt_always_on; +static u32 gt_control; /* * To get the value from the Global Timer Counter register proceed as follows: @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) { int cpu = smp_processor_id(); + if (!gt_always_on) + clk->features |= CLOCK_EVT_FEAT_C3STOP; + clk->name = "arm_global_timer"; clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU; @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource *cs) return gt_counter_read(); } +static void gt_suspend(struct clocksource *cs) +{ + gt_control = readl(gt_base + GT_CONTROL); +} + +static void gt_resume(struct clocksource *cs) +{ + /* enables timer on all the cores */ + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); +} + static struct clocksource gt_clocksource = { .name = "arm_global_timer", .rating = 300, .read = gt_clocksource_read, .mask = CLOCKSOURCE_MASK(64), .flags = CLOCK_SOURCE_IS_CONTINUOUS, + .suspend = gt_suspend, + .resume = gt_resume, }; #ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK @@ -218,6 +236,9 @@ static void __init gt_clocksource_init(void) /* enables timer on all the cores */ writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); + if (gt_always_on) + gt_clocksource.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP; + #ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate); #endif @@ -289,6 +310,8 @@ static void __init global_timer_of_register(struct device_node *np) goto out_clk; } + gt_always_on = of_property_read_bool(np, "always-on"); + err = request_percpu_irq(gt_ppi, gt_clockevent_interrupt, "gt", gt_evt); if (err) { -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] arm: omap2+: complete dm816x hwmod and clkdev
In order to fix support for the dm816x platform, add missing bits in the 81xx hwmod data. The clk related patch adds the missing clkdev entries to fix all source selection in the dmtimer driver. The last patch adds hwmod support of the spinbox module. v2: add error logs for first patch Neil Armstrong (4): arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data clk: ti816x: Add missing dmtimer clkdev entries arm: plat-omap: add DT support for ti,dm816-timer arm: omap2+: Add hwmod spinbox support for dm816x arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 38 ++ arch/arm/plat-omap/dmtimer.c | 4 drivers/clk/ti/clk-816x.c | 2 ++ 3 files changed, 44 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] arm: omap2+: Add hwmod spinbox support for dm816x
Add dm81xx hwmod data entries for dm816x spinbox support. Cc: Brian Hutchinson Signed-off-by: Neil Armstrong --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 35 ++ 1 file changed, 35 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c index 6256052..275b16c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c @@ -1036,6 +1036,40 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__mailbox = { .user = OCP_USER_MPU, }; +static struct omap_hwmod_class_sysconfig dm81xx_spinbox_sysc = { + .rev_offs = 0x000, + .sysc_offs = 0x010, + .syss_offs = 0x014, + .sysc_flags = SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE, + .idlemodes = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART, + .sysc_fields= &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class dm81xx_spinbox_hwmod_class = { + .name = "spinbox", + .sysc = &dm81xx_spinbox_sysc, +}; + +static struct omap_hwmod dm81xx_spinbox_hwmod = { + .name = "spinbox", + .clkdm_name = "alwon_l3s_clkdm", + .class = &dm81xx_spinbox_hwmod_class, + .main_clk = "sysclk6_ck", + .prcm = { + .omap4 = { + .clkctrl_offs = DM81XX_CM_ALWON_SPINBOX_CLKCTRL, + .modulemode = MODULEMODE_SWCTRL, + }, + }, +}; + +static struct omap_hwmod_ocp_if dm81xx_l4_ls__spinbox = { + .master = &dm81xx_l4_ls_hwmod, + .slave = &dm81xx_spinbox_hwmod, + .user = OCP_USER_MPU, +}; + static struct omap_hwmod_class dm81xx_tpcc_hwmod_class = { .name = "tpcc", }; @@ -1298,6 +1332,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] __initdata = { &dm816x_l4_ls__timer7, &dm81xx_l4_ls__mcspi1, &dm81xx_l4_ls__mailbox, + &dm81xx_l4_ls__spinbox, &dm81xx_l4_hs__emac0, &dm81xx_emac0__mdio, &dm816x_l4_hs__emac1, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] arm: plat-omap: add DT support for ti,dm816-timer
Adds ti,dm816-timer to the dmtimer OF match table. Cc: Brian Hutchinson Signed-off-by: Neil Armstrong --- arch/arm/plat-omap/dmtimer.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 8ca94d3..28a6550 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -943,6 +943,10 @@ static const struct of_device_id omap_timer_match[] = { .compatible = "ti,am335x-timer-1ms", .data = &omap3plus_pdata, }, + { + .compatible = "ti,dm816-timer", + .data = &omap3plus_pdata, + }, {}, }; MODULE_DEVICE_TABLE(of, omap_timer_match); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
Add missing HWMOD_NO_IDLEST hwmod flag for entries not having omap4 clkctrl values. The emac0 hwmod flag fixes the davinci_emac driver probe since the return of pm_resume() call is now checked. This solves the following boot errors : [0.121429] omap_hwmod: l4_ls: _wait_target_ready failed: -16 [0.121441] omap_hwmod: l4_ls: cannot be enabled for reset (3) [0.124342] omap_hwmod: l4_hs: _wait_target_ready failed: -16 [0.124352] omap_hwmod: l4_hs: cannot be enabled for reset (3) [1.967228] omap_hwmod: emac0: _wait_target_ready failed: -16 Cc: Brian Hutchinson Signed-off-by: Neil Armstrong --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c index b1288f5..6256052 100644 --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = { .name = "l4_ls", .clkdm_name = "alwon_l3s_clkdm", .class = &l4_hwmod_class, + .flags = HWMOD_NO_IDLEST, }; /* @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = { .name = "l4_hs", .clkdm_name = "alwon_l3_med_clkdm", .class = &l4_hwmod_class, + .flags = HWMOD_NO_IDLEST, }; /* L3 slow -> L4 ls peripheral interface running at 125MHz */ @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = { .name = "emac0", .clkdm_name = "alwon_ethernet_clkdm", .class = &dm816x_emac_hwmod_class, + .flags = HWMOD_NO_IDLEST, }; static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = { -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] clk: ti816x: Add missing dmtimer clkdev entries
Add missing clkdev dmtimer related entries for dm816x. 32Khz and ext sources were missing. Cc: Brian Hutchinson Acked-by: Tony Lindgren Signed-off-by: Neil Armstrong --- drivers/clk/ti/clk-816x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c index 1dfad0c..2a5d84f 100644 --- a/drivers/clk/ti/clk-816x.c +++ b/drivers/clk/ti/clk-816x.c @@ -20,6 +20,8 @@ static struct ti_dt_clk dm816x_clks[] = { DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"), DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"), DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"), + DT_CLK(NULL, "timer_32k_ck", "sysclk18_ck"), + DT_CLK(NULL, "timer_ext_ck", "tclkin_ck"), DT_CLK(NULL, "mpu_ck", "mpu_ck"), DT_CLK(NULL, "timer1_fck", "timer1_fck"), DT_CLK(NULL, "timer2_fck", "timer2_fck"), -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices
On 11/13/2015 5:07 AM, Mason wrote: On 13/11/2015 13:48, Grygorii Strashko wrote: On 11/12/2015 08:06 PM, Felipe Balbi wrote: Make sure to tell the kernel that AM437x has TWD and global timers. Signed-off-by: Felipe Balbi --- Hi Tony, now that all dependencies are in place, we can finally enable twd and global_timer for AM437x. Is AM437x SMP SOC ? Is TWD on AM437x works in low power states ? Probably I haven't followed the recent updates, but does the TWD supports C3STOP on UP systems ? The broadcast code was SMP only in past, and TWD use to die in low power state on past OMAP SOCs. If either of these are still the issue then TWD shouldn't be used. Regards, Santosh -- 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] clocksource: arm_global_timer: fix suspend resume
Hi, Grygorii Strashko writes: > Now the System stall is observed on TI AM437x based board > (am437x-gp-evm) during resuming from System suspend when ARM Global > timer is selected as clocksource device - SysRq are working, but > nothing else. The reason of stall is that ARM Global timer loses its > contexts. > > The reason of stall is that ARM Global timer loses its contexts during > System suspend: >GT_CONTROL.TIMER_ENABLE = 0 (unbanked) >GT_COUNTERx = 0 > > Hence, update ARM Global timer driver to reflect above behaviour > - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; > - ensure clocksource and clockevent devices have coresponding flags > (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set > depending on presence of "always-on" DT property. > > CC: Arnd Bergmann > Cc: John Stultz > Cc: Felipe Balbi > Cc: Tony Lindgren > Signed-off-by: Grygorii Strashko > --- > drivers/clocksource/arm_global_timer.c | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/clocksource/arm_global_timer.c > b/drivers/clocksource/arm_global_timer.c > index a2cb6fa..1bbaf64 100644 > --- a/drivers/clocksource/arm_global_timer.c > +++ b/drivers/clocksource/arm_global_timer.c > @@ -51,6 +51,8 @@ static void __iomem *gt_base; > static unsigned long gt_clk_rate; > static int gt_ppi; > static struct clock_event_device __percpu *gt_evt; > +static bool gt_always_on; > +static u32 gt_control; > > /* > * To get the value from the Global Timer Counter register proceed as > follows: > @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device > *clk) > { > int cpu = smp_processor_id(); > > + if (!gt_always_on) > + clk->features |= CLOCK_EVT_FEAT_C3STOP; > + > clk->name = "arm_global_timer"; > clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | > CLOCK_EVT_FEAT_PERCPU; > @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource > *cs) > return gt_counter_read(); > } > > +static void gt_suspend(struct clocksource *cs) > +{ > + gt_control = readl(gt_base + GT_CONTROL); > +} > + > +static void gt_resume(struct clocksource *cs) > +{ > + /* enables timer on all the cores */ > + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); do you really need to save context if all you restore is TIMER_ENABLE bit ? seems like you could skip gt_suspend altogether. Is there really a situation where this driver is running and GT isn't enabled ? -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected
Here the test results: Am 13.11.2015 um 13:01 schrieb Laurent Pinchart : > On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote: >> On 13/11/15 12:29, H. Nikolaus Schaller wrote: >>> Include VENC in the set of drivers where it is assimed that the cable >>> is always connected. Like DPI, DSI, DBI and SDI do. >>> >>> Otherwise, the VENC will return cable status "unknown" and is not enabled >>> by the X-server. So there is no video output signal. >>> >>> Tested on: BeagleBoard XM, GTA04 and OpenPandora >>> >>> Signed-off-by: H. Nikolaus Schaller >>> --- >>> >>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c >>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644 >>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c >>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c >>> @@ -120,6 +120,7 @@ static enum drm_connector_status >>> omap_connector_detect( >>> else >>> ret = connector_status_disconnected; >>> } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI || >>> + dssdev->type == OMAP_DISPLAY_TYPE_VENC || >>> dssdev->type == OMAP_DISPLAY_TYPE_DBI || >>> dssdev->type == OMAP_DISPLAY_TYPE_SDI || >>> dssdev->type == OMAP_DISPLAY_TYPE_DSI) { >> >> I have no idea why VENC is not working for you when using >> connector_status_unknown, but I just tested DPI with >> connector_status_unknown (i.e. changed the above func to return unknown >> for DPI), and it works fine with X and X omap driver. And xrandr >> confirms that the connection status is unknown: >> >> # xrandr >> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048 >> HDMI-1 disconnected (normal left inverted right x axis y axis) >> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x >> axis y axis) 0mm x 0mm >> 1920x1200 60.00*+ 60.00 + A) with this VENC patch: root@letux:~# xrandr Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048 None-1 connected 720x574+0+0 0mm x 0mm 720x574i 50.00*+ None-2 connected 480x640+0+0 0mm x 0mm 480x640 65.74*+ root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled enabled enabled root@letux:~# cat /sys/class/drm/card0-Unknown-*/status connected connected B) w/o VENC patch (VENC returns returning connector_status_unknown): root@letux:~# xrandr Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048 None-1 connected 480x640+0+0 0mm x 0mm 480x640 65.74*+ None-2 unknown connection 720x574i 50.00 + root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled enabled disabled root@letux:~# cat /sys/class/drm/card0-Unknown-*/status connected unknown C) with DPI (also) returning connector_status_unknown root@letux:~# xrandr Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048 None-1 unknown connection 720x574+0+0 0mm x 0mm 720x574i 50.00*+ None-2 unknown connection 480x640+0+0 0mm x 0mm 480x640 65.74*+ root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled enabled enabled root@letux:~# cat /sys/class/drm/card0-Unknown-*/status unknown unknown root@letux:~# D) VENC patch but DPI returning connector_status_unknown rroot@letux:~# xrandr Screen 0: minimum 320 x 200, current 720 x 574, maximum 2048 x 2048 None-1 unknown connection 480x640 65.74 + None-2 connected 720x574+0+0 0mm x 0mm 720x574i 50.00*+oot@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled disabled enabled root@letux:~# cat /sys/class/drm/card0-Unknown-*/status unknown connected In case B) I have no TV out and in case D) I have no LCD. So it looks as if it works if my LCD and VENC report the same connection status. And fails if they differ. Anyone with an explanation or even vague idea where to search for the real bug? BR and thanks, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro
Using constants for pinctrl allows better readability and removes redundancy with comments. AM33XX_IOPAD allows us to use part of the pinctrl physical address as in the TRM instead of an offset. Signed-off-by: Andrew F. Davis Reviewed-by: Javier Martinez Canillas --- arch/arm/boot/dts/am335x-boneblack.dts | 44 +- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts index eadbba3..55c0e95 100644 --- a/arch/arm/boot/dts/am335x-boneblack.dts +++ b/arch/arm/boot/dts/am335x-boneblack.dts @@ -36,32 +36,32 @@ &am33xx_pinmux { nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins { pinctrl-single,pins = < - 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ - 0xa0 0x08 /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xa4 0x08 /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xa8 0x08 /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xac 0x08 /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xb0 0x08 /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xb4 0x08 /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xb8 0x08 /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xbc 0x08 /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xc0 0x08 /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xc4 0x08 /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xc8 0x08 /* lcd_data10.lcd_data10, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xcc 0x08 /* lcd_data11.lcd_data11, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xd0 0x08 /* lcd_data12.lcd_data12, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xd4 0x08 /* lcd_data13.lcd_data13, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xd8 0x08 /* lcd_data14.lcd_data14, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xdc 0x08 /* lcd_data15.lcd_data15, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */ - 0xe0 0x00 /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ - 0xe4 0x00 /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ - 0xe8 0x00 /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ - 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */ + AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */ + AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */ + AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */ + AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */ + AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */ + AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */ + AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */ + AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */ + AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */ + AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */ + AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */ + AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */ + AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */ + AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */ + AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */ + AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */ + AM33XX_IOPAD(0x8dc, PIN_
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
On 11/13/2015 06:43 PM, Felipe Balbi wrote: > > Hi, > > Grygorii Strashko writes: >> Now the System stall is observed on TI AM437x based board >> (am437x-gp-evm) during resuming from System suspend when ARM Global >> timer is selected as clocksource device - SysRq are working, but >> nothing else. The reason of stall is that ARM Global timer loses its >> contexts. >> >> The reason of stall is that ARM Global timer loses its contexts during >> System suspend: >> GT_CONTROL.TIMER_ENABLE = 0 (unbanked) >> GT_COUNTERx = 0 >> >> Hence, update ARM Global timer driver to reflect above behaviour >> - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; >> - ensure clocksource and clockevent devices have coresponding flags >>(CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set >>depending on presence of "always-on" DT property. >> >> CC: Arnd Bergmann >> Cc: John Stultz >> Cc: Felipe Balbi >> Cc: Tony Lindgren >> Signed-off-by: Grygorii Strashko >> --- >> drivers/clocksource/arm_global_timer.c | 23 +++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/drivers/clocksource/arm_global_timer.c >> b/drivers/clocksource/arm_global_timer.c >> index a2cb6fa..1bbaf64 100644 >> --- a/drivers/clocksource/arm_global_timer.c >> +++ b/drivers/clocksource/arm_global_timer.c >> @@ -51,6 +51,8 @@ static void __iomem *gt_base; >> static unsigned long gt_clk_rate; >> static int gt_ppi; >> static struct clock_event_device __percpu *gt_evt; >> +static bool gt_always_on; >> +static u32 gt_control; >> >> /* >>* To get the value from the Global Timer Counter register proceed as >> follows: >> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device >> *clk) >> { >> int cpu = smp_processor_id(); >> >> +if (!gt_always_on) >> +clk->features |= CLOCK_EVT_FEAT_C3STOP; >> + >> clk->name = "arm_global_timer"; >> clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | >> CLOCK_EVT_FEAT_PERCPU; >> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource >> *cs) >> return gt_counter_read(); >> } >> >> +static void gt_suspend(struct clocksource *cs) >> +{ >> +gt_control = readl(gt_base + GT_CONTROL); >> +} >> + >> +static void gt_resume(struct clocksource *cs) >> +{ >> +/* enables timer on all the cores */ >> +writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); > > do you really need to save context if all you restore is TIMER_ENABLE > bit ? seems like you could skip gt_suspend altogether. Is there really a > situation where this driver is running and GT isn't enabled ? Now It's not. It's always enabled. I did it because .suspend() is called for all registered clock sources regardless of their usage. So, potentially in the future, at the moment when .suspend() is called it might be disabled (for example, .enable/disable() callbacks can be added and, if ARM Global timer will not be registered as sched_clock, it will be possible to keep it disabled if not used now). But It's not essentially now - I can update it and drop save restore. Pls, confirm. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices
On 11/13/2015 02:48 PM, Grygorii Strashko wrote: > On 11/12/2015 08:06 PM, Felipe Balbi wrote: >> Make sure to tell the kernel that AM437x has >> TWD and global timers. >> >> Signed-off-by: Felipe Balbi >> --- >> >> Hi Tony, >> >> now that all dependencies are in place, we can >> finally enable twd and global_timer for AM437x. >> > > I'd appreciated if someone can clarify if all described below is valid. > (may be some questions are dummy - sorry). > > After all last changes related to TI OMAP clock source/clock event/sched > clock's > devices configuration we will have the following for am437x case: > > clockevents: > "timer1", clockevent_gpt, .rating = 300, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT, ti,timer-alwon, > "arm,twd-timer",twd_evt,.rating = 350, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP > "arm_global_timer", gt_evt, rating = 300, CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU > > clocksources: > "jiffies", clocksource_jiffies, rating = 1 > if use_gptimer_clksrc > "timer2", clocksource_gpt, .rating = 300, CLOCK_SOURCE_IS_CONTINUOUS, > |-sched_clock_register(dmtimer_read_sched_clock, 32, clksrc.rate); > else > "ti,omap-counter32k", ti_32k_timer, .rating = 250, > CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP, > |-sched_clock_register(omap_32k_read_sched_clock, 32, 32768); > > "arm,global-timer", gt_clocksource, .rating = 300, > CLOCK_SOURCE_IS_CONTINUOUS > |-sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate); > > 1) current clockevent device will be registered during registration of > clockevent devices > and it will be "arm,twd-timer" - processing sequence follows the way they > are listed above. > > 2) current clocksource will be selected from > fs_initcall(clocksource_done_booting); > and it will be "arm,global-timer" or "timer2" if use_gptimer_clksrc > > 3) sched clock: "arm,global-timer" will be selected as sched_clock *always*, > because it depend on Makefile order (if someone will decide to sort entries > in drivers/clocksource/Makefile then "ti,omap-counter32k" most probably will > be always selected as sched clock). Ok. Sry. Above is not completely true. There are no dependency on makefile and sched clock with Max freq will be selected - and never changed even if corresponding clocksource can be changed through sysfs. > > Uh.. > > As for me, "timer1" is selected as clockevent device incorrectly, because it's > ti,timer-alwon. > > I think, "ti,omap-counter32k" will crash if use_gptimer_clksrc == true, > because > corresponding HWmod will not be enabled (not tested this case). Ok. Below is confirmation for the case if use_gptimer_clksrc == true, so https://www.spinics.net/lists/linux-omap/msg122576.html "[PATCH 00/11] arm: omap: counter32k rework" introduces regression !? cat /sys/devices/system/clocksource/clocksource0/available_clocksource timer2 arm_global_timer 32k_counter / # echo 32k_counter > /sys/devices/system/clocksource/clocksource0/current_cloc ksource [ 102.194313] Unhandled fault: imprecise external abort (0x1406) at 0x0020ab5c [ 102.197862] pgd = ee22c000 -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
Hi, Grygorii Strashko writes: > On 11/13/2015 06:43 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> Now the System stall is observed on TI AM437x based board >>> (am437x-gp-evm) during resuming from System suspend when ARM Global >>> timer is selected as clocksource device - SysRq are working, but >>> nothing else. The reason of stall is that ARM Global timer loses its >>> contexts. >>> >>> The reason of stall is that ARM Global timer loses its contexts during >>> System suspend: >>> GT_CONTROL.TIMER_ENABLE = 0 (unbanked) >>> GT_COUNTERx = 0 >>> >>> Hence, update ARM Global timer driver to reflect above behaviour >>> - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; >>> - ensure clocksource and clockevent devices have coresponding flags >>>(CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set >>>depending on presence of "always-on" DT property. >>> >>> CC: Arnd Bergmann >>> Cc: John Stultz >>> Cc: Felipe Balbi >>> Cc: Tony Lindgren >>> Signed-off-by: Grygorii Strashko >>> --- >>> drivers/clocksource/arm_global_timer.c | 23 +++ >>> 1 file changed, 23 insertions(+) >>> >>> diff --git a/drivers/clocksource/arm_global_timer.c >>> b/drivers/clocksource/arm_global_timer.c >>> index a2cb6fa..1bbaf64 100644 >>> --- a/drivers/clocksource/arm_global_timer.c >>> +++ b/drivers/clocksource/arm_global_timer.c >>> @@ -51,6 +51,8 @@ static void __iomem *gt_base; >>> static unsigned long gt_clk_rate; >>> static int gt_ppi; >>> static struct clock_event_device __percpu *gt_evt; >>> +static bool gt_always_on; >>> +static u32 gt_control; >>> >>> /* >>>* To get the value from the Global Timer Counter register proceed as >>> follows: >>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct >>> clock_event_device *clk) >>> { >>> int cpu = smp_processor_id(); >>> >>> + if (!gt_always_on) >>> + clk->features |= CLOCK_EVT_FEAT_C3STOP; >>> + >>> clk->name = "arm_global_timer"; >>> clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | >>> CLOCK_EVT_FEAT_PERCPU; >>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource >>> *cs) >>> return gt_counter_read(); >>> } >>> >>> +static void gt_suspend(struct clocksource *cs) >>> +{ >>> + gt_control = readl(gt_base + GT_CONTROL); >>> +} >>> + >>> +static void gt_resume(struct clocksource *cs) >>> +{ >>> + /* enables timer on all the cores */ >>> + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); >> >> do you really need to save context if all you restore is TIMER_ENABLE >> bit ? seems like you could skip gt_suspend altogether. Is there really a >> situation where this driver is running and GT isn't enabled ? > > Now It's not. It's always enabled. I did it because .suspend() is called for > all registered clock sources regardless of their usage. So, potentially > in the future, at the moment when .suspend() is called it might be disabled > (for example, .enable/disable() callbacks can be added and, if ARM Global > timer > will not be registered as sched_clock, it will be possible to keep it > disabled > if not used now). > > But It's not essentially now - I can update it and drop save restore. > Pls, confirm. I think it's best to skip suspend completely. You're not restoring anything you saved during suspend, unless you meant | where you used &. -- balbi signature.asc Description: PGP signature
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
On 11/13/2015 07:40 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 11/13/2015 06:43 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that ARM Global timer loses its contexts. The reason of stall is that ARM Global timer loses its contexts during System suspend: GT_CONTROL.TIMER_ENABLE = 0 (unbanked) GT_COUNTERx = 0 Hence, update ARM Global timer driver to reflect above behaviour - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; - ensure clocksource and clockevent devices have coresponding flags (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set depending on presence of "always-on" DT property. CC: Arnd Bergmann Cc: John Stultz Cc: Felipe Balbi Cc: Tony Lindgren Signed-off-by: Grygorii Strashko --- drivers/clocksource/arm_global_timer.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index a2cb6fa..1bbaf64 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -51,6 +51,8 @@ static void __iomem *gt_base; static unsigned long gt_clk_rate; static int gt_ppi; static struct clock_event_device __percpu *gt_evt; +static bool gt_always_on; +static u32 gt_control; /* * To get the value from the Global Timer Counter register proceed as follows: @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) { int cpu = smp_processor_id(); + if (!gt_always_on) + clk->features |= CLOCK_EVT_FEAT_C3STOP; + clk->name = "arm_global_timer"; clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU; @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource *cs) return gt_counter_read(); } +static void gt_suspend(struct clocksource *cs) +{ + gt_control = readl(gt_base + GT_CONTROL); +} + +static void gt_resume(struct clocksource *cs) +{ + /* enables timer on all the cores */ + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); do you really need to save context if all you restore is TIMER_ENABLE bit ? seems like you could skip gt_suspend altogether. Is there really a situation where this driver is running and GT isn't enabled ? Now It's not. It's always enabled. I did it because .suspend() is called for all registered clock sources regardless of their usage. So, potentially in the future, at the moment when .suspend() is called it might be disabled (for example, .enable/disable() callbacks can be added and, if ARM Global timer will not be registered as sched_clock, it will be possible to keep it disabled if not used now). But It's not essentially now - I can update it and drop save restore. Pls, confirm. I think it's best to skip suspend completely. You're not restoring anything you saved during suspend, unless you meant | where you used &. I didn't get it - I'm restoring one bit(0) only. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
Hi, Grygorii Strashko writes: > On 11/13/2015 07:40 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> On 11/13/2015 06:43 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: > Now the System stall is observed on TI AM437x based board > (am437x-gp-evm) during resuming from System suspend when ARM Global > timer is selected as clocksource device - SysRq are working, but > nothing else. The reason of stall is that ARM Global timer loses its > contexts. > > The reason of stall is that ARM Global timer loses its contexts during > System suspend: > GT_CONTROL.TIMER_ENABLE = 0 (unbanked) > GT_COUNTERx = 0 > > Hence, update ARM Global timer driver to reflect above behaviour > - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; > - ensure clocksource and clockevent devices have coresponding flags > (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set > depending on presence of "always-on" DT property. > > CC: Arnd Bergmann > Cc: John Stultz > Cc: Felipe Balbi > Cc: Tony Lindgren > Signed-off-by: Grygorii Strashko > --- >drivers/clocksource/arm_global_timer.c | 23 +++ >1 file changed, 23 insertions(+) > > diff --git a/drivers/clocksource/arm_global_timer.c > b/drivers/clocksource/arm_global_timer.c > index a2cb6fa..1bbaf64 100644 > --- a/drivers/clocksource/arm_global_timer.c > +++ b/drivers/clocksource/arm_global_timer.c > @@ -51,6 +51,8 @@ static void __iomem *gt_base; >static unsigned long gt_clk_rate; >static int gt_ppi; >static struct clock_event_device __percpu *gt_evt; > +static bool gt_always_on; > +static u32 gt_control; > >/* > * To get the value from the Global Timer Counter register proceed as > follows: > @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct > clock_event_device *clk) >{ > int cpu = smp_processor_id(); > > + if (!gt_always_on) > + clk->features |= CLOCK_EVT_FEAT_C3STOP; > + > clk->name = "arm_global_timer"; > clk->features = CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | > CLOCK_EVT_FEAT_PERCPU; > @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct > clocksource *cs) > return gt_counter_read(); >} > > +static void gt_suspend(struct clocksource *cs) > +{ > + gt_control = readl(gt_base + GT_CONTROL); > +} > + > +static void gt_resume(struct clocksource *cs) > +{ > + /* enables timer on all the cores */ > + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); do you really need to save context if all you restore is TIMER_ENABLE bit ? seems like you could skip gt_suspend altogether. Is there really a situation where this driver is running and GT isn't enabled ? >>> >>> Now It's not. It's always enabled. I did it because .suspend() is called for >>> all registered clock sources regardless of their usage. So, potentially >>> in the future, at the moment when .suspend() is called it might be disabled >>> (for example, .enable/disable() callbacks can be added and, if ARM Global >>> timer >>> will not be registered as sched_clock, it will be possible to keep it >>> disabled >>> if not used now). >>> >>> But It's not essentially now - I can update it and drop save restore. >>> Pls, confirm. >> >> I think it's best to skip suspend completely. You're not restoring >> anything you saved during suspend, unless you meant | where you used &. >> > > I didn't get it - I'm restoring one bit(0) only. that's the point, if you know you're restoring only that bit. Why save anything at all ? -- balbi signature.asc Description: PGP signature
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
On 11/13/2015 08:15 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 11/13/2015 07:40 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: On 11/13/2015 06:43 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that ARM Global timer loses its contexts. The reason of stall is that ARM Global timer loses its contexts during System suspend: GT_CONTROL.TIMER_ENABLE = 0 (unbanked) GT_COUNTERx = 0 Hence, update ARM Global timer driver to reflect above behaviour - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; - ensure clocksource and clockevent devices have coresponding flags (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set depending on presence of "always-on" DT property. CC: Arnd Bergmann Cc: John Stultz Cc: Felipe Balbi Cc: Tony Lindgren Signed-off-by: Grygorii Strashko --- drivers/clocksource/arm_global_timer.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index a2cb6fa..1bbaf64 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -51,6 +51,8 @@ static void __iomem *gt_base; static unsigned long gt_clk_rate; static int gt_ppi; static struct clock_event_device __percpu *gt_evt; +static bool gt_always_on; +static u32 gt_control; /* * To get the value from the Global Timer Counter register proceed as follows: @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) { int cpu = smp_processor_id(); + if (!gt_always_on) + clk->features |= CLOCK_EVT_FEAT_C3STOP; + clk->name = "arm_global_timer"; clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU; @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource *cs) return gt_counter_read(); } +static void gt_suspend(struct clocksource *cs) +{ + gt_control = readl(gt_base + GT_CONTROL); +} + +static void gt_resume(struct clocksource *cs) +{ + /* enables timer on all the cores */ + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); do you really need to save context if all you restore is TIMER_ENABLE bit ? seems like you could skip gt_suspend altogether. Is there really a situation where this driver is running and GT isn't enabled ? Now It's not. It's always enabled. I did it because .suspend() is called for all registered clock sources regardless of their usage. So, potentially in the future, at the moment when .suspend() is called it might be disabled (for example, .enable/disable() callbacks can be added and, if ARM Global timer will not be registered as sched_clock, it will be possible to keep it disabled if not used now). But It's not essentially now - I can update it and drop save restore. Pls, confirm. I think it's best to skip suspend completely. You're not restoring anything you saved during suspend, unless you meant | where you used &. I didn't get it - I'm restoring one bit(0) only. that's the point, if you know you're restoring only that bit. Why save anything at all ? i think there are difference between "restoring" and "re-enabling". "restoring" - assume saving smth.. then restore saving value. I'm saving & restoring one bit here. But I can do just "re-enabling" - writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); and then I don't need to save anything. It will work with current code. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
Hi, Grygorii Strashko writes: > On 11/13/2015 08:15 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> On 11/13/2015 07:40 PM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: > On 11/13/2015 06:43 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> Now the System stall is observed on TI AM437x based board >>> (am437x-gp-evm) during resuming from System suspend when ARM Global >>> timer is selected as clocksource device - SysRq are working, but >>> nothing else. The reason of stall is that ARM Global timer loses its >>> contexts. >>> >>> The reason of stall is that ARM Global timer loses its contexts during >>> System suspend: >>> GT_CONTROL.TIMER_ENABLE = 0 (unbanked) >>> GT_COUNTERx = 0 >>> >>> Hence, update ARM Global timer driver to reflect above behaviour >>> - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; >>> - ensure clocksource and clockevent devices have coresponding flags >>> (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set >>> depending on presence of "always-on" DT property. >>> >>> CC: Arnd Bergmann >>> Cc: John Stultz >>> Cc: Felipe Balbi >>> Cc: Tony Lindgren >>> Signed-off-by: Grygorii Strashko >>> --- >>> drivers/clocksource/arm_global_timer.c | 23 +++ >>> 1 file changed, 23 insertions(+) >>> >>> diff --git a/drivers/clocksource/arm_global_timer.c >>> b/drivers/clocksource/arm_global_timer.c >>> index a2cb6fa..1bbaf64 100644 >>> --- a/drivers/clocksource/arm_global_timer.c >>> +++ b/drivers/clocksource/arm_global_timer.c >>> @@ -51,6 +51,8 @@ static void __iomem *gt_base; >>> static unsigned long gt_clk_rate; >>> static int gt_ppi; >>> static struct clock_event_device __percpu *gt_evt; >>> +static bool gt_always_on; >>> +static u32 gt_control; >>> >>> /* >>> * To get the value from the Global Timer Counter register proceed >>> as follows: >>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct >>> clock_event_device *clk) >>> { >>> int cpu = smp_processor_id(); >>> >>> + if (!gt_always_on) >>> + clk->features |= CLOCK_EVT_FEAT_C3STOP; >>> + >>> clk->name = "arm_global_timer"; >>> clk->features = CLOCK_EVT_FEAT_PERIODIC | >>> CLOCK_EVT_FEAT_ONESHOT | >>> CLOCK_EVT_FEAT_PERCPU; >>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct >>> clocksource *cs) >>> return gt_counter_read(); >>> } >>> >>> +static void gt_suspend(struct clocksource *cs) >>> +{ >>> + gt_control = readl(gt_base + GT_CONTROL); >>> +} >>> + >>> +static void gt_resume(struct clocksource *cs) >>> +{ >>> + /* enables timer on all the cores */ >>> + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + >>> GT_CONTROL); >> >> do you really need to save context if all you restore is TIMER_ENABLE >> bit ? seems like you could skip gt_suspend altogether. Is there really a >> situation where this driver is running and GT isn't enabled ? > > Now It's not. It's always enabled. I did it because .suspend() is called > for > all registered clock sources regardless of their usage. So, potentially > in the future, at the moment when .suspend() is called it might be > disabled > (for example, .enable/disable() callbacks can be added and, if ARM Global > timer > will not be registered as sched_clock, it will be possible to keep it > disabled > if not used now). > > But It's not essentially now - I can update it and drop save restore. > Pls, confirm. I think it's best to skip suspend completely. You're not restoring anything you saved during suspend, unless you meant | where you used &. >>> >>> I didn't get it - I'm restoring one bit(0) only. >> >> that's the point, if you know you're restoring only that bit. Why save >> anything at all ? >> > > i think there are difference between "restoring" and "re-enabling". > "restoring" - assume saving smth.. then restore saving value. > I'm saving & restoring one bit here. with your current suspend/resume, they are the same thing. You save GT_CONTROL contents, timer goes off and looses context, you set ENABLE bit. No difference what so ever. -- balbi signature.asc Description: PGP signature
Re: [PATCH] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD
On 11/12/2015 11:19 AM, Sebastian Andrzej Siewior wrote: > On 11/06/2015 08:59 PM, Grygorii Strashko wrote: >> Hi Sebastian, > > Hi Grygorii, > >> - IRQF_NO_THREAD is the first considered option for such kind of issues. >>But: Now in LKML there are ~60 occurrences of IRQF_NO_THREAD - most of >>them are used by Arch code. And It's only used by 6 drivers (drivers/*) >> [Addendum 2]. >>During past year, I've found only two threads related to IRQF_NO_THREAD >>and, in both cases, IRQF_NO_THREAD was added for arch specific IRQs which >>can't be threaded >> (https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-November/122659.html, >>https://lkml.org/lkml/2015/4/21/404). > > That powerpc patch you reference is doing the same thing you are doing > here. Probably. I don't know this hw, so my assumption was based on commits descriptions. > >> - ARM UP system: TI's am437xx SoCs for example. >> Here everything is started from /drivers/irqchip/irq-gic.c -> >> gic_handle_irq() >> > >> GIC IRQ handler gic_handle_irq() may process more than one IRQ without >> leaving HW IRQ mode >> (during my experiments I saw up to 6 IRQs processed in one cycle). > > not only GIC. But then what good does it do if it leaves and returns > immediately back to the routine? > >> As result, It was concluded, that having such current HW/SW and all IRQs >> forced threaded [1], >> it will be potentially possible to predict system behavior, because >> gic_handle_irq() will >> do the same things for most of processed IRQs. >> But, once there will be chained [2] or IRQF_NO_THREAD [3] IRQs - complete >> unpredictability. > > I would not go as far as "complete unpredictability". What you do (or > should do) is testing the system for longer period of time with > different behavior in order to estimate the worst case. > You can't predict the system anyway since it is way too complex. Just > try something that ensures that cyclictest is no longer cache hot and > see what happens then. I understand that. That's the current plan and work is in progress. The nearest target is to get rid of all -RT specific backtracks and ensure TI -RT kernel supports the same functionality as non-RT. next step - try to optimize. > >> So, It was selected as goal to have all PPI IRQs (forced) threaded. And if >> someone >> will require faster IRQ handling - IRQF_NO_THREAD can be always added, but >> it will >> be custom solution then. >> >> I'd be appreciated for your comments - if above problem is not a problem. >> Good - IRQF_NO_THREAD forever! > > Yes, we try to avoid IRQF_NO_THREAD under all circumstances. However it > is required for low-level arch code. This includes basically > everything that is using raw-locks which includes interrupt controller > (the "real" ones like GIC or cascading like MSI or GPIO). > Here it is simple - you have a cascading MSI-interrupt controller and > as such it should be IRQF_NO_THREAD marked. > The latency spikes in worst case are not huge as explained earlier: The > only thing your cascading controller is allowed to do is to mark > interrupt as pending (which is with threaded interrupts just a task > wakeup). > And this is not a -RT only problem: it is broken in vanilla linux with > threaded interrupts as well. > Ok. I've got it. IRQF_NO_THREAD will be a solution for reference code and for issues like this. I understand, that each, -RT based, real solution is unique and need to be specifically tuned, so if someone will have problem with IRQF_NO_THREAD - it can be removed easily and replaced with any sort of custom hacks/improvements. Thanks a lot for your comments. I'll apply your previous comments and re-send. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
On 11/13/2015 08:32 PM, Felipe Balbi wrote: > > Hi, > > Grygorii Strashko writes: >> On 11/13/2015 08:15 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Grygorii Strashko writes: On 11/13/2015 07:40 PM, Felipe Balbi wrote: > > Hi, > > Grygorii Strashko writes: >> On 11/13/2015 06:43 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Grygorii Strashko writes: Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that ARM Global timer loses its contexts. The reason of stall is that ARM Global timer loses its contexts during System suspend: GT_CONTROL.TIMER_ENABLE = 0 (unbanked) GT_COUNTERx = 0 Hence, update ARM Global timer driver to reflect above behaviour - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; - ensure clocksource and clockevent devices have coresponding flags (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set depending on presence of "always-on" DT property. CC: Arnd Bergmann Cc: John Stultz Cc: Felipe Balbi Cc: Tony Lindgren Signed-off-by: Grygorii Strashko --- drivers/clocksource/arm_global_timer.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index a2cb6fa..1bbaf64 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -51,6 +51,8 @@ static void __iomem *gt_base; static unsigned long gt_clk_rate; static int gt_ppi; static struct clock_event_device __percpu *gt_evt; +static bool gt_always_on; +static u32 gt_control; /* * To get the value from the Global Timer Counter register proceed as follows: @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) { int cpu = smp_processor_id(); + if (!gt_always_on) + clk->features |= CLOCK_EVT_FEAT_C3STOP; + clk->name = "arm_global_timer"; clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERCPU; @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource *cs) return gt_counter_read(); } +static void gt_suspend(struct clocksource *cs) +{ + gt_control = readl(gt_base + GT_CONTROL); +} + +static void gt_resume(struct clocksource *cs) +{ + /* enables timer on all the cores */ + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL); >>> >>> do you really need to save context if all you restore is TIMER_ENABLE >>> bit ? seems like you could skip gt_suspend altogether. Is there really a >>> situation where this driver is running and GT isn't enabled ? >> >> Now It's not. It's always enabled. I did it because .suspend() is called >> for >> all registered clock sources regardless of their usage. So, potentially >> in the future, at the moment when .suspend() is called it might be >> disabled >> (for example, .enable/disable() callbacks can be added and, if ARM >> Global timer >> will not be registered as sched_clock, it will be possible to keep it >> disabled >> if not used now). >> >> But It's not essentially now - I can update it and drop save restore. >> Pls, confirm. > > I think it's best to skip suspend completely. You're not restoring > anything you saved during suspend, unless you meant | where you used &. > I didn't get it - I'm restoring one bit(0) only. >>> >>> that's the point, if you know you're restoring only that bit. Why save >>> anything at all ? >>> >> >> i think there are difference between "restoring" and "re-enabling". >> "restoring" - assume saving smth.. then restore saving value. >> I'm saving & restoring one bit here. > > with your current suspend/resume, they are the same thing. You save > GT_CONTROL contents, timer goes off and looses context, you set ENABLE > bit. No difference what so ever. > I'm writing: gt_control & GT_CONTROL_TIMER_ENABLE, where gt_control is old value of GT_CONTROL before entering suspend, so on resume: - if gt_control == 0x 0001 ==> gt_control & GT_CONTROL_TIMER_ENAB
Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir
Em Wed, 11 Nov 2015 21:26:31 +0100 Arnd Bergmann escreveu: > On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote: > > rename include/media/{ => platform}/exynos-fimc.h (100%) > > rename include/media/{ => platform}/mmp-camera.h (100%) > > rename include/media/{ => platform}/omap1_camera.h (100%) > > rename include/media/{ => platform}/omap4iss.h (100%) > > rename include/media/{ => platform}/s3c_camif.h (100%) > > rename include/media/{ => platform}/s5p_hdmi.h (100%) > > rename include/media/{ => platform}/sh_mobile_ceu.h (100%) > > rename include/media/{ => platform}/sh_mobile_csi2.h (100%) > > rename include/media/{ => platform}/sh_vou.h (100%) > > rename include/media/{ => platform}/sii9234.h (100%) > > rename include/media/{ => platform}/soc_camera.h (100%) > > rename include/media/{ => platform}/soc_camera_platform.h (98%) > > rename include/media/{ => platform}/soc_mediabus.h (100%) > > This still seems to be a mix of various things. Some of these are interfaces > between drivers, while others declare a foo_platform_data structure that > is used to interface between platform code and the driver. True. What about calling putting those driver interfaces under include/media/drv-intf? That also helps moving the headers for other non-platform drivers too. > > I think the latter should go into include/linux/platform_data/media/*.h > instead. Agreed. Please see the enclosed patch: Subject: [PATCH] [media] include/media: move platform driver headers to a separate dirs Let's not mix headers used by the core with those headers that are needed by some specific platform drivers or by platform data. This patch was made via this script: mkdir include/media/platform mkdir include/media/platform_data (cd include/media/; git mv $(grep -l platform_data *.h|grep -v v4l2) platform_data/) for i in include/media/*.h; do n=`basename $i`; (for j in $(git grep -l $n); do dirname $j; done)|sort|uniq|grep -ve '^.$' > list; num=$(wc -l list|cut -d' ' -f1); if [ $num == 1 ]; then if [ "`grep platform list`" != "" ]; then git mv $i include/media/drv-intf; fi; fi; done git mv include/media/exynos* include/media/soc_* include/media/sh_* include/media/drv-intf/ And some headers were manually adjusted. Then, this script fixed the address for those new headers: for i in $(find include/media/ -type f); do n=`basename $i`; git grep -l $n; done|sort|uniq >files && (echo "for i in \$(cat files); do cat \$i | \\"; cd include/media; for j in platform/ platform_data/; do for i in $(ls $j); do echo "perl -ne 's,(include [\\\"\\<]media/)($i)([\\\"\\>]),\1$j\2\3,; print \$_' |\\"; done; done; echo "cat > a && mv a \$i; done") >script&& . ./script Signed-off-by: Mauro Carvalho Chehab --- arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 2 +- arch/arm/mach-imx/mach-mx27_3ds.c| 2 +- arch/arm/mach-imx/mach-mx31_3ds.c| 2 +- arch/arm/mach-imx/mach-mx35_3ds.c| 2 +- arch/arm/mach-imx/mach-pcm037.c | 2 +- arch/arm/mach-imx/mx31moboard-marxbot.c | 2 +- arch/arm/mach-imx/mx31moboard-smartbot.c | 2 +- arch/arm/mach-omap1/board-ams-delta.c| 2 +- arch/arm/mach-omap1/include/mach/camera.h| 2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 4 ++-- arch/arm/mach-pxa/em-x270.c | 2 +- arch/arm/mach-pxa/ezx.c | 2 +- arch/arm/mach-pxa/mioa701.c | 2 +- arch/arm/mach-pxa/palmz72.c | 2 +- arch/arm/mach-pxa/pcm990-baseboard.c | 2 +- arch/arm/mach-shmobile/board-bockw.c | 2 +- arch/arm/plat-samsung/devs.c | 2 +- arch/sh/boards/mach-ap325rxa/setup.c | 6 +++--- arch/sh/boards/mach-ecovec24/setup.c | 6 +++--- arch/sh/boards/mach-kfr2r09/setup.c | 4 ++-- arch/sh/boards/mach-migor/setup.c| 4 ++-- arch/sh/boards/mach-se/7724/setup.c | 4 ++-- drivers/media/common/cx2341x.c | 2 +- drivers/media/common/saa7146/saa7146_core.c | 2 +- drivers/media/common/saa7146/saa7146_fops.c | 2 +- drivers/media/common/saa7146/saa7146_hlp.c | 2 +- drivers/media/common/saa7146/saa7146_i2c.c | 2 +- drivers/media/common/saa7146/saa7146_vbi.c | 2 +- drivers/media/common/saa7146/saa7146_video.c | 2 +- drivers/media/i2c/cx25840/cx25840-audio.c| 2 +- drivers/media/i2c/cx25840/cx25840-core.c | 2 +- drivers/media/i2c/cx25840/cx25840-firmware.c | 2 +- drivers/media/i2c/cx25840/cx25840-ir.c | 2 +- drivers/media/i2c/cx25840/cx25840-vbi.c
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
Hi Felipe, On 11/13/2015 08:59 PM, Grygorii Strashko wrote: > On 11/13/2015 08:32 PM, Felipe Balbi wrote: >> Grygorii Strashko writes: >>> On 11/13/2015 08:15 PM, Felipe Balbi wrote: Grygorii Strashko writes: > On 11/13/2015 07:40 PM, Felipe Balbi wrote: >> Grygorii Strashko writes: >>> On 11/13/2015 06:43 PM, Felipe Balbi wrote: GrygoCONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCKrii Strashko writes: > Now the System stall is observed on TI AM437x based board > (am437x-gp-evm) during resuming from System suspend when ARM Global > timer is selected as clocksource device - SysRq are working, but > nothing else. The reason of stall is that ARM Global timer loses its > contexts. > > The reason of stall is that ARM Global timer loses its contexts during > System suspend: > GT_CONTROL.TIMER_ENABLE = 0 (unbanked) > GT_COUNTERx = 0 > > Hence, update ARM Global timer driver to reflect above behaviour > - save GT_CONTROL.TIMER_ENABLE during suspend and restore on resume; > - ensure clocksource and clockevent devices have coresponding flags >(CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set >depending on presence of "always-on" DT property. > > CC: Arnd Bergmann > Cc: John Stultz > Cc: Felipe Balbi > Cc: Tony Lindgren > Signed-off-by: Grygorii Strashko > --- > drivers/clocksource/arm_global_timer.c | 23 > +++ > 1 file changed, 23 insertions(+) > > diff --git a/drivers/clocksource/arm_global_timer.c > b/drivers/clocksource/arm_global_timer.c > index a2cb6fa..1bbaf64 100644 > --- a/drivers/clocksource/arm_global_timer.c > +++ b/drivers/clocksource/arm_global_timer.c > @@ -51,6 +51,8 @@ static void __iomem *gt_base; > static unsigned long gt_clk_rate; > static int gt_ppi; > static struct clock_event_device __percpu *gt_evt; > +static bool gt_always_on; > +static u32 gt_control; > > /* >* To get the value from the Global Timer Counter register > proceed as follows: > @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct > clock_event_device *clk) > { > int cpu = smp_processor_id(); > > + if (!gt_always_on) > + clk->features |= CLOCK_EVT_FEAT_C3STOP; > + > clk->name = "arm_global_timer"; > clk->features = CLOCK_EVT_FEAT_PERIODIC | > CLOCK_EVT_FEAT_ONESHOT | > CLOCK_EVT_FEAT_PERCPU; > @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct > clocksource *cs) > return gt_counter_read(); > } > > +static void gt_suspend(struct clocksource *cs) > +{ > + gt_control = readl(gt_base + GT_CONTROL); > +} > + > +static void gt_resume(struct clocksource *cs) > +{ > + /* enables timer on all the cores */ > + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + > GT_CONTROL); do you really need to save context if all you restore is TIMER_ENABLE bit ? seems like you could skip gt_suspend altogether. Is there really a situation where this driver is running and GT isn't enabled ? >>> >>> Now It's not. It's always enabled. I did it because .suspend() is >>> called for >>> all registered clock sources regardless of their usage. So, potentially >>> in the future, at the moment when .suspend() is called it might be >>> disabled >>> (for example, .enable/disable() callbacks can be added and, if ARM >>> Global timer >>> will not be registered as sched_clock, it will be possible to keep it >>> disabled >>> if not used now). >>> >>> But It's not essentially now - I can update it and drop save restore. >>> Pls, confirm. >> >> I think it's best to skip suspend completely. You're not restoring >> anything you saved during suspend, unless you meant | where you used &. >> > > I didn't get it - I'm restoring one bit(0) only. that's the point, if you know you're restoring only that bit. Why save anything at all ? >>> >>> i think there are difference between "restoring" and "re-enabling". >>> "restoring" - assume saving smth.. then restore saving value. >>> I'm saving & restoring one bit here. >> >> with your current suspend/resume, they are the same thing. You save >> GT_CONTROL contents, timer goes off and looses context, you set ENABLE >> bit. No difference what so ever. >> > > I'
Re: [PATCH] clocksource: arm_global_timer: fix suspend resume
On Fri, 13 Nov 2015, Grygorii Strashko wrote: > Any way, I'll wait for other comments a bit, replace save/restore with > just pure re-enabling and re-send. Please folks, trim your emails! I'm really tired of going through hundreds of quoted (quoting level here was 10!!!) useless lines to find a single line of useful information. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir
On Fri, Nov 13, 2015 at 8:13 PM, Mauro Carvalho Chehab wrote: >> I think the latter should go into include/linux/platform_data/media/*.h >> instead. > > Agreed. > > Please see the enclosed patch: > > > Subject: [PATCH] [media] include/media: move platform driver headers to a > separate dirs > > Let's not mix headers used by the core with those headers that > are needed by some specific platform drivers or by platform data. > > This patch was made via this script: > mkdir include/media/platform mkdir include/media/platform_data > (cd include/media/; git mv $(grep -l platform_data *.h|grep -v v4l2) I think include/linux/platform_data/media/, like Arnd suggested, would be better. Then we can make it a common goal to empty include/linux/platform_data/ ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)
Changes V2: * add a patch to make drivers still recognise the old "ti,swap-xy" property (suggested by Rob Herring) 2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04 OpenPandora and Pyra devices. New common bindings have been defined by commit b98abe52fa8e: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt which also defines a helper function to parse the DT. These new parameters allow to specify the fuzz factors (jitter suppression), inversion of x or y axis and swapping of x and y to achieve inversion and rotation so that the touch coordinate axes match the natural orientation of the display panel. Another improvement is to better use the min/max ADC values and scale to the screen size as defined by the DT. This allows to coarsely calibrate the touch to match the LCD to which it is glued on so that the touch can quite precisely be operated before any user-space fine-calibration can be (and needs to be) started. For the adc7846 we fix an issue with the spi module table. Finally we add an iio interface for the AUX and temperature ADC channels of the tsc2007 and also provide the touch screen raw values. This allows to read an optional ambient light sensor installed on the gta04 board and improves calibration and hardware monitoring. H. Nikolaus Schaller (8): drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values DT:omap3+tsc2007: use new common touchscreen bindings drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping drivers:input:ads7846(+tsc2046): fix spi module table DT:omap3+ads7846: use new common touchscreen bindings .../devicetree/bindings/input/ads7846.txt | 8 +- .../bindings/input/touchscreen/tsc2007.txt | 20 +- arch/arm/boot/dts/omap3-gta04.dtsi | 18 +- arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 2 +- arch/arm/boot/dts/omap3-pandora-common.dtsi| 17 +- .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi| 2 +- drivers/input/touchscreen/Kconfig | 1 + drivers/input/touchscreen/ads7846.c| 85 +- drivers/input/touchscreen/tsc2007.c| 286 +++-- include/linux/i2c/tsc2007.h| 8 + 10 files changed, 401 insertions(+), 46 deletions(-) -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] DT:omap3+ads7846: use new common touchscreen bindings
The standard touch screen bindings [1] replace the private ti,swap-xy with touchscreen-swaped-x-y. And for the Openpandora we use touchscreen-size etc. to match the LCD screen size. [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +- arch/arm/boot/dts/omap3-pandora-common.dtsi | 17 + arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +- 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi index d0dd036..01dae66 100644 --- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi +++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi @@ -325,7 +325,7 @@ ti,y-max = /bits/ 16 <3600>; ti,x-plate-ohms = /bits/ 16 <80>; ti,pressure-max = /bits/ 16 <255>; - ti,swap-xy; + touchscreen-swapped-x-y; linux,wakeup; }; diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi index f672a04..9497cc6 100644 --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi @@ -696,10 +696,19 @@ pendown-gpio = <&gpio3 30 0>; vcc-supply = <&vaux4>; - ti,x-min = /bits/ 16 <0>; - ti,x-max = /bits/ 16 <8000>; - ti,y-min = /bits/ 16 <0>; - ti,y-max = /bits/ 16 <4800>; + touchscreen-size-x = <800>; + touchscreen-size-y = <480>; + touchscreen-max-pressure = <1000>; + touchscreen-fuzz-x = <16>; + touchscreen-fuzz-y = <16>; + touchscreen-fuzz-pressure = <10>; + touchscreen-inverted-x; + touchscreen-inverted-y; + + ti,x-min = /bits/ 16 <160>; + ti,x-max = /bits/ 16 <3900>; + ti,y-min = /bits/ 16 <220>; + ti,y-max = /bits/ 16 <3750>; ti,x-plate-ohms = /bits/ 16 <40>; ti,pressure-max = /bits/ 16 <255>; diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi index f4b1a61..c772b76 100644 --- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi +++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi @@ -65,7 +65,7 @@ ti,y-max = /bits/ 16 <4800>; ti,x-plate-ohms = /bits/ 16 <40>; ti,pressure-max = /bits/ 16 <255>; - ti,swap-xy; + touchscreen-swapped-x-y; linux,wakeup; }; }; -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does
this should reduce unnecessary input events. Signed-off-by: H. Nikolaus Schaller --- drivers/input/touchscreen/tsc2007.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c index e0c7173..1a8a79d 100644 --- a/drivers/input/touchscreen/tsc2007.c +++ b/drivers/input/touchscreen/tsc2007.c @@ -94,6 +94,7 @@ struct tsc2007 { wait_queue_head_t wait; boolstopped; + boolpendown; int (*get_pendown_state)(struct device *); void(*clear_penirq)(void); @@ -251,7 +252,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle) dev_dbg(&ts->client->dev, "shaped point(%4d,%4d), pressure (%4u)\n", tc.x, tc.y, rt); - input_report_key(input, BTN_TOUCH, 1); + if (!ts->pendown) { + input_report_key(input, BTN_TOUCH, 1); + ts->pendown = true; + } input_report_abs(input, ABS_X, tc.x); input_report_abs(input, ABS_Y, tc.y); input_report_abs(input, ABS_PRESSURE, rt); @@ -272,9 +276,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle) dev_dbg(&ts->client->dev, "UP\n"); - input_report_key(input, BTN_TOUCH, 0); - input_report_abs(input, ABS_PRESSURE, 0); - input_sync(input); + if (ts->pendown) { + input_report_key(input, BTN_TOUCH, 0); + input_report_abs(input, ABS_PRESSURE, 0); + input_sync(input); + + ts->pendown = false; + } if (ts->clear_penirq) ts->clear_penirq(); -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] drivers:input:ads7846(+tsc2046): fix spi module table
Fix module table so that the driver is loaded if compiled as module and requested by DT. Signed-off-by: H. Nikolaus Schaller --- drivers/input/touchscreen/ads7846.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index b9896fd..6bedbfa 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1563,6 +1563,17 @@ static int ads7846_remove(struct spi_device *spi) return 0; } +static const struct spi_device_id ads7846_idtable[] = { + { "tsc2046", 0 }, + { "ads7843", 0 }, + { "ads7845", 0 }, + { "ads7846", 0 }, + { "ads7873", 0 }, + { } +}; + +MODULE_DEVICE_TABLE(spi, ads7846_idtable); + static struct spi_driver ads7846_driver = { .driver = { .name = "ads7846", -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values
The tsc2007 chip not only has a resistive touch screen controller but also an external AUX adc imput which can be used for an ambient light sensor, battery voltage monitoring or any general purpose. Additionally it can measure the chip temperature. This driver provides an iio interface for these adc channels in addition to the raw x, y, z values and the estimated touch screen resistance. This can be used for debugging or special applications. Signed-off-by: H. Nikolaus Schaller --- drivers/input/touchscreen/Kconfig | 1 + drivers/input/touchscreen/tsc2007.c | 137 +++- 2 files changed, 136 insertions(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index deb14c1..b437ead 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -941,6 +941,7 @@ config TOUCHSCREEN_TSC2005 config TOUCHSCREEN_TSC2007 tristate "TSC2007 based touchscreens" depends on I2C + select IIO help Say Y here if you have a TSC2007 based touchscreen. diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c index 1a8a79d..4d3c995 100644 --- a/drivers/input/touchscreen/tsc2007.c +++ b/drivers/input/touchscreen/tsc2007.c @@ -30,6 +30,9 @@ #include #include #include +#include +#include +#include #define TSC2007_MEASURE_TEMP0 (0x0 << 4) #define TSC2007_MEASURE_AUX(0x2 << 4) @@ -61,6 +64,16 @@ #define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X) #define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN) +#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \ +{ \ + .datasheet_name = _name, \ + .type = _type, \ + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \ + BIT(_chan_info), \ + .indexed = 1, \ + .channel = _chan, \ +} + struct ts_event { u16 x; u16 y; @@ -69,9 +82,11 @@ struct ts_event { struct tsc2007 { struct input_dev*input; + struct iio_dev *indio; charphys[32]; struct i2c_client *client; + struct mutexmlock; u16 model; u16 x_plate_ohms; @@ -192,7 +207,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle) while (!ts->stopped && tsc2007_is_pen_down(ts)) { /* pen is down, continue with the measurement */ + + mutex_lock(&ts->mlock); tsc2007_read_values(ts, &tc); + mutex_unlock(&ts->mlock); rt = tsc2007_calculate_resistance(ts, &tc); @@ -340,6 +358,86 @@ static void tsc2007_close(struct input_dev *input_dev) tsc2007_stop(ts); } +static const struct iio_chan_spec tsc2007_iio_channel[] = { + TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */ + TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW), + TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW), +}; + +static int tsc2007_read_raw(struct iio_dev *indio_dev, + struct iio_chan_spec const *chan, int *val, int *val2, long mask) +{ + struct tsc2007 *tsc = iio_priv(indio_dev); + int adc_chan = chan->channel; + int ret = 0; + + if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel)) + return -EINVAL; + + if (mask != IIO_CHAN_INFO_RAW) + return -EINVAL; + + mutex_lock(&tsc->mlock); + + switch (chan->channel) { + case 0: + *val = tsc2007_xfer(tsc, READ_X); + break; + case 1: + *val = tsc2007_xfer(tsc, READ_Y); + break; + case 2: + *val = tsc2007_xfer(tsc, READ_Z1); + break; + case 3: + *val = tsc2007_xfer(tsc, READ_Z2); + break; + case 4: + *val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX)); + break; + case 5: { + struct ts_event tc; + + tc.x = tsc2007_xfer(tsc, READ_X); + tc.z1 = tsc2007_xfer(tsc, READ_Z1); + tc.z2 = tsc2007_xfer(tsc, READ_Z2); + *val = tsc2007_calculate_resistance(tsc, &tc); + break; + } + case 6: + *val = tsc2007_is_pen_down(tsc); + break; + case 7: + *val = tsc2007_xfer(tsc, + (ADC_ON_12BIT | TSC2007_MEASURE
[PATCH v2 6/8] drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping
By this patch we still recognise the old binding ti,swap-xy in parallel to the common binding touchscreen-swapped-x-y. This keeps compatibility to older (out-of-tree) device tree binaries. We do this in a separate patch so that it can be easily reverted in the future to retire the old API. A notice is printed to remind developers of using old API. We also fix the bindings name for all in-tree device tree sources in a separate patch. Signed-off-by: H. Nikolaus Schaller --- drivers/input/touchscreen/ads7846.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 4525f00..b9896fd 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1259,7 +1259,11 @@ static const struct ads7846_platform_data *ads7846_probe_dt(struct device *dev) of_property_read_u16(node, "ti,vref-mv", &pdata->vref_mv); pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on"); - pdata->swap_xy = of_property_read_bool(node, "touchscreen-swapped-x-y"); + pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy"); + if (pdata->swap_xy) + dev_notice(dev, "please update device tree to use touchscreen-swapped-x-y"); + pdata->swap_xy |= of_property_read_bool(node, + "touchscreen-swapped-x-y"); of_property_read_u16(node, "ti,settle-delay-usec", &pdata->settle_delay_usecs); -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] DT:omap3+tsc2007: use new common touchscreen bindings
Tested on: GTA04A4 (Letux2804), Letux3704, Letux7004 Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap3-gta04.dtsi | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index 7166d88..95fed8e 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -357,10 +357,24 @@ tsc2007@48 { compatible = "ti,tsc2007"; reg = <0x48>; + pinctrl-names = "default"; + pinctrl-0 = <&penirq_pins>; interrupt-parent = <&gpio6>; interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */ - gpios = <&gpio6 0 GPIO_ACTIVE_LOW>; - ti,x-plate-ohms = <600>; + gpios = <&gpio6 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */ + touchscreen-size-x = <480>; + touchscreen-size-y = <640>; + touchscreen-max-pressure = <1000>; + touchscreen-fuzz-x = <2>; + touchscreen-fuzz-y = <2>; + touchscreen-fuzz-pressure = <10>; + touchscreen-inverted-y; + ti,min-x = <0x100>; + ti,max-x = <0xf00>; + ti,min-y = <0x100>; + ti,max-y = <0xf00>; + ti,max-rt = <4096>; + ti,x-plate-ohms = <550>; }; }; -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
commit b98abe52fa8e ("Input: add common DT binding for touchscreens") introduced common DT bindings for touchscreens [1] and a helper function to parse the DT. This has been integrated and interpretation of the inversion (flipping) properties for the x and y axis has been added to accommodate any orientation of the touch in relation to the LCD. By scaling the min/max ADC values to the screen size it is now possible to pre-calibrate the touch so that is (almost) exactly matches the LCD it is glued onto. This allows to well enough operate the touch before a user space calibration can improve the precision. calculate_pressure has been renamed to calculate_resistance because that is what it is doing. [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Signed-off-by: H. Nikolaus Schaller --- .../bindings/input/touchscreen/tsc2007.txt | 20 +-- drivers/input/touchscreen/tsc2007.c| 135 + include/linux/i2c/tsc2007.h| 8 ++ 3 files changed, 135 insertions(+), 28 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt index ec365e1..6e9fd55 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt @@ -6,6 +6,7 @@ Required properties: - ti,x-plate-ohms: X-plate resistance in ohms. Optional properties: +- generic touch screen properties: see touchscreen binding [2]. - gpios: the interrupt gpio the chip is connected to (trough the penirq pin). The penirq pin goes to low when the panel is touched. (see GPIO binding[1] for more details). @@ -13,17 +14,20 @@ Optional properties: (see interrupt binding[0]). - interrupts: (gpio) interrupt to which the chip is connected (see interrupt binding[0]). -- ti,max-rt: maximum pressure. -- ti,fuzzx: specifies the absolute input fuzz x value. - If set, it will permit noise in the data up to +- the value given to the fuzz - parameter, that is used to filter noise from the event stream. -- ti,fuzzy: specifies the absolute input fuzz y value. -- ti,fuzzz: specifies the absolute input fuzz z value. +- ti,max-rt: maximum pressure resistance above which samples are ignored + (default: 4095). +- ti,report-resistance: report resistance (no pressure = max_rt) instead + of pressure (no pressure = 0). +- ti,min-x: minimum value reported by X axis ADC (default 0). +- ti,max-x: maximum value reported by X axis ADC (default 4095). +- ti,min-y: minimum value reported by Y axis ADC (default 0). +- ti,max-y: maximum value reported by Y axis ADC (default 4095). - ti,poll-period: how much time to wait (in milliseconds) before reading again the - values from the tsc2007. + values from the tsc2007 (default 1). [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt [1]: Documentation/devicetree/bindings/gpio/gpio.txt +[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Example: &i2c1 { @@ -35,6 +39,8 @@ Example: interrupts = <0x0 0x8>; gpios = <&gpio4 0 0>; ti,x-plate-ohms = <180>; + touchscreen-size-x = <640>; + touchscreen-size-y = <480>; }; /* ... */ diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c index 5d0cd51..e0c7173 100644 --- a/drivers/input/touchscreen/tsc2007.c +++ b/drivers/input/touchscreen/tsc2007.c @@ -29,6 +29,7 @@ #include #include #include +#include #define TSC2007_MEASURE_TEMP0 (0x0 << 4) #define TSC2007_MEASURE_AUX(0x2 << 4) @@ -74,6 +75,14 @@ struct tsc2007 { u16 model; u16 x_plate_ohms; + boolswap_xy; + boolinvert_x; + boolinvert_y; + boolreport_resistance; + u16 min_x; + u16 min_y; + u16 max_x; + u16 max_y; u16 max_rt; unsigned long poll_period; /* in jiffies */ int fuzzx; @@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc) tsc2007_xfer(tsc, PWRDOWN); } -static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc) +static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc, + struct ts_event *tc) { u32 rt = 0; @@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle) struct ts_event tc; u32 rt; + dev_dbg(&ts->client->dev, "soft irq %d\n", irq); while (!ts->stopped && tsc2007_is_pen_down(ts))
[PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping
commit b98abe52fa8e ("Input: add common DT binding for touchscreens") introduced common DT bindings for touchscreens [1] and a helper function to parse the DT. This has been integrated and interpretation of the inversion (flipping) properties for the x and y axis has been added to accommodate any orientation of the touch in relation to the LCD. By scaling the min/max ADC values to the screen size it is now possible to pre-calibrate the touch so that is (almost) exactly matches the LCD it is glued onto. This allows to well enough operate the touch before a user space calibration can improve the precision. [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Signed-off-by: H. Nikolaus Schaller --- .../devicetree/bindings/input/ads7846.txt | 8 ++- drivers/input/touchscreen/ads7846.c| 72 -- 2 files changed, 74 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt index df8b127..ae56355 100644 --- a/Documentation/devicetree/bindings/input/ads7846.txt +++ b/Documentation/devicetree/bindings/input/ads7846.txt @@ -26,12 +26,17 @@ Additional required properties: Optional properties: +You can optionally specify any of the touchscreen parameters described in + + Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt + +This allows to scale, invert or swap coordinates and define the fuzz factors. + ti,vref-delay-usecs vref supply delay in usecs, 0 for external vref (u16). ti,vref-mv The VREF voltage, in millivolts (u16). ti,keep-vref-on set to keep vref on for differential measurements as well - ti,swap-xy swap x and y axis ti,settle-delay-usecSettling time of the analog signals; a function of Vcc and the capacitance on the X/Y drivers. If set to non-zero, @@ -79,6 +84,7 @@ Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: pendown-gpio = <&gpio1 8 0>; vcc-supply = <®_vcc3>; + touchscreen-swapped-x-y; ti,x-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <8000>; ti,y-min = /bits/ 16 <0>; diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 04edc8f..4525f00 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -34,6 +34,7 @@ #include #include #include +#include #include /* @@ -109,8 +110,14 @@ struct ads7846 { u16 vref_delay_usecs; u16 x_plate_ohms; u16 pressure_max; + u16 x_min; + u16 x_max; + u16 y_min; + u16 y_max; boolswap_xy; + boolinvert_x; + boolinvert_y; booluse_internal; struct ads7846_packet *packet; @@ -828,9 +835,48 @@ static void ads7846_report_state(struct ads7846 *ts) if (Rt) { struct input_dev *input = ts->input; + dev_dbg(&ts->spi->dev, + "Raw point(%4d,%4d), pressure (%4u)\n", + x, y, Rt); + /* clamp to expected ADC range */ + if (x < ts->x_min) + x = ts->x_min; + if (x > ts->x_max) + x = ts->x_max; + if (y < ts->y_min) + y = ts->y_min; + if (y > ts->y_max) + y = ts->y_max; + + dev_dbg(&ts->spi->dev, + "Clamped point(%4d,%4d), pressure (%4u)\n", + x, y, Rt); + + /* flip */ + if (ts->invert_x) + x = (ts->x_max - x) + ts->x_min; + if (ts->invert_y) + y = (ts->y_max - y) + ts->y_min; + + dev_dbg(&ts->spi->dev, + "Flipped point(%4d,%4d), pressure (%4u)\n", + x, y, Rt); + + /* scale to desired output range */ + x = (input->absinfo[ABS_X].maximum * (x - ts->x_min)) + / (ts->x_max - ts->x_min); + y = (input->absinfo[ABS_Y].maximum * (y - ts->y_min)) + / (ts->y_max - ts->y_min); + + dev_dbg(&ts->spi->dev, + "Scaled point(%4d,%4d), pressure (%4u)\n", + x, y, Rt); + +
Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir
On Friday 13 November 2015 17:13:41 Mauro Carvalho Chehab wrote: > Em Wed, 11 Nov 2015 21:26:31 +0100 > Arnd Bergmann escreveu: > > include/media/{ => drv-intf}/cx2341x.h | 0 > include/media/{ => drv-intf}/cx25840.h | 0 > include/media/{ => drv-intf}/exynos-fimc.h | 0 > include/media/{ => drv-intf}/msp3400.h | 0 > include/media/{ => drv-intf}/s3c_camif.h | 0 > include/media/{ => drv-intf}/saa7146.h | 0 > include/media/{ => drv-intf}/saa7146_vv.h| 2 +- > include/media/{ => drv-intf}/sh_mobile_ceu.h | 0 > include/media/{ => drv-intf}/sh_mobile_csi2.h| 0 > include/media/{ => drv-intf}/sh_vou.h| 0 > include/media/{ => drv-intf}/si476x.h| 0 > include/media/{ => drv-intf}/soc_mediabus.h | 0 > include/media/{ => drv-intf}/tea575x.h | 0 > include/media/i2c/tw9910.h | 2 +- > include/media/{ => platform_data}/gpio-ir-recv.h | 0 > include/media/{ => platform_data}/ir-rx51.h | 0 > include/media/{ => platform_data}/mmp-camera.h | 0 > include/media/{ => platform_data}/omap1_camera.h | 0 > include/media/{ => platform_data}/omap4iss.h | 0 > include/media/{ => platform_data}/s5p_hdmi.h | 0 > include/media/{ => platform_data}/si4713.h | 0 > include/media/{ => platform_data}/sii9234.h | 0 > include/media/{ => platform_data}/smiapp.h | 0 > include/media/{ => platform_data}/soc_camera.h | 0 > include/media/{ => platform_data}/soc_camera_platform.h | 2 +- > include/media/{ => platform_data}/timb_radio.h | 0 > include/media/{ => platform_data}/timb_video.h | 0 > sound/pci/es1968.c | 2 +- > sound/pci/fm801.c| 2 +- > 155 files changed, 158 insertions(+), 158 deletions(-) As Geert said, include/linux/platform_data/media/ would be nicer for consistency with other subsystems. > diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > index ede2bdbb5dd5..44ba1f28bb34 100644 > --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > @@ -33,7 +33,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include This looks like a mistake: the header contains the string 'platform_data', but it is not actually a platform data header file in the sense that it defines the interface between platform and driver. Maybe soc_camera.h is important enough to still leave it as a core file in the existing location? Or possibly a separate directory for media/soc_camera/*.h > @@ -24,7 +24,7 @@ > #include > #include > #include > -#include > +#include > #include > > #include "cx25840-core.h" For this case, I think the original patch to move it into include/media/i2c was more logical as it mirrors the file structure. I was mainly talking about the platform_data being different from the rest. 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: [PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping
Hi, On Fri, Nov 13, 2015 at 09:35:56PM +0100, H. Nikolaus Schaller wrote: > commit b98abe52fa8e ("Input: add common DT binding for touchscreens") > introduced common DT bindings for touchscreens [1] and a helper function to > parse the DT. > > This has been integrated and interpretation of the inversion (flipping) > properties for the x and y axis has been added to accommodate any > orientation of the touch in relation to the LCD. > > By scaling the min/max ADC values to the screen size it is now possible to > pre-calibrate the touch so that is (almost) exactly matches the LCD it is > glued onto. This allows to well enough operate the touch before a user > space calibration can improve the precision. > > [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > > Signed-off-by: H. Nikolaus Schaller > --- > .../devicetree/bindings/input/ads7846.txt | 8 ++- > drivers/input/touchscreen/ads7846.c| 72 > -- > 2 files changed, 74 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/input/ads7846.txt > b/Documentation/devicetree/bindings/input/ads7846.txt > index df8b127..ae56355 100644 > --- a/Documentation/devicetree/bindings/input/ads7846.txt > +++ b/Documentation/devicetree/bindings/input/ads7846.txt > @@ -26,12 +26,17 @@ Additional required properties: > > Optional properties: > > +You can optionally specify any of the touchscreen parameters described in > + > + Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > + > +This allows to scale, invert or swap coordinates and define the fuzz factors. > + > ti,vref-delay-usecs vref supply delay in usecs, 0 for > external vref (u16). > ti,vref-mv The VREF voltage, in millivolts (u16). > ti,keep-vref-on set to keep vref on for differential > measurements as well > - ti,swap-xy swap x and y axis I guess this should be: ti,swap-xy: deprecated name for touchscreen-swapped-x-y -- Sebastian signature.asc Description: PGP signature
Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir
Em Fri, 13 Nov 2015 22:31:15 +0100 Arnd Bergmann escreveu: > On Friday 13 November 2015 17:13:41 Mauro Carvalho Chehab wrote: > > Em Wed, 11 Nov 2015 21:26:31 +0100 > > Arnd Bergmann escreveu: > > > > > include/media/{ => drv-intf}/cx2341x.h | 0 > > include/media/{ => drv-intf}/cx25840.h | 0 > > include/media/{ => drv-intf}/exynos-fimc.h | 0 > > include/media/{ => drv-intf}/msp3400.h | 0 > > include/media/{ => drv-intf}/s3c_camif.h | 0 > > include/media/{ => drv-intf}/saa7146.h | 0 > > include/media/{ => drv-intf}/saa7146_vv.h| 2 +- > > include/media/{ => drv-intf}/sh_mobile_ceu.h | 0 > > include/media/{ => drv-intf}/sh_mobile_csi2.h| 0 > > include/media/{ => drv-intf}/sh_vou.h| 0 > > include/media/{ => drv-intf}/si476x.h| 0 > > include/media/{ => drv-intf}/soc_mediabus.h | 0 > > include/media/{ => drv-intf}/tea575x.h | 0 > > include/media/i2c/tw9910.h | 2 +- > > include/media/{ => platform_data}/gpio-ir-recv.h | 0 > > include/media/{ => platform_data}/ir-rx51.h | 0 > > include/media/{ => platform_data}/mmp-camera.h | 0 > > include/media/{ => platform_data}/omap1_camera.h | 0 > > include/media/{ => platform_data}/omap4iss.h | 0 > > include/media/{ => platform_data}/s5p_hdmi.h | 0 > > include/media/{ => platform_data}/si4713.h | 0 > > include/media/{ => platform_data}/sii9234.h | 0 > > include/media/{ => platform_data}/smiapp.h | 0 > > include/media/{ => platform_data}/soc_camera.h | 0 > > include/media/{ => platform_data}/soc_camera_platform.h | 2 +- > > include/media/{ => platform_data}/timb_radio.h | 0 > > include/media/{ => platform_data}/timb_video.h | 0 > > sound/pci/es1968.c | 2 +- > > sound/pci/fm801.c| 2 +- > > 155 files changed, 158 insertions(+), 158 deletions(-) > > As Geert said, include/linux/platform_data/media/ would be nicer for > consistency with other subsystems. OK! I have a new series of patches almost ready. I'll be sending it tomorrow, after addressing your concerns. > > > diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > > b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > > index ede2bdbb5dd5..44ba1f28bb34 100644 > > --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > > +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c > > @@ -33,7 +33,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > #include > > #include > > #include > > This looks like a mistake: the header contains the string 'platform_data', > but it is not actually a platform data header file in the sense > that it defines the interface between platform and driver. > > Maybe soc_camera.h is important enough to still leave it as a core > file in the existing location? Or possibly a separate directory for > media/soc_camera/*.h Ok, I'll fix it. > > > @@ -24,7 +24,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > #include > > > > #include "cx25840-core.h" > > For this case, I think the original patch to move it into include/media/i2c > was more logical as it mirrors the file structure. I was mainly talking > about the platform_data being different from the rest. cx25840 is not (always) an I2C. On most devices, this is actually an IP block inside the bridge chipset. That's why I didn't include it on patch 1/1. There's one thing to notice about that, though: while most of the header is describing the driver interface, it does contain one platform_data in the end: /* pvr150_workaround activates a workaround for a hardware bug that is present in Hauppauge PVR-150 (and possibly PVR-500) cards that have certain NTSC tuners (tveeprom tuner model numbers 85, 99 and 112). The audio autodetect fails on some channels for these models and the workaround is to select the audio standard explicitly. Many thanks to Hauppauge for providing this information. This platform data only needs to be supplied by the ivtv driver. */ struct cx25840_platform_data { int pvr150_workaround; }; While we might split it, I guess it is not worth, specially since I don't think we'll see any new driver using it. Also, this is actually a hack used only by the ivtv driver. Regards, Mauro -- 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