Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

[Tomi Valkeinen]

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

[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 +
> 
> 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: [BISECTED] v4.3-rc5: OMAP1 boot hang

[Jon Hunter]

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

[Neil Armstrong]

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

[PATCH v3] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

[Andrew F. Davis]

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 @@
 _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 */
+ 

Re: [PATCH] clocksource: arm_global_timer: fix suspend resume

[Grygorii Strashko]

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

[Grygorii Strashko]

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

[PATCH v2 0/4] arm: omap2+: complete dm816x hwmod and clkdev

[Neil Armstrong]

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

[Neil Armstrong]

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= _hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dm81xx_spinbox_hwmod_class = {
+   .name = "spinbox",
+   .sysc = _spinbox_sysc,
+};
+
+static struct omap_hwmod dm81xx_spinbox_hwmod = {
+   .name   = "spinbox",
+   .clkdm_name = "alwon_l3s_clkdm",
+   .class  = _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 = _l4_ls_hwmod,
+   .slave  = _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 = {
_l4_ls__timer7,
_l4_ls__mcspi1,
_l4_ls__mailbox,
+   _l4_ls__spinbox,
_l4_hs__emac0,
_emac0__mdio,
_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

[Neil Armstrong]

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 = _pdata,
},
+   {
+   .compatible = "ti,dm816-timer",
+   .data = _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

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

[H. Nikolaus Schaller]

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

Re: Minimal support for dm814x

[Tony Lindgren]

* 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

[PATCH v2 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

[Neil Armstrong]

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

[Neil Armstrong]

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] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

[Tony Lindgren]

* 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=144665429032014=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

Re: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[santosh shilimkar]

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 v3 1/5] spi: introduce mmap read support for spi flash devices

[Cyrille Pitchen]

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:

Re: [PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

[Neil Armstrong]

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  = _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  = _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  = _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 RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank

[Jyri Sarha]

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

[Jyri Sarha]

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 

[PATCH RFC v2 2/2] drm/atomic: Disable planes on blanked CRTC and enable on unblank

[Jyri Sarha]

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, >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] clocksource: arm_global_timer: fix suspend resume

[Grygorii Strashko]

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

Re: [PATCH] clocksource: arm_global_timer: fix suspend resume

[Felipe Balbi]

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] clocksource: arm_global_timer: fix suspend resume

[Felipe Balbi]

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

[Grygorii Strashko]

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 

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Mauro Carvalho Chehab]

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

Re: [PATCH] clocksource: arm_global_timer: fix suspend resume

[Grygorii Strashko]

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

[Felipe Balbi]

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

[Grygorii Strashko]

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

[Grygorii Strashko]

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 

Re: [PATCH] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Grygorii Strashko]

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

[Felipe Balbi]

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

[PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

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 = < 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(>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(>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(>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(>spi->dev,
+   "Scaled point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   

[PATCH v2 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

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

[H. Nikolaus Schaller]

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(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -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(>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, );
+   break;
+   }
+   case 6:
+   *val = tsc2007_is_pen_down(tsc);
+   break;
+   case 7:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | 

[PATCH v2 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

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(>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(>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 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

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 = < 30 0>;
vcc-supply = <>;
 
-   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 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 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(>client->dev, "soft irq %d\n", irq);
while (!ts->stopped && 

Re: [PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[Sebastian Reichel]

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

[Mauro Carvalho Chehab]

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

[PATCH v2 4/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

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 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 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

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Arnd Bergmann]

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 2/2] [media] include/media: move platform driver headers to a separate dir

[Geert Uytterhoeven]

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)

[H. Nikolaus Schaller]

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

Re: [PATCH 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Igor Grinberg]

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

[...]

> +_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 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

[H. Nikolaus Schaller]

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

Re: Minimal support for dm814x

[Matthijs van Duin]

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

[PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

[H. Nikolaus Schaller]

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

[H. Nikolaus Schaller]

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 3.16.y-ckt 08/94] clk: ti: fix dual-registration of uart4_ick

[Luis Henriques]

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: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

[Mike Looijmans]

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

[Tony Lindgren]

* 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  = _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  = _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  = _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

[Tony Lindgren]

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

Re: Minimal support for dm814x

[Tony Lindgren]

* 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: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[Grygorii Strashko]

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: [PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[Mason]

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: am35xx memory management issues

[Markku Ahvenjärvi]

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

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

[H. Nikolaus Schaller]

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