Re: [PATCH] ARM: OMAP2+: Fixed inverted OMAP_OFFOUT_EN

2015-10-09 Thread Ben Tucker 
On Fri, Oct 09, 2015 at 09:16:28AM -0700, Tony Lindgren wrote:
> * Ben Tucker <benjam...@bsquare.com> [151009 03:20]:
> > On Thu, Oct 08, 2015 at 11:40:06PM -0700, Tony Lindgren wrote:
> > > * Ben Tucker <benjam...@bsquare.com> [151008 06:09]:
> > > > The OFFOUTENABLE bit of the omap PADCONF registers is active low.
> > > > The mux code assumed that it was active high and this patch fixes this
> > > > problem.
> > > > 
> > > > Tested on an AM37x device.
> > > 
> > > Hmm what are the test cases you're using to validate this so
> > > I can try to reproduce?
> > 
> > I have a GSM modem connected to the omap via uart. The modem will only
> > enter a low power sleep mode when is RXD is pulled low, so by using the
> > OFFOUTENABLE signal I am able to automatically activate low power in the
> > modem when suspending to off.
> > I have a test setup which allows me to measure the combined power used by 
> > the
> > omap+modem and I can see a saving of around 45mA in suspend with this
> > patch. This is consistent with the literature on the modem device.
> 
> OK that pin may be then glitchy because of 1.158 :)
> 
> > Our custom hardware is based on omap3beagle and not available to you. My
> > thoughts as to reproducing this would be to use a beagle and setup so
> > that it is able to suspend right down to CORE Off. Then set up the pin
> > muxing for the UART TX signal to output low in off mode. It should be
> > possible to measure the level on the TX signal in suspend.
> 
> Hmm well UART will be powered off, but I can use any GPIO pin for
> that.
> 
> > I appreciate that this is a lot of work. I would be happy to do this
> > but it will take some time. Would you be able to help get things up and
> > running?
> > 
> > > 
> > > AFAIK because of erratum 1.158 for GPIO pins needing to be
> > > muxed temporarly for input + pull + safe mode for off mode,
> > > so I'm wondering in which cases the OFFOUTENABLE can be used.
> > 
> > In my scenario the pin is muxed to the uart function (TxD), but I am
> > interested in this issue as well. First off, I want to read the erratum
> > 1.158 you speak of.
> > I see that the errata document for OMAP35xx has:
> > Advisory 3.1.1.158 Pull-up not maintained on pin corresponding to
> > GPIO_28/29 during padconf restore
> > Is this what you are referring to?
> 
> Hmm I believe it has some different TI external number. Maybe search
> for 1.158 and Tero Kristo and you come up with an older patch
> implementing the workaround. I have not seen the errata description
> either.
Yes, I found that patch or a variant of it before. I think it most
closely matches the TI advisories:

- sprz278f.pdf (omap35xx)
Advisory 3.1.1.160 GPIO Pad Glitch/Spike Upon Wake-Up From System OFF Mode

- sprz318f.pdf (am37x)
Advisory 1.45 GPIO Pad Spurious Transition (Glitch/Spike) During Wake Up 
Entering or Exiting System OFF Mode

>From my understanding both of these advisories include the work around
to switch to off mode input and pull up or down to mimic the gpio output level
(which is fine so long as the pin is lightly loaded). Looks like this is
what the patch does.

> 
> > > I have a patch in works for 1.158 using gpio-ranges, and the
> > > test case I'm using is the reset of WLAN that happens in off
> > > mode as the enable GPIO glitches when returning from off mode.
> > 
> > I will now go away and have a look through all the places that we use
> > GPIO and asses the impact of glitches on the signals in our design.
> > Thankyou.
> 
> Yup, I've verified it happens on a scope earlier. If you have
> external pulls you may not experience this issue.
> 
> > > Also.. I'm wondring why this has not been caught earlier?
> > > Maybe because 1.158 is needed on omap3?
> > 
> > Maybe. Also the use of OFFOUTENABLE in combination with peripherals
> > other than GPIO, I guess, is pretty rare.
> 
> Right, I guess it has not been used :)
> 
> Hmm so what's the use case for PIN_OFF_INPUT* then?
On the face of it if the peripheral behind the pin is powered off which
will be the case when we have powered the domains off, then it cannot
process any input values.

However there are two uses for input off mode I can think of:

1- the pin is not connected, in which case you want to make it an input
so that there is no driver enabled for it. I am guessing this would save
a little power even though the pin has no load. Note an internal pull
resister should be enabled in this case to avoid the pin acting like a
aerial and switching internal logic, which again woul

[PATCH] ARM: OMAP2+: Fixed inverted OMAP_OFFOUT_EN

2015-10-08 Thread Ben Tucker 
The OFFOUTENABLE bit of the omap PADCONF registers is active low.
The mux code assumed that it was active high and this patch fixes this
problem.

Tested on an AM37x device.

Signed-off-by: Ben Tucker <benjam...@bsquare.com>
---
 arch/arm/mach-omap2/mux.c |  2 +-
 arch/arm/mach-omap2/mux.h | 13 +++--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6..427a7f88 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -523,7 +523,7 @@ static inline void omap_mux_decode(struct seq_file *s, u16 
val)
 
OMAP_MUX_TEST_FLAG(val, OMAP_PIN_OFF_WAKEUPENABLE);
if (val & OMAP_OFF_EN) {
-   if (!(val & OMAP_OFFOUT_EN)) {
+   if (val & OMAP_OFFOUT_EN) {
if (!(val & OMAP_OFF_PULL_UP)) {
OMAP_MUX_TEST_FLAG(val,
OMAP_PIN_OFF_INPUT_PULLDOWN);
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index d121fb6..9a5fd76 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -29,7 +29,7 @@
 /* omap3/4/5 specific mux bit defines */
 #define OMAP_INPUT_EN  (1 << 8)
 #define OMAP_OFF_EN(1 << 9)
-#define OMAP_OFFOUT_EN (1 << 10)
+#define OMAP_OFFOUT_EN (1 << 10) /* 1 for input, 0 for output 
*/
 #define OMAP_OFFOUT_VAL(1 << 11)
 #define OMAP_OFF_PULL_EN   (1 << 12)
 #define OMAP_OFF_PULL_UP   (1 << 13)
@@ -45,12 +45,13 @@
 
 /* Off mode states */
 #define OMAP_PIN_OFF_NONE  0
-#define OMAP_PIN_OFF_OUTPUT_HIGH   (OMAP_OFF_EN | OMAP_OFFOUT_EN \
-   | OMAP_OFFOUT_VAL)
-#define OMAP_PIN_OFF_OUTPUT_LOW(OMAP_OFF_EN | OMAP_OFFOUT_EN)
-#define OMAP_PIN_OFF_INPUT_PULLUP  (OMAP_OFF_EN | OMAP_OFF_PULL_EN \
+#define OMAP_PIN_OFF_OUTPUT_HIGH   (OMAP_OFF_EN | OMAP_OFFOUT_VAL)
+#define OMAP_PIN_OFF_OUTPUT_LOW(OMAP_OFF_EN)
+#define OMAP_PIN_OFF_INPUT_PULLUP  (OMAP_OFF_EN | OMAP_OFFOUT_EN \
+   | OMAP_OFF_PULL_EN \
| OMAP_OFF_PULL_UP)
-#define OMAP_PIN_OFF_INPUT_PULLDOWN(OMAP_OFF_EN | OMAP_OFF_PULL_EN)
+#define OMAP_PIN_OFF_INPUT_PULLDOWN(OMAP_OFF_EN | OMAP_OFFOUT_EN \
+   | OMAP_OFF_PULL_EN)
 #define OMAP_PIN_OFF_WAKEUPENABLE  OMAP_WAKEUP_EN
 
 #define OMAP_MODE_GPIO(partition, x)   (((x) & OMAP_MUX_MODE7) == \
-- 
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: OMAP2,3: DSS2: Report -EBUSY when to many registered isr

2011-03-04 Thread Ben Tucker 
Thankyou Tomi. Please go ahead and fix the bug yourself.

Ben


 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
 Sent: 21 February 2011 09:28
 To: Ben Tucker
 Cc: linux-omap@vger.kernel.org; Ben Tucker
 Subject: Re: OMAP2,3: DSS2: Report -EBUSY when to many registered isr

 Hi,

 On Fri, 2011-01-21 at 04:53 +, Ben Tucker wrote:
  From: Ben Tucker btuc...@mpc-data.co.uk
 
  This patch fixes a problem with map_dispc_register_isr() where it
  fails to return -EBUSY if it has no more space for registrations.

 Looks correct, but a couple of things:
 - Missing signed-off
 - Indentation is wrong
 - Don't use { } when there's just one line in the if block

 Please fix those, or alternatively I can fix the bug myself and add you
 as reported-by.

  Tomi


 
  ---
  drivers/video/omap2/dss/dispc.c |4 
   1 files changed, 4 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/video/omap2/dss/dispc.c
 b/drivers/video/omap2/dss/dispc.c
  index e0e8275..f566177 100644
  --- a/drivers/video/omap2/dss/dispc.c
  +++ b/drivers/video/omap2/dss/dispc.c
  @@ -2579,6 +2579,10 @@ int omap_dispc_register_isr(omap_dispc_isr_t
 isr, void *arg, u32 mask)
  break;
  }
 
  +if (ret) {
  +goto err;
  +}
  +
  _omap_dispc_set_irqs();
 
  spin_unlock_irqrestore(dispc.irq_lock, flags);

--
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: OMAP DSS Enable clocks in dss_setup_partial_planes

2011-01-12 Thread Ben Tucker 
 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: 12 January 2011 09:14
 To: ext Ben Tucker
 Cc: linux-omap@vger.kernel.org
 Subject: Re: OMAP DSS Enable clocks in dss_setup_partial_planes

 Hi,

 On Tue, 2011-01-11 at 17:41 +, ext Ben Tucker wrote:
  From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00
 2001
  From: Ben Tucker btuc...@mpc-data.co.uk
  Date: Thu, 13 Jan 2011 12:56:45 +
  Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
   Enable the interface clocks while calling
 configure_dispc().

 This description doesn't really tell anything which isn't selfevident
 from the code below. Please check
 http://who-t.blogspot.com/2009/12/on-commit-messages.html

 But I presume this is about RFBI. If so, correct place to enable the
 clocks would be in rfbi.c.

  Tomi


Apologies for the commit message. Updated patch below.

Are you sure the code to enable clocks should be placed in rfbi.c? The DSI
code (dsi.c) uses dss_setup_partial_planes() in the same way as rfbi.c and
there is no clock enable code there. Also omap_dss_mgr_apply() within
manager.c enables clocks for the configure_dispc() call.

Ben


From fac7afefc4f80c3045ce73bb34e24a037ed26edc Mon Sep 17 00:00:00 2001
From: Ben Tucker btuc...@mpc-data.co.uk
Date: Sat, 15 Jan 2011 07:18:49 +
Subject: [PATCH] OMAP2,3: DSS2: Enable clocks in dss_setup_partial_planes

Fix a deadly bus halt when using RFBI or DSI interfaced panels
due to access to the OMAP DSS subsystem while interface and
peripheral clocks are disabled.
Resolved by enabling the clocks while calling the
configure_dispc() in dss_setup_partial_planes().
---
 drivers/video/omap2/dss/manager.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 545e9b9..cb90dac 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
mc-w = w;
mc-h = h;

+   dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
configure_dispc();
+   dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);

mc-do_manual_update = false;

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

OMAP DSS Enable clocks in dss_setup_partial_planes

2011-01-11 Thread Ben Tucker 
From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001
From: Ben Tucker btuc...@mpc-data.co.uk
Date: Thu, 13 Jan 2011 12:56:45 +
Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes
 Enable the interface clocks while calling
 configure_dispc().

---
 drivers/video/omap2/dss/manager.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 545e9b9..cb90dac 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device
*dssdev,
mc-w = w;
mc-h = h;

+   dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
configure_dispc();
+   dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);

mc-do_manual_update = false;

--
1.7.3.2
--
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: RFBI worked example

2011-01-07 Thread Ben Tucker 
With further experimentation it appears that I can call the
omap_rfbi_update() from the call back, but as the callback is in interrupt
context this could be dangerous. I would love to see an example of this
elsewhere.

static void framedone_callback(void *data)
{
int r;
u16 dw, dh;
struct omap_dss_device *dssdev = (struct omap_dss_device *)data;

/* Start the next update, triggered on the external H/VSync signals */
dssdev-driver-get_resolution(dssdev, dw, dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r  0)
printk(omap_rfbi_update FAILED);
}

static int generic_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
u16 dw, dh;

r = omapdss_rfbi_display_enable(dssdev);
if (r  0)
goto err0;

/* Setup external HSYNC/VSYNC triggering */
r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
   400, /* HSYNS pulse 4uS */
   10,  /* VSYNC pulse 1ms */
   0, 0,   /* H/VSYNC not inverted */
   0);
if (r  0)
goto err1;

/* Enable external triggering */
r = omap_rfbi_enable_te(1, 0);
if (r  0)
goto err1;

#if 0
/* At a guess I do not think we need to do the prepare_update
 * if we are updating the whole area
 */
r = omap_rfbi_prepare_update(dssdev, ???);
if (r  0)
goto err1;
#endif

/* Start the first update, triggered on the external H/VSync siganls.
 * The callback (FRAMEDONE interrupt context) will re-arm this
 * update once more.
 */
dssdev-driver-get_resolution(dssdev, dw, dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r  0)
goto err1;


if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
if (r)
goto err1;
}

return 0;
err1:
omap_rfbi_enable_te(0, 0);
omapdss_dpi_display_disable(dssdev);
err0:
return r;
}




-Original Message-
From: Ben Tucker [mailto:btuc...@mpcdata.com]
Sent: 06 January 2011 15:32
To: 'linux-omap@vger.kernel.org'
Cc: 'tomi.valkei...@nokia.com'
Subject: RFBI worked example



Hi,

I am trying to setup an OMAP3530 based system for RFBI video output using
external triggering. Looking at the omap dss2 source code (and also
searching around) I cannot find any worked example of how to use the rfbi
driver. I know that RFBI has worked in the past for a Nokia N800 device.
Can you dig out any source code that shows how to use the RFBI driver?
In particular I need to see how the omap_rfbi_prepare_update() and
omap_rfbi_update() calls operate with their callback. I am thinking that I
should simply call omap_rfbi_update() in a thread and wait for the
completion call back after each call. I want to confirm that this is the
correct way to run the driver.

Thanks,
Ben



Ben Tucker
Senior Software Engineer
MPC Data Limited
e-mail: btuc...@mpc-data.co.uk  web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600  fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710660

MPC Data Limited is a company registered in England and Wales with company
number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14
7FJ
VAT no: 850625238

The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the addressee.
Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the original
message. When
addressed to our clients any opinions or advice contained in this email is
subject to
the terms and conditions expressed in the governing contract.
--
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: RFBI worked example

2011-01-07 Thread Ben Tucker 
 -Original Message-
 From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
 Sent: 07 January 2011 15:14
 To: ext Ben Tucker
 Cc: linux-omap@vger.kernel.org
 Subject: RE: RFBI worked example

 On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote:
  With further experimentation it appears that I can call the
  omap_rfbi_update() from the call back, but as the callback is in
 interrupt
  context this could be dangerous. I would love to see an example of
 this
  elsewhere.

 Did you get it working enough to get an image on the panel?

The panel in this case is under development so (it's actually an FPGA) so we
have some way to go before we have an image.


 It's been long since I've touched the rfbi code, and I honestly don't
 know the state of it, but basically it should work similarly as DSI
 command mode:

It appears to be working. As a test I tried using internal triggering with
my panel code (below). Pixel data appears to flow out of the port (the
RFBI_PIXEL_CNT register is decrementing).


 The panel driver issues an update when the user space has requested it
 via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered
 automatically.

OK, that helps my understanding.


 If you really want to update the display automatically (which you
 shouldn't, as the point with panels with their own framebuffer is to
 update only when necessary), you can do it either directly as you do,
 or
 via workqueue or thread.

The primary reason for using RFBI in this design is to allow the RFB to
control the H/VSync's and thus the delivery of pixel data. This is not the
traditional RFBI design.

I am concerned that a thread or workqueue may introduce an unacceptable
delay between FRAMEDONE and re-arming the DSS/RFBI for the next frame. I
guess it depends on the rate that the panel requests frames.


 I don't know right away if calling omap_rfbi_update() from interrupt
 context is dangerous, but it might well be so you should check if
 carefully.

OK, thankyou. I will check.


 Also, remember that you may need to stop updates somehow when the panel
 is blanked or the driver is unloaded.


I *think* this is OK because the FRAMEDONE interrupt is deregistered in
omapdss_rfbi_display_disable().

 
  static void framedone_callback(void *data)
  {
  int r;
  u16 dw, dh;
  struct omap_dss_device *dssdev = (struct omap_dss_device *)data;
 
  /* Start the next update, triggered on the external H/VSync
 signals */
  dssdev-driver-get_resolution(dssdev, dw, dh);
  r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
  dssdev);
  if (r  0)
  printk(omap_rfbi_update FAILED);
  }
 
  static int generic_panel_power_on(struct omap_dss_device *dssdev)
  {
  int r;
  u16 dw, dh;
 
  r = omapdss_rfbi_display_enable(dssdev);
  if (r  0)
  goto err0;
 
  /* Setup external HSYNC/VSYNC triggering */
  r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
 400, /* HSYNS pulse 4uS */
 10,  /* VSYNC pulse 1ms */
 0, 0,   /* H/VSYNC not inverted */
 0);
  if (r  0)
  goto err1;
 
  /* Enable external triggering */
  r = omap_rfbi_enable_te(1, 0);
  if (r  0)
  goto err1;
 
  #if 0
  /* At a guess I do not think we need to do the prepare_update
   * if we are updating the whole area
   */

 I'm not sure if it's ok not to call it every time, but you should at
 least call it once to be sure everything is configured properly.

Thanks. I will add this call.


  Tomi


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

RFBI worked example

2011-01-06 Thread Ben Tucker 
Hi,

I am trying to setup an OMAP3530 based system for RFBI video output using
external triggering. Looking at the omap dss2 source code (and also
searching around) I cannot find any worked example of how to use the rfbi
driver. I know that RFBI has worked in the past for a Nokia N800 device.
Can you dig out any source code that shows how to use the RFBI driver?
In particular I need to see how the omap_rfbi_prepare_update() and
omap_rfbi_update() calls operate with their callback. I am thinking that I
should simply call omap_rfbi_update() in a thread and wait for the
completion call back after each call. I want to confirm that this is the
correct way to run the driver.

Thanks,
Ben



Ben Tucker
Senior Software Engineer
MPC Data Limited
e-mail: btuc...@mpc-data.co.uk  web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600  fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710660

MPC Data Limited is a company registered in England and Wales with company
number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14
7FJ
VAT no: 850625238

The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the addressee.
Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the original
message. When
addressed to our clients any opinions or advice contained in this email is
subject to
the terms and conditions expressed in the governing contract.
--
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