Re: [PATCH] usb: dwc3: Keeping 'resource' related code together

[Vivek Gautam]

Hi,


On Wed, Jun 4, 2014 at 12:41 AM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
 From: linux-usb-ow...@vger.kernel.org 
 [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Vivek Gautam
 Sent: Tuesday, June 03, 2014 3:40 AM

 Putting together the code related to getting the 'IORESOURCE_MEM'
 and assigning the same to dwc-xhci_resources, for increasing
 the readability.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---

 Based on 'next' branch of Felipe's usb tree.
 Also cleanly applies to 'usb-next' branch of Greg's usb tree.

  drivers/usb/dwc3/core.c |   38 +++---
  1 file changed, 19 insertions(+), 19 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 3f59c12..4ca925d 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -656,6 +656,25 @@ static int dwc3_probe(struct platform_device *pdev)
   return -ENODEV;
   }

 + dwc-xhci_resources[0].start = res-start;
 + dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
 + DWC3_XHCI_REGS_END;
 + dwc-xhci_resources[0].flags = res-flags;
 + dwc-xhci_resources[0].name = res-name;
 +
 + res-start += DWC3_GLOBALS_REGS_START;
 +
 + /*
 +  * Request memory region but exclude xHCI regs,
 +  * since it will be requested by the xhci-plat driver.
 +  */
 + regs = devm_ioremap_resource(dev, res);
 + if (IS_ERR(regs))
 + return PTR_ERR(regs);
 +
 + dwc-regs   = regs;
 + dwc-regs_size  = resource_size(res);
 +
   if (node) {
   dwc-maximum_speed = of_usb_get_maximum_speed(node);

 I think this will break if the following dwc3_core_get_phy() call returns
 -EPROBE_DEFER. Since you have incremented res-start above, the next time
 this probe function is called, res-start will have the wrong value.
 Provided I'm reading the code correctly of course :)

True, my fault. This will surely throw an error in requesting memory
region the next time probe
is called.
Thanks for catching this.


 I think you could fix that by decrementing res-start back to its
 original value just after the call to resource_size() above.

Sure will put
res-start -= DWC3_GLOBALS_REGS_START;
right after the call to resource_size() call.



-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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/3] clk: ti: add 'ti,round-rate' flag

[Tomi Valkeinen]

On 03/06/14 22:35, Paul Walmsley wrote:

 What's really needed is better control over rounding in the clock code.  

Well, if you ask me, what's really needed _now_ is to fix the bug that
makes am3xxx (and am4xxx when it's merged) display not to work. I don't
need a fix that solves all the clock set_rate/round issues once and for
all, I just want to get the display working.

 Both the driver API should be improved; and, to the extent that clock 
 sources share the same underlying code implementation, probably some clock 
 source configuration data enhancement is needed (DT or whatever).
 
 Furthermore, clk_set_rate() should never silently round a requested rate - 
 it should just return an error if it can't satisfy the requested rate 
 precisely.  Silently rounding a rate is racy, and, if we care about 
 drivers behaving consistently across different integration environments, 
 prone to behavior that the driver may not expect.
 
 Frankly, a DT ti,round-rate property is risible.  I certainly understand 
 why you don't like it and I don't know why that specific property was 
 proposed.  The issue has never been whether clk_round_rate() should round 

I created the property for the v2 because (if I recall right) you were
worried that fixing the rounding bug unconditionally could break some
drivers, and suggested that it should be used only for DSS.

 rates.  Of course it should.  The more pertinent question is, *how* should 
 it round the rate?  A more reasonable DT property approach would be to 
 specify how the clock's rate should be rounded: to the closest rate, to 
 the closest rate equal to or less than the desired rate, to the closest 
 rate greater than or equal to the desired rate; what the tolerance of the 
 closest rate should be, etc.  But drivers, e.g. many drivers that 
 control external I/O, should always be able to state that they want an 
 exact rate.
 
 ...
 
 In terms of the short-term thing to do, I'm currently thinking that the 
 thing to do is to modify the PLL set_rate() code in mach-omap2/ to not 
 round the rate at all, and then switch the PLL rate rounding code to 
 equal-or-closest-lesser-rate, with something like the oldhardcoded rate 
 tolerances.  That should push the responsibility out to the drivers to 
 control how they want the rounding to happen.  Then the drivers should be 
 able to probe available rates with repeated calls to clk_round_rate() if 
 they want, and if people get unhappy with that, then it might drive 
 rounding improvements in the clock API.

I agree, the current clock rounding is rather undefined, and I need to
do my own calculations in omapdss to probe the clock rates.

 But all this won't happen in -rc8; this is 3.16 material..
 
 
 We can always see how it goes and fix it up afterwards when everything 
 explodes.
 
 No thanks... that's what leads to these kinds of messes :-( 

I don't understand how this fix would lead to a mess.

1. AM3xxx/AM4xxx display is broken
2. The PLL round function is broken, it doesn't round
3. The fix to omap2_dpll_round_rate has been in TI's kernel for a long
time, no problems observed
4. We've ran test runs with linux-next + the fix, no problems observed

I agree that there's a possibility that some driver could break with the
fix. I think it's a theoretical possibility, because clk-divider.c (I
think there's always a divider after the pll in omaps) doesn't handle
the error from the dpll code, so I don't really see how a driver could
manage to handle the error as the error is not conveyed to the driver.

In any case, if a driver breaks because of the fix, the driver's clock
handling is totally broken in any case, and it should be fixed.

Do we want to keep an important subsystem totally broken because there's
a theoretical possibility that the fix could break something else?

The fix was first posted in January. And we're still discussing about
it. And I still don't understand why the fix could cause problems. So
if the patch (v1 preferably) cannot be applied to 3.15, I'd very much
like to hear how it makes the situation worse, either for the current
kernel or for any future changes to the drivers/clock code.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: am335x: system doesn't reboot after flashing NAND

[Sekhar Nori]

On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?
 
 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.
 
 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

Writing to sysboot bits in control_status register will make ROM change
boot sequence. Not sure why NAND driver should be changing these values.
Can you please verify that this register is indeed modified after the
NAND write?

Thanks,
Sekhar
--
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 3/7] OMAPDSS: DPI: Store dpi_data pointer in the DT port's data

[Archit Taneja]

DPI and SDI ports are backed by only one parent DSS device. We don't have a
corresponding platform_device for ports under DSS. In order to support multiple
instances of DPI, we need to pass the driver data pointer through the DPI port's
private data ('data' member in device_node struct).

dpi_init_output/dpi_uninit_output are untouched and only used for non-DT case,
these are called when the DPI platform device probed/removed. These funcs will
be removed when non-DT mode is removed.

dpi_init_output_port/dpi_uninit_output_port are created and used for the DT
path, called when DSS inits/uninits it's ports. These new functions retrieve
the dpi_data pointer from 'port-data', and not from the platform device's
data(pdev-dev) like in the non-DT path.

We add some code in dss_uninit_ports() to pass a pointer to the DPI port in
dpi_uninit_port().

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dpi.c | 36 ++--
 drivers/video/fbdev/omap2/dss/dss.c | 13 -
 drivers/video/fbdev/omap2/dss/dss.h |  2 +-
 3 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index 9087619..b579022 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -59,6 +59,7 @@ static struct dpi_data *dpi_get_data_from_dssdev(struct 
omap_dss_device *dssdev)
return container_of(dssdev, struct dpi_data, output);
 }
 
+/* only used in non-DT mode */
 static struct dpi_data *dpi_get_data_from_pdev(struct platform_device *pdev)
 {
return dev_get_drvdata(pdev-dev);
@@ -724,6 +725,30 @@ static void __exit dpi_uninit_output(struct 
platform_device *pdev)
omapdss_unregister_output(out);
 }
 
+static void dpi_init_output_port(struct platform_device *pdev,
+   struct device_node *port)
+{
+   struct dpi_data *dpi = port-data;
+   struct omap_dss_device *out = dpi-output;
+
+   out-dev = pdev-dev;
+   out-id = OMAP_DSS_OUTPUT_DPI;
+   out-output_type = OMAP_DISPLAY_TYPE_DPI;
+   out-dispc_channel = dpi_get_channel();
+   out-ops.dpi = dpi_ops;
+   out-owner = THIS_MODULE;
+
+   omapdss_register_output(out);
+}
+
+static void __exit dpi_uninit_output_port(struct device_node *port)
+{
+   struct dpi_data *dpi = port-data;
+   struct omap_dss_device *out = dpi-output;
+
+   omapdss_unregister_output(out);
+}
+
 static int omap_dpi_probe(struct platform_device *pdev)
 {
struct dpi_data *dpi;
@@ -795,15 +820,14 @@ int __init dpi_init_port(struct platform_device *pdev, 
struct device_node *port)
of_node_put(ep);
 
dpi-pdev = pdev;
+   port-data = dpi;
 
mutex_init(dpi-lock);
 
-   dpi_init_output(pdev);
+   dpi_init_output_port(pdev, port);
 
dpi-port_initialized = true;
 
-   dev_set_drvdata(pdev-dev, dpi);
-
return 0;
 
 err_datalines:
@@ -812,12 +836,12 @@ err_datalines:
return r;
 }
 
-void __exit dpi_uninit_port(struct platform_device *pdev)
+void __exit dpi_uninit_port(struct device_node *port)
 {
-   struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
+   struct dpi_data *dpi = port-data;
 
if (!dpi-port_initialized)
return;
 
-   dpi_uninit_output(dpi-pdev);
+   dpi_uninit_output_port(port);
 }
diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 225b13f..bebb824 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -822,8 +822,19 @@ static int __init dss_init_ports(struct platform_device 
*pdev)
 
 static void __exit dss_uninit_ports(struct platform_device *pdev)
 {
+   struct device_node *parent = pdev-dev.of_node;
+   struct device_node *port;
+   int r;
+
+   if (parent == NULL)
+   return;
+
+   port = omapdss_of_get_next_port(parent, NULL);
+   if (!port)
+   return;
+
 #ifdef CONFIG_OMAP2_DSS_DPI
-   dpi_uninit_port(pdev);
+   dpi_uninit_port(port);
 #endif
 
 #ifdef CONFIG_OMAP2_DSS_SDI
diff --git a/drivers/video/fbdev/omap2/dss/dss.h 
b/drivers/video/fbdev/omap2/dss/dss.h
index da7f5f9..5b9db95 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -359,7 +359,7 @@ int dpi_init_platform_driver(void) __init;
 void dpi_uninit_platform_driver(void) __exit;
 
 int dpi_init_port(struct platform_device *pdev, struct device_node *port) 
__init;
-void dpi_uninit_port(struct platform_device *pdev) __exit;
+void dpi_uninit_port(struct device_node *port) __exit;
 
 /* DISPC */
 int dispc_init_platform_driver(void) __init;
-- 
1.8.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

[PATCH v3 1/7] OMAPDSS: DPI: Use DPI driver data

[Archit Taneja]

DPI related data is currently a static global struct parameter. It is accessed
directly by functions in the driver.

This method won't work if we want the driver to support multiple DPI instances.
Create struct dpi_data, and pass it's pointer to functions which need to use it.

We still have a static instance defined for dpi_data, which is accessed by top
level DPI ops. This will be removed when the driver dynamically allocates
dpi_data for each DPI instance.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dpi.c | 187 +---
 1 file changed, 107 insertions(+), 80 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index 9368972..945d988 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -37,7 +37,7 @@
 #include dss.h
 #include dss_features.h
 
-static struct {
+struct dpi_data {
struct platform_device *pdev;
 
struct regulator *vdds_dsi_reg;
@@ -52,7 +52,9 @@ static struct {
struct omap_dss_device output;
 
bool port_initialized;
-} dpi;
+};
+
+static struct dpi_data dpi;
 
 static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
 {
@@ -200,15 +202,16 @@ static bool dpi_calc_dss_cb(unsigned long fck, void *data)
dpi_calc_dispc_cb, ctx);
 }
 
-static bool dpi_dsi_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
+static bool dpi_dsi_clk_calc(struct dpi_data *dpi, unsigned long pck,
+   struct dpi_clk_calc_ctx *ctx)
 {
unsigned long clkin;
unsigned long pll_min, pll_max;
 
-   clkin = dsi_get_pll_clkin(dpi.dsidev);
+   clkin = dsi_get_pll_clkin(dpi-dsidev);
 
memset(ctx, 0, sizeof(*ctx));
-   ctx-dsidev = dpi.dsidev;
+   ctx-dsidev = dpi-dsidev;
ctx-pck_min = pck - 1000;
ctx-pck_max = pck + 1000;
ctx-dsi_cinfo.clkin = clkin;
@@ -216,7 +219,7 @@ static bool dpi_dsi_clk_calc(unsigned long pck, struct 
dpi_clk_calc_ctx *ctx)
pll_min = 0;
pll_max = 0;
 
-   return dsi_pll_calc(dpi.dsidev, clkin,
+   return dsi_pll_calc(dpi-dsidev, clkin,
pll_min, pll_max,
dpi_calc_pll_cb, ctx);
 }
@@ -252,7 +255,7 @@ static bool dpi_dss_clk_calc(unsigned long pck, struct 
dpi_clk_calc_ctx *ctx)
 
 
 
-static int dpi_set_dsi_clk(enum omap_channel channel,
+static int dpi_set_dsi_clk(struct dpi_data *dpi, enum omap_channel channel,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
 {
@@ -260,18 +263,18 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
int r;
bool ok;
 
-   ok = dpi_dsi_clk_calc(pck_req, ctx);
+   ok = dpi_dsi_clk_calc(dpi, pck_req, ctx);
if (!ok)
return -EINVAL;
 
-   r = dsi_pll_set_clock_div(dpi.dsidev, ctx.dsi_cinfo);
+   r = dsi_pll_set_clock_div(dpi-dsidev, ctx.dsi_cinfo);
if (r)
return r;
 
dss_select_lcd_clk_source(channel,
dpi_get_alt_clk_src(channel));
 
-   dpi.mgr_config.clock_info = ctx.dispc_cinfo;
+   dpi-mgr_config.clock_info = ctx.dispc_cinfo;
 
*fck = ctx.dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = ctx.dispc_cinfo.lck_div;
@@ -280,8 +283,8 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
return 0;
 }
 
-static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
-   int *lck_div, int *pck_div)
+static int dpi_set_dispc_clk(struct dpi_data *dpi, unsigned long pck_req,
+   unsigned long *fck, int *lck_div, int *pck_div)
 {
struct dpi_clk_calc_ctx ctx;
int r;
@@ -295,7 +298,7 @@ static int dpi_set_dispc_clk(unsigned long pck_req, 
unsigned long *fck,
if (r)
return r;
 
-   dpi.mgr_config.clock_info = ctx.dispc_cinfo;
+   dpi-mgr_config.clock_info = ctx.dispc_cinfo;
 
*fck = ctx.fck;
*lck_div = ctx.dispc_cinfo.lck_div;
@@ -304,19 +307,21 @@ static int dpi_set_dispc_clk(unsigned long pck_req, 
unsigned long *fck,
return 0;
 }
 
-static int dpi_set_mode(struct omap_overlay_manager *mgr)
+static int dpi_set_mode(struct dpi_data *dpi)
 {
-   struct omap_video_timings *t = dpi.timings;
+   struct omap_dss_device *out = dpi-output;
+   struct omap_overlay_manager *mgr = out-manager;
+   struct omap_video_timings *t = dpi-timings;
int lck_div = 0, pck_div = 0;
unsigned long fck = 0;
unsigned long pck;
int r = 0;
 
-   if (dpi.dsidev)
-   r = dpi_set_dsi_clk(mgr-id, t-pixelclock, fck,
+   if (dpi-dsidev)
+   r = dpi_set_dsi_clk(dpi, mgr-id, t-pixelclock, fck,
lck_div, pck_div);
else
-   r = dpi_set_dispc_clk(t-pixelclock, fck,
+   r = dpi_set_dispc_clk(dpi, t-pixelclock, fck,

[PATCH v3 2/7] OMAPDSS: DPI: Allocate driver data

[Archit Taneja]

Allocate driver data(dpi_data) for each DPI instance. It's allocated in
omap_dpi_probe() when DT isn't used, and in dpi_init_port() when DT is used.
The dpi_data struct instance is no longer global. In the case of DPI ops, it's
retrieved from dpi_get_data_from_dssdev(). 'dssdev' passed by the connected
encoder/panel driver is a pointer to the 'output' member in dpi_data, and thus
can be used to get the DPI instance's driver data. In the case of probe/ini_port
functions, it's set as DPI/DSS device's private data embedded in the
platform_device struct.

Having dpi_data as private data of the platform device will not work for
multiple DPI instances in the DT case. This is because there is no corresponding
platform_device for DPI or SDI, they exist only as ports under the parent DSS
platform_device in the DT case. The DPI port's private data('data' member in
device_node struct) will later be used to store dpi_data.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dpi.c | 46 ++---
 drivers/video/fbdev/omap2/dss/dss.c |  6 ++---
 drivers/video/fbdev/omap2/dss/dss.h |  2 +-
 3 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index 945d988..9087619 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -54,7 +54,15 @@ struct dpi_data {
bool port_initialized;
 };
 
-static struct dpi_data dpi;
+static struct dpi_data *dpi_get_data_from_dssdev(struct omap_dss_device 
*dssdev)
+{
+   return container_of(dssdev, struct dpi_data, output);
+}
+
+static struct dpi_data *dpi_get_data_from_pdev(struct platform_device *pdev)
+{
+   return dev_get_drvdata(pdev-dev);
+}
 
 static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
 {
@@ -359,7 +367,7 @@ static void dpi_config_lcd_manager(struct dpi_data *dpi)
 
 static int dpi_display_enable(struct omap_dss_device *dssdev)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
struct omap_dss_device *out = dpi-output;
int r;
 
@@ -439,7 +447,7 @@ err_no_reg:
 
 static void dpi_display_disable(struct omap_dss_device *dssdev)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
struct omap_overlay_manager *mgr = dpi-output.manager;
 
mutex_lock(dpi-lock);
@@ -463,7 +471,7 @@ static void dpi_display_disable(struct omap_dss_device 
*dssdev)
 static void dpi_set_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
 
DSSDBG(dpi_set_timings\n);
 
@@ -477,7 +485,7 @@ static void dpi_set_timings(struct omap_dss_device *dssdev,
 static void dpi_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
 
mutex_lock(dpi-lock);
 
@@ -489,7 +497,7 @@ static void dpi_get_timings(struct omap_dss_device *dssdev,
 static int dpi_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
struct omap_overlay_manager *mgr = dpi-output.manager;
int lck_div, pck_div;
unsigned long fck;
@@ -529,7 +537,7 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
 
 static void dpi_set_data_lines(struct omap_dss_device *dssdev, int data_lines)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
 
mutex_lock(dpi-lock);
 
@@ -635,7 +643,7 @@ static enum omap_channel dpi_get_channel(void)
 static int dpi_connect(struct omap_dss_device *dssdev,
struct omap_dss_device *dst)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_dssdev(dssdev);
struct omap_overlay_manager *mgr;
int r;
 
@@ -694,7 +702,7 @@ static const struct omapdss_dpi_ops dpi_ops = {
 
 static void dpi_init_output(struct platform_device *pdev)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
struct omap_dss_device *out = dpi-output;
 
out-dev = pdev-dev;
@@ -710,7 +718,7 @@ static void dpi_init_output(struct platform_device *pdev)
 
 static void __exit dpi_uninit_output(struct platform_device *pdev)
 {
-   struct dpi_data *dpi = dpi;
+   struct dpi_data *dpi = dpi_get_data_from_pdev(pdev);
struct omap_dss_device *out = dpi-output;
 
omapdss_unregister_output(out);
@@ -718,7 +726,11 @@ static void __exit dpi_uninit_output(struct 
platform_device *pdev)
 
 static int omap_dpi_probe(struct platform_device 

[PATCH v3 5/7] OMAPDSS: DT: Get source endpoint by matching reg-id

[Archit Taneja]

In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node,
and then see what omapdss output has the matching device_node pointer in
omap_dss_find_output_by_node.

For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS
device_node pointer. If the source is one of these outputs, the above method
won't work.

To get the correct output for ports within DSS(and in other cases in the future,
where multiple ports might be under one device), we require additional
information which is exclusive to the output port.

We create a new field in omap_dss_device called 'port_num', this provides port
number of the output port corresponding to this device. When searching for the
source endpoint in DT, we extract the 'reg' property from the port corresponding
to the endpoint source. From the list of registered outputs, we pick out that
output which has both dev-of_node and port_num matching with the device_node
pointer and 'reg' of the source endpoint node from DT.

For encoder blocks(the ones which have both an input and output port), we need
to set the port_num as the 'reg' property for the output port as defined in the
DT bindings. We set port_num to 1 in the tfp410 and tpd12s015 encoder drivers.

Signed-off-by: Archit Taneja arc...@ti.com
---
 .../fbdev/omap2/displays-new/encoder-tfp410.c  |  1 +
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |  1 +
 drivers/video/fbdev/omap2/dss/dss-of.c | 58 +++---
 drivers/video/fbdev/omap2/dss/dss.h|  4 ++
 drivers/video/fbdev/omap2/dss/output.c | 19 +--
 include/video/omapdss.h|  5 +-
 6 files changed, 66 insertions(+), 22 deletions(-)

diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c 
b/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
index b4e9a42..d927455 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c
@@ -249,6 +249,7 @@ static int tfp410_probe(struct platform_device *pdev)
dssdev-output_type = OMAP_DISPLAY_TYPE_DVI;
dssdev-owner = THIS_MODULE;
dssdev-phy.dpi.data_lines = ddata-data_lines;
+   dssdev-port_num = 1;
 
r = omapdss_register_output(dssdev);
if (r) {
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c 
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index 7e33686..9e25fe7 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -389,6 +389,7 @@ static int tpd_probe(struct platform_device *pdev)
dssdev-type = OMAP_DISPLAY_TYPE_HDMI;
dssdev-output_type = OMAP_DISPLAY_TYPE_HDMI;
dssdev-owner = THIS_MODULE;
+   dssdev-port_num = 1;
 
in = ddata-in;
 
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c 
b/drivers/video/fbdev/omap2/dss/dss-of.c
index a4b20aa..928ee63 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -20,6 +20,8 @@
 
 #include video/omapdss.h
 
+#include dss.h
+
 struct device_node *
 omapdss_of_get_next_port(const struct device_node *parent,
 struct device_node *prev)
@@ -84,20 +86,17 @@ omapdss_of_get_next_endpoint(const struct device_node 
*parent,
 }
 EXPORT_SYMBOL_GPL(omapdss_of_get_next_endpoint);
 
-static struct device_node *
-omapdss_of_get_remote_device_node(const struct device_node *node)
+struct device_node *dss_of_port_get_parent_device(struct device_node *port)
 {
struct device_node *np;
int i;
 
-   np = of_parse_phandle(node, remote-endpoint, 0);
-
-   if (!np)
+   if (!port)
return NULL;
 
-   np = of_get_next_parent(np);
+   np = of_get_next_parent(port);
 
-   for (i = 0; i  3  np; ++i) {
+   for (i = 0; i  2  np; ++i) {
struct property *prop;
 
prop = of_find_property(np, compatible, NULL);
@@ -111,6 +110,31 @@ omapdss_of_get_remote_device_node(const struct device_node 
*node)
return NULL;
 }
 
+u32 dss_of_port_get_port_number(struct device_node *port)
+{
+   int r;
+   u32 reg;
+
+   r = of_property_read_u32(port, reg, reg);
+   if (r)
+   reg = 0;
+
+   return reg;
+}
+
+static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
+{
+   struct device_node *np;
+
+   np = of_parse_phandle(node, remote-endpoint, 0);
+   if (!np)
+   return NULL;
+
+   np = of_get_next_parent(np);
+
+   return np;
+}
+
 struct device_node *
 omapdss_of_get_first_endpoint(const struct device_node *parent)
 {
@@ -133,27 +157,25 @@ struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node)
 {
struct device_node *ep;
-   struct device_node *src_node;
+   struct device_node *src_port;
struct omap_dss_device 

[PATCH v3 6/7] OMAPDSS: DPI: Add support for multiple instances

[Archit Taneja]

Register DPI outputs, and assign the port_num to them as specified by the
'reg' property in the DPI ports in DT.

To support multiple DPI instances, dpi_get_channel needs to take the DPI
instance's reg-id to get the corresponding channel. Make it take this
argument.We just pass 0 in the non-DT path, since we don't support multiple
instances in the non-DT case.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dpi.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index b579022..3e204a8 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -616,7 +616,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
  * the channel in some more dynamic manner, or get the channel as a user
  * parameter.
  */
-static enum omap_channel dpi_get_channel(void)
+static enum omap_channel dpi_get_channel(int reg)
 {
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
@@ -710,7 +710,7 @@ static void dpi_init_output(struct platform_device *pdev)
out-id = OMAP_DSS_OUTPUT_DPI;
out-output_type = OMAP_DISPLAY_TYPE_DPI;
out-name = dpi.0;
-   out-dispc_channel = dpi_get_channel();
+   out-dispc_channel = dpi_get_channel(0);
out-ops.dpi = dpi_ops;
out-owner = THIS_MODULE;
 
@@ -730,11 +730,31 @@ static void dpi_init_output_port(struct platform_device 
*pdev,
 {
struct dpi_data *dpi = port-data;
struct omap_dss_device *out = dpi-output;
+   int r;
+   u32 reg;
+
+   r = of_property_read_u32(port, reg, reg);
+   if (r)
+   reg = 0;
+
+   switch (reg) {
+   case 2:
+   out-name = dpi.2;
+   break;
+   case 1:
+   out-name = dpi.1;
+   break;
+   case 0:
+   default:
+   out-name = dpi.0;
+   break;
+   }
 
out-dev = pdev-dev;
out-id = OMAP_DSS_OUTPUT_DPI;
out-output_type = OMAP_DISPLAY_TYPE_DPI;
-   out-dispc_channel = dpi_get_channel();
+   out-dispc_channel = dpi_get_channel(reg);
+   out-port_num = reg;
out-ops.dpi = dpi_ops;
out-owner = THIS_MODULE;
 
-- 
1.8.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

[PATCH v3 0/7] OMAPDSS: Support multiple DPI instances

[Archit Taneja]

DSS on DRA7x has 3 DPI outputs. In order to get them to work. We need to make
the DPI driver support multiple DPI instances. We also need to tweak the
DT parsing done to match an encoder/connector/panel driver to find the
corresponding omapdss output. This series tries to achieve the above 2 tasks.

Changes in v3:

- Make indexes in port lists not depend on DPI and SDI CONFIGs.
- Cleaner code in dss_init_ports/uninit_ports.
- Split up the patch which creates multi DPI instances.
- Switch to a simpler way of extracting DPI driver data from dssdev.
- Change some of the dss-of fucntions, such that
  omapdss_of_find_source_for_first_ep is simplified.

Archit Taneja (7):
  OMAPDSS: DPI: Use DPI driver data
  OMAPDSS: DPI: Allocate driver data
  OMAPDSS: DPI: Store dpi_data pointer in the DT port's data
  OMAPDSS: DSS: init dss ports cleanly
  OMAPDSS: DT: Get source endpoint by matching reg-id
  OMAPDSS: DPI: Add support for multiple instances
  omapdss: DSS: add reg-id param to dpi_select_source

 .../fbdev/omap2/displays-new/encoder-tfp410.c  |   1 +
 .../fbdev/omap2/displays-new/encoder-tpd12s015.c   |   1 +
 drivers/video/fbdev/omap2/dss/dpi.c| 259 ++---
 drivers/video/fbdev/omap2/dss/dss-of.c |  58 +++--
 drivers/video/fbdev/omap2/dss/dss.c| 108 +++--
 drivers/video/fbdev/omap2/dss/dss.h|  34 ++-
 drivers/video/fbdev/omap2/dss/output.c |  19 +-
 drivers/video/fbdev/omap2/dss/sdi.c|   2 +-
 include/video/omapdss.h|   5 +-
 9 files changed, 354 insertions(+), 133 deletions(-)

-- 
1.8.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

[PATCH v3 4/7] OMAPDSS: DSS: init dss ports cleanly

[Archit Taneja]

The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.

For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property in dts to specify the DPI output instance.

The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
'reg' is used to specify whether the output is SDI, or another DPI instance.

We create a list of port types supported for each DSS rev, with the index of the
port in the list matching the reg id. This allows us to have a more generic way
to init/uninit ports within DSS, and support multiple DPI ports.

Also, make the uninit_port functions iterative since we will have multiple DPI
ports to uninit in the future.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dss.c | 81 ++---
 drivers/video/fbdev/omap2/dss/dss.h | 26 +++-
 drivers/video/fbdev/omap2/dss/sdi.c |  2 +-
 3 files changed, 93 insertions(+), 16 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index bebb824..3b41953 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -70,6 +70,8 @@ struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
+   enum omap_display_type *ports;
+   int num_ports;
int (*dpi_select_source)(enum omap_channel channel);
 };
 
@@ -689,6 +691,16 @@ void dss_debug_dump_clocks(struct seq_file *s)
 }
 #endif
 
+
+static enum omap_display_type omap2plus_ports[] = {
+   OMAP_DISPLAY_TYPE_DPI,
+};
+
+static enum omap_display_type omap34xx_ports[] = {
+   OMAP_DISPLAY_TYPE_DPI,
+   OMAP_DISPLAY_TYPE_SDI,
+};
+
 static const struct dss_features omap24xx_dss_feats __initconst = {
/*
 * fck div max is really 16, but the divider range has gaps. The range
@@ -698,6 +710,8 @@ static const struct dss_features omap24xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   2,
.parent_clk_name=   core_ck,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .ports  =   omap2plus_ports,
+   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
 };
 
 static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -705,6 +719,8 @@ static const struct dss_features omap34xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   2,
.parent_clk_name=   dpll4_ck,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .ports  =   omap34xx_ports,
+   .num_ports  =   ARRAY_SIZE(omap34xx_ports),
 };
 
 static const struct dss_features omap3630_dss_feats __initconst = {
@@ -712,6 +728,8 @@ static const struct dss_features omap3630_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.parent_clk_name=   dpll4_ck,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .ports  =   omap2plus_ports,
+   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
 };
 
 static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -719,6 +737,8 @@ static const struct dss_features omap44xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.parent_clk_name=   dpll_per_x2_ck,
.dpi_select_source  =   dss_dpi_select_source_omap4,
+   .ports  =   omap2plus_ports,
+   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
 };
 
 static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -726,6 +746,8 @@ static const struct dss_features omap54xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.parent_clk_name=   dpll_per_x2_ck,
.dpi_select_source  =   dss_dpi_select_source_omap5,
+   .ports  =   omap2plus_ports,
+   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
 };
 
 static const struct dss_features am43xx_dss_feats __initconst = {
@@ -733,6 +755,8 @@ static const struct dss_features am43xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   0,
.parent_clk_name=   NULL,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .ports  =   omap2plus_ports,
+   .num_ports  =   ARRAY_SIZE(omap2plus_ports),
 };
 
 static int __init dss_init_features(struct platform_device *pdev)
@@ -798,23 +822,32 @@ static int __init dss_init_ports(struct platform_device 
*pdev)
if (!port)

[PATCH v3 7/7] omapdss: DSS: add reg-id param to dpi_select_source

[Archit Taneja]

Add an argument which describes which DPI instance we are referring to when
selecting it's overlay manager.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/fbdev/omap2/dss/dpi.c |  2 +-
 drivers/video/fbdev/omap2/dss/dss.c | 12 ++--
 drivers/video/fbdev/omap2/dss/dss.h |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dpi.c 
b/drivers/video/fbdev/omap2/dss/dpi.c
index 3e204a8..776c409 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -396,7 +396,7 @@ static int dpi_display_enable(struct omap_dss_device 
*dssdev)
if (r)
goto err_get_dispc;
 
-   r = dss_dpi_select_source(out-manager-id);
+   r = dss_dpi_select_source(out-port_num, out-manager-id);
if (r)
goto err_src_sel;
 
diff --git a/drivers/video/fbdev/omap2/dss/dss.c 
b/drivers/video/fbdev/omap2/dss/dss.c
index 3b41953..8fd141f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -72,7 +72,7 @@ struct dss_features {
const char *parent_clk_name;
enum omap_display_type *ports;
int num_ports;
-   int (*dpi_select_source)(enum omap_channel channel);
+   int (*dpi_select_source)(int id, enum omap_channel channel);
 };
 
 static struct {
@@ -566,7 +566,7 @@ enum dss_hdmi_venc_clk_source_select 
dss_get_hdmi_venc_clk_source(void)
return REG_GET(DSS_CONTROL, 15, 15);
 }
 
-static int dss_dpi_select_source_omap2_omap3(enum omap_channel channel)
+static int dss_dpi_select_source_omap2_omap3(int id, enum omap_channel channel)
 {
if (channel != OMAP_DSS_CHANNEL_LCD)
return -EINVAL;
@@ -574,7 +574,7 @@ static int dss_dpi_select_source_omap2_omap3(enum 
omap_channel channel)
return 0;
 }
 
-static int dss_dpi_select_source_omap4(enum omap_channel channel)
+static int dss_dpi_select_source_omap4(int id, enum omap_channel channel)
 {
int val;
 
@@ -594,7 +594,7 @@ static int dss_dpi_select_source_omap4(enum omap_channel 
channel)
return 0;
 }
 
-static int dss_dpi_select_source_omap5(enum omap_channel channel)
+static int dss_dpi_select_source_omap5(int id, enum omap_channel channel)
 {
int val;
 
@@ -620,9 +620,9 @@ static int dss_dpi_select_source_omap5(enum omap_channel 
channel)
return 0;
 }
 
-int dss_dpi_select_source(enum omap_channel channel)
+int dss_dpi_select_source(int id, enum omap_channel channel)
 {
-   return dss.feat-dpi_select_source(channel);
+   return dss.feat-dpi_select_source(id, channel);
 }
 
 static int dss_get_clocks(void)
diff --git a/drivers/video/fbdev/omap2/dss/dss.h 
b/drivers/video/fbdev/omap2/dss/dss.h
index 849ede1..a7a0d8a 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -209,7 +209,7 @@ int dss_init_platform_driver(void) __init;
 void dss_uninit_platform_driver(void);
 
 unsigned long dss_get_dispc_clk_rate(void);
-int dss_dpi_select_source(enum omap_channel channel);
+int dss_dpi_select_source(int id, enum omap_channel channel);
 void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
 enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
 const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
-- 
1.8.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

[PATCH] hsi: omap_ssi_port: use normal module refcounting

[Arnd Bergmann]

The ref_module() function is used for internal housekeeping of the
module code, it's not normally used by subsystems or device drivers,
and the use of ref_module in the omap_ssi_port driver causes a link
build error when modules are disabled:

hsi/controllers/omap_ssi_port.c: In function 'ssi_port_probe':
hsi/controllers/omap_ssi_port.c:1119:2: error: implicit declaration of function 
'ref_module' [-Werror=implicit-function-declaration]

This changes the omap_ssi_port driver to use try_module_get()
and module_put() instead, which is the normal way to ensure that
the driver providing a device used in another module does not
go away.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Sebastian Reichel s...@kernel.org
Cc: Carlos Chinea carlos.chi...@nokia.com
Cc: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com

diff --git a/drivers/hsi/controllers/omap_ssi_port.c 
b/drivers/hsi/controllers/omap_ssi_port.c
index b8693f0..6eb7c28 100644
--- a/drivers/hsi/controllers/omap_ssi_port.c
+++ b/drivers/hsi/controllers/omap_ssi_port.c
@@ -1116,8 +1116,7 @@ static int __init ssi_port_probe(struct platform_device 
*pd)
 
dev_dbg(pd-dev, init ssi port...\n);
 
-   err = ref_module(THIS_MODULE, ssi-owner);
-   if (err) {
+   if (!try_module_get(ssi-owner)) {
dev_err(pd-dev, could not increment parent module refcount 
(err=%d)\n,
err);
return -ENODEV;
@@ -1254,6 +1253,7 @@ static int __exit ssi_port_remove(struct platform_device 
*pd)
 
omap_ssi-port[omap_port-port_id] = NULL;
platform_set_drvdata(pd, NULL);
+   module_put(port-owner);
pm_runtime_disable(pd-dev);
 
return 0;

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

[PATCH v2] hsi: omap_ssi_port: use normal module refcounting

[Arnd Bergmann]

The ref_module() function is used for internal housekeeping of the
module code, it's not normally used by subsystems or device drivers,
and the use of ref_module in the omap_ssi_port driver causes a link
build error when modules are disabled:

hsi/controllers/omap_ssi_port.c: In function 'ssi_port_probe':
hsi/controllers/omap_ssi_port.c:1119:2: error: implicit declaration of function 
'ref_module' [-Werror=implicit-function-declaration]

This changes the omap_ssi_port driver to use try_module_get()
and module_put() instead, which is the normal way to ensure that
the driver providing a device used in another module does not
go away.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Sebastian Reichel s...@kernel.org
Cc: Carlos Chinea carlos.chi...@nokia.com
Cc: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
v2: fix a stupid typo, I accidentally sent out the wrong version of the patch

diff --git a/drivers/hsi/controllers/omap_ssi_port.c 
b/drivers/hsi/controllers/omap_ssi_port.c
index b8693f0..29aea0b 100644
--- a/drivers/hsi/controllers/omap_ssi_port.c
+++ b/drivers/hsi/controllers/omap_ssi_port.c
@@ -1116,8 +1116,7 @@ static int __init ssi_port_probe(struct platform_device 
*pd)
 
dev_dbg(pd-dev, init ssi port...\n);
 
-   err = ref_module(THIS_MODULE, ssi-owner);
-   if (err) {
+   if (!try_module_get(ssi-owner)) {
dev_err(pd-dev, could not increment parent module refcount 
(err=%d)\n,
err);
return -ENODEV;
@@ -1254,6 +1253,7 @@ static int __exit ssi_port_remove(struct platform_device 
*pd)
 
omap_ssi-port[omap_port-port_id] = NULL;
platform_set_drvdata(pd, NULL);
+   module_put(ssi-owner);
pm_runtime_disable(pd-dev);
 
return 0;

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

Re: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

Can I read this register from userspace via debugfs? I can't find such
entry so far.

I made another test: write to NAND and then make kexec. In this case I
can successfully execute reboot afterwards.

Yegor
--
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: am335x: system doesn't reboot after flashing NAND

[Roger Quadros]

Hi,

On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

Can you try to get XIP out of the boot sequence and see if it works?
Maybe try to boot from mmc directly?

This would prove that NAND/GPMC driver is leaving some state that doesn't
go well with the bootROM XIP.

cheers,
-roger


 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?
 
 Can I read this register from userspace via debugfs? I can't find such
 entry so far.
 
 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.
 
 Yegor
 

--
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: am335x: system doesn't reboot after flashing NAND

[Sekhar Nori]

On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?
 
 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

If not debugfs you can use devmem2[1] to read from userspace. You need
to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

Okay. We need to monitor how sysboot values are changing between these
steps.

Thanks,
Sekhar

[1] www.lartmaker.nl/lartware/port/devmem2.c
--
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: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Mark Brown]

On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
 On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter bu...@lixom.net wrote:

  [2.816920] smps9: failed to get the current voltage

 This seems to be from palmas registration failing, which in turns
 causes vmmc regulator lookup to fail. See the errors about palmas-pmic
 above.

Always CC maintainers on things.  This is a bug in the driver, it needs
to support retrieving voltages at all times (and would probably run into
trouble anyway).


signature.asc
Description: Digital signature

[PATCH v2] usb: dwc3: Keeping 'resource' related code together

[Vivek Gautam]

Putting together the code related to getting the 'IORESOURCE_MEM'
and assigning the same to dwc-xhci_resources, for increasing
the readability.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---

Changes from v1:
 - Fixed issue with 'res-start' as pointed out by Paul Zimmerman
   by decrementing it back to its original value.

 drivers/usb/dwc3/core.c |   44 +---
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3f59c12..8b1acad 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -656,6 +656,31 @@ static int dwc3_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+   dwc-xhci_resources[0].start = res-start;
+   dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
+   DWC3_XHCI_REGS_END;
+   dwc-xhci_resources[0].flags = res-flags;
+   dwc-xhci_resources[0].name = res-name;
+
+   res-start += DWC3_GLOBALS_REGS_START;
+
+   /*
+* Request memory region but exclude xHCI regs,
+* since it will be requested by the xhci-plat driver.
+*/
+   regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+
+   dwc-regs   = regs;
+   dwc-regs_size  = resource_size(res);
+   /*
+* restore res-start back to its original value so that,
+* in case the probe is deferred, we don't end up getting error in
+* request the memory region the next time probe is called.
+*/
+   res-start -= DWC3_GLOBALS_REGS_START;
+
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
 
@@ -676,28 +701,9 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   dwc-xhci_resources[0].start = res-start;
-   dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
-   DWC3_XHCI_REGS_END;
-   dwc-xhci_resources[0].flags = res-flags;
-   dwc-xhci_resources[0].name = res-name;
-
-   res-start += DWC3_GLOBALS_REGS_START;
-
-   /*
-* Request memory region but exclude xHCI regs,
-* since it will be requested by the xhci-plat driver.
-*/
-   regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(regs))
-   return PTR_ERR(regs);
-
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
 
-   dwc-regs   = regs;
-   dwc-regs_size  = resource_size(res);
-
dev-dma_mask   = dev-parent-dma_mask;
dev-dma_parms  = dev-parent-dma_parms;
dma_set_coherent_mask(dev, dev-parent-coherent_dma_mask);
-- 
1.7.10.4

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

MEDDELELSER

[System Administrator]

Du har overskredet opbevaring grænse på din postkasse. Du vil ikke være i
stand til at sende eller modtage ny post, indtil du opgraderer din e
kvote.

Kopier nedenstående link og udfylde formularen for at opgradere din konto.

https://www.formstack.com/forms/?1760287-AfOZDCCqwk

System Administrator
192.168.0.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

MEDDELELSER

[System Administrator]

Du har overskredet opbevaring grænse på din postkasse. Du vil ikke være i
stand til at sende eller modtage ny post, indtil du opgraderer din e
kvote.

Kopier nedenstående link og udfylde formularen for at opgradere din konto.

https://www.formstack.com/forms/?1760287-AfOZDCCqwk

System Administrator
192.168.0.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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

 If not debugfs you can use devmem2[1] to read from userspace. You need
 to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

 Okay. We need to monitor how sysboot values are changing between these
 steps.

devmem from busybox seems to work better. At least it delivers real
values and not 0x0 as devmem2 does. Anyway the value doesn't change
and looks as configured via resistors:

# devmem 0x44E10040 32
0x00400304

I wonder, where can I issue NAND reset from userspace? This is one of
the commands the kernel does during the initialization.

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

MEDDELELSER

[System Administrator]

Du har overskredet opbevaring grænse på din postkasse. Du vil ikke være i
stand til at sende eller modtage ny post, indtil du opgraderer din e
kvote.

Kopier nedenstående link og udfylde formularen for at opgradere din konto.

https://www.formstack.com/forms/?1760287-AfOZDCCqwk

System Administrator
192.168.0.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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote:
 Hi,

 On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 Can you try to get XIP out of the boot sequence and see if it works?
 Maybe try to boot from mmc directly?

 This would prove that NAND/GPMC driver is leaving some state that doesn't
 go well with the bootROM XIP.

This configuration is soldered. It won't be easy to change.

Yegor
--
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: am335x: system doesn't reboot after flashing NAND

[Roger Quadros]

On 06/04/2014 12:39 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

 If not debugfs you can use devmem2[1] to read from userspace. You need
 to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

 Okay. We need to monitor how sysboot values are changing between these
 steps.
 
 devmem from busybox seems to work better. At least it delivers real
 values and not 0x0 as devmem2 does. Anyway the value doesn't change
 and looks as configured via resistors:
 
 # devmem 0x44E10040 32
 0x00400304
 
 I wonder, where can I issue NAND reset from userspace? This is one of
 the commands the kernel does during the initialization.

I'm not sure about external NAND chip, does it have a RESET via GPIO?
However, you can reset the whole GPMC module via the
GPMC_SYSCONFIG. You could try to do that in the driver .shutdown path.

I'm not sure how this will help the hardreset case as hardware should reset
the GPMC module during a hardreset.

Note that in the hwmod config, (mach-omap2/omap_hwmod_3xxx_data.c)
we set HWMOD_INIT_NO_RESET. it means that the kernel will never reset
the GPMC module during boot up to prevent loss of GPMC configuration
set up by the bootloader.

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

Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events

[Grazvydas Ignotas]

On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
 Attempt to power off in case of critical events such as battery removal,
 over voltage events.

 There is no guarentee that we'd be in a safe scenario here, but the very
 least we can try to do is to power off the device to prevent damage to
 the system instead of just printing a message and hoping for the best.

At least battery temperature out of range does seem to happen quite
often while charging on hot summer day. I'd prefer my pandora to not
shutdown in such case, it could just stop charging instead.


 NOTE: twl4030 should attempt some form of recovery, but just depending
 on that is never a safe alternative.

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 new patch. original attempt was: https://patchwork.kernel.org/patch/4002371/

 NOTE: we dont have poweroff support yet enabled on LDP, but it just needs
 relevant dts entry.

  drivers/power/twl4030_charger.c |   26 +-
  1 file changed, 21 insertions(+), 5 deletions(-)

 diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
 index 2598c58..ed0dbd2 100644
 --- a/drivers/power/twl4030_charger.c
 +++ b/drivers/power/twl4030_charger.c
 @@ -22,6 +22,7 @@
  #include linux/power_supply.h
  #include linux/notifier.h
  #include linux/usb/otg.h
 +#include linux/reboot.h
  #include linux/regulator/machine.h

  #define TWL4030_BCIMSTATEC 0x02
 @@ -332,6 +333,7 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void 
 *arg)
 struct twl4030_bci *bci = arg;
 u8 irqs1, irqs2;
 int ret;
 +   bool power_off = false;

 ret = twl_i2c_read_u8(TWL4030_MODULE_INTERRUPTS, irqs1,
   TWL4030_INTERRUPTS_BCIISR1A);
 @@ -352,20 +354,34 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void 
 *arg)
 }

 /* various monitoring events, for now we just log them here */
 -   if (irqs1  (TWL4030_TBATOR2 | TWL4030_TBATOR1))
 +   if (irqs1  (TWL4030_TBATOR2 | TWL4030_TBATOR1)) {
 dev_warn(bci-dev, battery temperature out of range\n);
 +   power_off = true;
 +   }

 -   if (irqs1  TWL4030_BATSTS)
 +   if (irqs1  TWL4030_BATSTS) {
 dev_crit(bci-dev, battery disconnected\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_VBATOV)
 +   if (irqs2  TWL4030_VBATOV) {
 dev_crit(bci-dev, VBAT overvoltage\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_VBUSOV)
 +   if (irqs2  TWL4030_VBUSOV) {
 dev_crit(bci-dev, VBUS overvoltage\n);
 +   power_off = true;
 +   }

 -   if (irqs2  TWL4030_ACCHGOV)
 +   if (irqs2  TWL4030_ACCHGOV) {
 dev_crit(bci-dev, Ac charger overvoltage\n);
 +   power_off = true;
 +   }
 +
 +   /* Try to shutdown the system */
 +   if (power_off)
 +   orderly_poweroff(true);

 return IRQ_HANDLED;
  }
 --
 1.7.9.5


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Gražvydas
--
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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 11:49 AM, Roger Quadros rog...@ti.com wrote:
 On 06/04/2014 12:39 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

 If not debugfs you can use devmem2[1] to read from userspace. You need
 to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

 Okay. We need to monitor how sysboot values are changing between these
 steps.

 devmem from busybox seems to work better. At least it delivers real
 values and not 0x0 as devmem2 does. Anyway the value doesn't change
 and looks as configured via resistors:

 # devmem 0x44E10040 32
 0x00400304

 I wonder, where can I issue NAND reset from userspace? This is one of
 the commands the kernel does during the initialization.

 I'm not sure about external NAND chip, does it have a RESET via GPIO?

No.

 However, you can reset the whole GPMC module via the
 GPMC_SYSCONFIG. You could try to do that in the driver .shutdown path.

devmem 0x5010 32 0x0002

doesn't help.

 I'm not sure how this will help the hardreset case as hardware should reset
 the GPMC module during a hardreset.

 Note that in the hwmod config, (mach-omap2/omap_hwmod_3xxx_data.c)
 we set HWMOD_INIT_NO_RESET. it means that the kernel will never reset
 the GPMC module during boot up to prevent loss of GPMC configuration
 set up by the bootloader.

O.K.
--
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: am335x: system doesn't reboot after flashing NAND

[Sekhar Nori]

On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote:
 Hi,

 On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 Can you try to get XIP out of the boot sequence and see if it works?
 Maybe try to boot from mmc directly?

 This would prove that NAND/GPMC driver is leaving some state that doesn't
 go well with the bootROM XIP.
 
 This configuration is soldered. It won't be easy to change.

Most likely XIP is the issue if sysboot has not changed.

The way ROM works for XIP boot is:

1) Set chip select 0 base address to 0x0800'
2) Read memory at 0x0800'
3) If something else other than 0x0 or ~0x0 is found, jump to
0x0800' and start executing.

Can you check to see the contents of 0x0800' before and after nand
write using mtdblock?

Thanks,
Sekhar


--
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: am335x: system doesn't reboot after flashing NAND

[Roger Quadros]

On 06/04/2014 01:07 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 11:49 AM, Roger Quadros rog...@ti.com wrote:
 On 06/04/2014 12:39 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

 If not debugfs you can use devmem2[1] to read from userspace. You need
 to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

 Okay. We need to monitor how sysboot values are changing between these
 steps.

 devmem from busybox seems to work better. At least it delivers real
 values and not 0x0 as devmem2 does. Anyway the value doesn't change
 and looks as configured via resistors:

 # devmem 0x44E10040 32
 0x00400304

 I wonder, where can I issue NAND reset from userspace? This is one of
 the commands the kernel does during the initialization.

 I'm not sure about external NAND chip, does it have a RESET via GPIO?
 
 No.

OK. it seems the NAND chip can only be reset via the RESET command.

e.g. from the driver.
nand_chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);

but still it is unclear what really is the difference between
direct write to /dev/mtdblock vs filesystem write to rootfs.

does doing a sync before the reboot help? Just to make sure there are no
pending operations when the reboot happens.

cheers,
-roger

 
 However, you can reset the whole GPMC module via the
 GPMC_SYSCONFIG. You could try to do that in the driver .shutdown path.
 
 devmem 0x5010 32 0x0002
 
 doesn't help.
 
 I'm not sure how this will help the hardreset case as hardware should reset
 the GPMC module during a hardreset.

 Note that in the hwmod config, (mach-omap2/omap_hwmod_3xxx_data.c)
 we set HWMOD_INIT_NO_RESET. it means that the kernel will never reset
 the GPMC module during boot up to prevent loss of GPMC configuration
 set up by the bootloader.
 
 O.K.
 

--
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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote:
 Hi,

 On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 Can you try to get XIP out of the boot sequence and see if it works?
 Maybe try to boot from mmc directly?

 This would prove that NAND/GPMC driver is leaving some state that doesn't
 go well with the bootROM XIP.

 This configuration is soldered. It won't be easy to change.

 Most likely XIP is the issue if sysboot has not changed.

 The way ROM works for XIP boot is:

 1) Set chip select 0 base address to 0x0800'
 2) Read memory at 0x0800'
 3) If something else other than 0x0 or ~0x0 is found, jump to
 0x0800' and start executing.

 Can you check to see the contents of 0x0800' before and after nand
 write using mtdblock?

Before writing:

# devmem 0x0800 32
0x

After writing:

# devmem 0x0800 32
0xE0E0E0E0

And I can't change it via devmem afterwards.

Yegor
--
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: am335x: system doesn't reboot after flashing NAND

[Sekhar Nori]

On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote:
 Hi,

 On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 Can you try to get XIP out of the boot sequence and see if it works?
 Maybe try to boot from mmc directly?

 This would prove that NAND/GPMC driver is leaving some state that doesn't
 go well with the bootROM XIP.

 This configuration is soldered. It won't be easy to change.

 Most likely XIP is the issue if sysboot has not changed.

 The way ROM works for XIP boot is:

 1) Set chip select 0 base address to 0x0800'
 2) Read memory at 0x0800'
 3) If something else other than 0x0 or ~0x0 is found, jump to
 0x0800' and start executing.

 Can you check to see the contents of 0x0800' before and after nand
 write using mtdblock?
 
 Before writing:
 
 # devmem 0x0800 32
 0x
 
 After writing:
 
 # devmem 0x0800 32
 0xE0E0E0E0

Okay, so this is the cause of failure to boot. I am not sure what
operation by NAND driver causes this value to change. Perhaps you could
bisect a bit by dumping this address at various points during the write
operation?

If you have a debugger it will become easy to do this.

Thanks,
Sekhar
--
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

MEDDELELSER

[System Administrator]

Du har overskredet opbevaring grænse på din postkasse. Du vil ikke være i
stand til at sende eller modtage ny post, indtil du opgraderer din e
kvote.

Kopier nedenstående link og udfylde formularen for at opgradere din konto.

https://www.formstack.com/forms/?1760287-AfOZDCCqwk

System Administrator
192.168.0.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: am335x: system doesn't reboot after flashing NAND

[Gupta, Pekon]

On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
[...]

 The way ROM works for XIP boot is:

 1) Set chip select 0 base address to 0x0800'
 2) Read memory at 0x0800'
 3) If something else other than 0x0 or ~0x0 is found, jump to
 0x0800' and start executing.

 Can you check to see the contents of 0x0800' before and after nand
 write using mtdblock?

 Before writing:

 # devmem 0x0800 32
 0x

 After writing:

 # devmem 0x0800 32
 0xE0E0E0E0

Okay, so this is the cause of failure to boot. I am not sure what
operation by NAND driver causes this value to change. Perhaps you could
bisect a bit by dumping this address at various points during the write
operation?

If you have a debugger it will become easy to do this.

I'm not sure, if a NAND device is connected as CS0 how is ROM code
detecting it as NOR and proceeding for an XIP read. 
As its mentioned in XIP boot process in AM335x TRM that if an invalid
boot image is found then ROM code falls back to next boot device
which is in this case MMC boot. A hung code here mean 
- XIP boot is not failing OR
- ROM code is waiting on GPMC_WAIT0 pin a part of XIP read access.
So please check if the GPMC:

(1) This may happen because GPMC pins are shared for both NOR and
   NAND so plz check conflicting pins as given in 
  AM335x TRM: Table 26-9. Pins Used for Non-Muxed NOR Boot
(Please see that GPMC_WAIT0 and GPMC_WAIT1 are pulled high on the board)

(2) Some SYSBOOT configuration might also be confusing ROM code.
 If you are using x8 NAND device, then please try with setting
 SYSBOOT[8] = 1
 SYSBOOT[11: 10] == 01 or 11 (reserved values) 
 This should fail XIP boot and make the ROM code fall back
 to next boot device which is MMC in this case.


with regards, pekon

Multimonitor support on ARM

[Sid Boyce]

I don't know if this is fixable or even considered for ARM.
I have a Lilliput 7 USB LCD that works fine on a Beaglebone White with 
the udlfb kernel module.


I started looking at the issue after a guy asked me if it also works on 
the ODROID.
For Software Defined Radio (SDR) which is of prime interest it would be 
nice to have a  portable/mobile SDR with a small keyboard/7 USB LCD or 
touchscreen, all as a compact unit.


Digging further. The Beaglebone does not have a GPU so that's probably 
why it works there and on x86_64 as it's dependent on x86.

The ODROID has a Mali400 GPU.

In /etc/modprobe.d/blacklist-framebuffer.conf
##blacklist udlfb
blacklist udl

The Lilliput came up on the ODROID with a green screen background but no 
display.


root@odroid:~# grep -i arbiter /var/log/Xorg.0.log.old
[   200.165] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card 
support


In kernels on x86_64 there is an option that is not available for ARM.
# CONFIG_VGA_ARB is not set

The files are present in the kernel but no config option, configuring it 
by hand and doing make oldconfig removes it as it depends on PCI and x86.

root@odroid:/b1/linux-3.8.13.23# ls drivers/gpu/vga
built-in.o  Kconfig  Makefile  modules.builtin  modules.order vgaarb.c  
vga_switcheroo.c


drivers/gpu/vga/Kconfig
===
config VGA_ARB
bool VGA Arbitration if EXPERT
default y
depends on (PCI  !S390)
help
  Some legacy VGA devices implemented on PCI typically have 
the same
  hard-decoded addresses as they did on ISA. When multiple PCI 
devices
  are accessed at same time they need some kind of 
coordination. Please
  see Documentation/vgaarbiter.txt for more details. Select 
this to

  enable VGA arbiter.

config VGA_ARB_MAX_GPUS
int Maximum number of GPUs
default 16
depends on VGA_ARB
help
  Reserves space in the kernel to maintain resource locking for
  multiple GPUS.  The overhead for each GPU is very small.

config VGA_SWITCHEROO
bool Laptop Hybrid Graphics - GPU switching support
depends on X86
depends on ACPI
select VGA_ARB
help
  Many laptops released in 2008/9/10 have two GPUs with a 
multiplexer
  to switch between them. This adds support for dynamic 
switching when
  X isn't running and delayed switching until the next logoff. 
This

  feature is called hybrid graphics, ATI PowerXpress, and Nvidia
  HybridPower.

Regards
Sid.

On 03/06/14 14:53, Michael Durkin wrote:

and its working on the Odrod?

On Tue, Jun 3, 2014 at 4:49 AM, Sid Boyce boyce@gmail.com wrote:

A number of years actually.


--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:21 PM, Roger Quadros rog...@ti.com wrote:
 On 06/04/2014 01:07 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 11:49 AM, Roger Quadros rog...@ti.com wrote:
 On 06/04/2014 12:39 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:54 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 01:55 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 If I just mount ubifs partition as rootfs and change some files, I
 still can perform reboot and boot from MMC again. The issue seems to
 occur only, if I write to /dev/mtdblock directly. What can affect ROM
 boot so that it doesn't follow the boot sequence?

 Writing to sysboot bits in control_status register will make ROM change
 boot sequence. Not sure why NAND driver should be changing these values.
 Can you please verify that this register is indeed modified after the
 NAND write?

 Can I read this register from userspace via debugfs? I can't find such
 entry so far.

 If not debugfs you can use devmem2[1] to read from userspace. You need
 to provide physical address of the register.

 I made another test: write to NAND and then make kexec. In this case I
 can successfully execute reboot afterwards.

 Okay. We need to monitor how sysboot values are changing between these
 steps.

 devmem from busybox seems to work better. At least it delivers real
 values and not 0x0 as devmem2 does. Anyway the value doesn't change
 and looks as configured via resistors:

 # devmem 0x44E10040 32
 0x00400304

 I wonder, where can I issue NAND reset from userspace? This is one of
 the commands the kernel does during the initialization.

 I'm not sure about external NAND chip, does it have a RESET via GPIO?

 No.

 OK. it seems the NAND chip can only be reset via the RESET command.

 e.g. from the driver.
 nand_chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);

 but still it is unclear what really is the difference between
 direct write to /dev/mtdblock vs filesystem write to rootfs.

 does doing a sync before the reboot help? Just to make sure there are no
 pending operations when the reboot happens.

No. sync returns immediately and reboot still fails.

Yegor
--
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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 1:49 PM, Gupta, Pekon pe...@ti.com wrote:
On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
 [...]

 The way ROM works for XIP boot is:

 1) Set chip select 0 base address to 0x0800'
 2) Read memory at 0x0800'
 3) If something else other than 0x0 or ~0x0 is found, jump to
 0x0800' and start executing.

 Can you check to see the contents of 0x0800' before and after nand
 write using mtdblock?

 Before writing:

 # devmem 0x0800 32
 0x

 After writing:

 # devmem 0x0800 32
 0xE0E0E0E0

Okay, so this is the cause of failure to boot. I am not sure what
operation by NAND driver causes this value to change. Perhaps you could
bisect a bit by dumping this address at various points during the write
operation?

If you have a debugger it will become easy to do this.

 I'm not sure, if a NAND device is connected as CS0 how is ROM code
 detecting it as NOR and proceeding for an XIP read.
 As its mentioned in XIP boot process in AM335x TRM that if an invalid
 boot image is found then ROM code falls back to next boot device
 which is in this case MMC boot. A hung code here mean
 - XIP boot is not failing OR
 - ROM code is waiting on GPMC_WAIT0 pin a part of XIP read access.
 So please check if the GPMC:

 (1) This may happen because GPMC pins are shared for both NOR and
NAND so plz check conflicting pins as given in
   AM335x TRM: Table 26-9. Pins Used for Non-Muxed NOR Boot
 (Please see that GPMC_WAIT0 and GPMC_WAIT1 are pulled high on the board)

The system has only 8-bit NAND

nandflash_pins_s0: nandflash_pins_s0 {
pinctrl-single,pins = 
0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /*
gpmc_ad0.gpmc_ad0 */
0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /*
gpmc_ad1.gpmc_ad1 */
0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /*
gpmc_ad2.gpmc_ad2 */
0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /*
gpmc_ad3.gpmc_ad3 */
0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
0x74 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wpn.gpmc_wpn */
0x7c (PIN_OUTPUT | MUX_MODE0)   /*
gpmc_csn0.gpmc_csn0  */
0x90 (PIN_OUTPUT | MUX_MODE0)   /*
gpmc_advn_ale.gpmc_advn_ale */
0x94 (PIN_OUTPUT | MUX_MODE0)   /*
gpmc_oen_ren.gpmc_oen_ren */
0x98 (PIN_OUTPUT | MUX_MODE0)   /*
gpmc_wen.gpmc_wen */
0x9c (PIN_OUTPUT | MUX_MODE0)   /*
gpmc_be0n_cle.gpmc_be0n_cle */
;
elm {
status = okay;
};

gpmc {
pinctrl-names = default;
pinctrl-0 = nandflash_pins_s0;
ranges = 0 0 0x0800 0x1000;   /* CS0: NAND */
status = okay;

nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;
ti,nand-xfer-type = polled;

gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 44;
gpmc,cs-wr-off-ns = 44;
gpmc,adv-on-ns = 6;
gpmc,adv-rd-off-ns = 34;
gpmc,adv-wr-off-ns = 44;
gpmc,we-on-ns = 0;
gpmc,we-off-ns = 40;
gpmc,oe-on-ns = 0;
gpmc,oe-off-ns = 54;
gpmc,access-ns = 64;
gpmc,rd-cycle-ns = 82;
gpmc,wr-cycle-ns = 82;
gpmc,wait-on-read = true;
gpmc,wait-on-write = true;
gpmc,bus-turnaround-ns = 0;
gpmc,cycle2cycle-delay-ns = 0;
gpmc,clk-activation-ns = 0;
gpmc,wait-monitoring-ns = 0;
gpmc,wr-access-ns = 40;
gpmc,wr-data-mux-bus-ns = 0;

#address-cells = 1;
#size-cells = 1;
elm_id = elm;

/* MTD partition table */
partition@0 {
   label = MLO;
reg = 0x 0x2;
};

partition@1 {
label = U-boot;
reg = 0x0002 0x001e;
};

partition@2 {
label = DTB;
reg = 0x0020 0x2;
};

partition@3 {
label = 

Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events

[Nishanth Menon]

On 06/04/2014 05:04 AM, Grazvydas Ignotas wrote:
 On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
 Attempt to power off in case of critical events such as battery removal,
 over voltage events.

 There is no guarentee that we'd be in a safe scenario here, but the very
 least we can try to do is to power off the device to prevent damage to
 the system instead of just printing a message and hoping for the best.
 
 At least battery temperature out of range does seem to happen quite
 often while charging on hot summer day. I'd prefer my pandora to not
 shutdown in such case, it could just stop charging instead.
Yeah, We could call
  twl4030_charger_enable_ac(false);
  twl4030_charger_enable_usb(bci, false);

But then, is that sufficient?
From the TRM:
7.5.8 Battery Temperature Out-of-Range Detection
Battery temperature out-of-range detection detects whether the battery
temperature is within a specific
range. Detection is possible for two temperature ranges. When the
battery temperature is not in the
2–50°C range or is in the 3–43°C range, the TBATOR1 and TBATOR2 status
bits rise and an interrupt is
generated.
This MADC monitoring function can be enabled by writing to the
TBATOR1EN (BCIMFEN2[3]) and
TBATOR2EN (BCIMFEN2[1]) fields.

Battery pack at high temperature is a risk, no? and it may not be just
charger that might be causing such a condition. Is'nt it safer to shut
the device down in such a case?

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

Re: [PATCH 3/6] mfd: twl4030-power: Add generic reset configuration

[Matthias Brugger]

2014-05-27 20:08 GMT+02:00 Tony Lindgren t...@atomide.com:
 The twl4030 PMIC needs to be configured properly for things like
 warm reset and deeper idle states so the PMIC manages the regulators
 properly based on the hardware triggers from the SoC. Earlier
 we have configured twl4030 using platform data, but we want to
 do it for device tree based booting also.

 In some cases configuring twl4030 is needed for things to work.
 For example, when rebooting an OMAP3530 at 125 MHz, it hangs.
 With this patch, TWL4030 will be reset when a warm reset occures,
 and OMAP3530 does not hang on reboot.

 Let's add device tree support and configure things for warm reset
 as the default when compatible = ti,twl4030-power. More
 complicated configurations can be added to the driver based on
 other compatible flags.

 Note we now also make the pdata const like it should be.
 This allows use it for match-data with the device tree
 related functions.

 Based on earlier patch by Matthias Brugger matthias@gmail.com
 and Lesly A M lesl...@ti.com.

 Cc: Matthias Brugger matthias@gmail.com
 Cc: Robert Nelson robertcnel...@gmail.com
 Cc: Peter De Schrijver pdeschrij...@nvidia.com
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  .../devicetree/bindings/mfd/twl4030-power.txt  |   7 +-
  drivers/mfd/twl4030-power.c| 109 
 ++---
  include/linux/i2c/twl.h|   3 +
  3 files changed, 105 insertions(+), 14 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt 
 b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 index 8e15ec3..b906116 100644
 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
 @@ -5,7 +5,12 @@ to control the power resources, including power scripts. For 
 now, the
  binding only supports the complete shutdown of the system after poweroff.

  Required properties:
 -- compatible : must be ti,twl4030-power
 +- compatible : must be one of the following
 +   ti,twl4030-power
 +   ti,twl4030-power-reset
 +
 +The use of ti,twl4030-power-reset is recommended at least on
 +3530 that needs a special configuration for warm reset to work.

  Optional properties:
  - ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF 
 or
 diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
 index 0b037dc..cb5b0cb 100644
 --- a/drivers/mfd/twl4030-power.c
 +++ b/drivers/mfd/twl4030-power.c
 @@ -29,6 +29,7 @@
  #include linux/i2c/twl.h
  #include linux/platform_device.h
  #include linux/of.h
 +#include linux/of_device.h

  #include asm/mach-types.h

 @@ -128,6 +129,40 @@ static u8 res_config_addrs[] = {
 [RES_MAIN_REF]  = 0x94,
  };

 +/*
 + * Usable values for .remap_sleep and .remap_off
 + * Based on table 5.3.3 Resource Operating modes
 + */
 +enum {
 +   TWL_REMAP_OFF = 0,
 +   TWL_REMAP_SLEEP = 8,
 +   TWL_REMAP_ACTIVE = 9,

Do we really need remap active?
As far as I can see it's not used anywhere.

 +};
 +
 +/*
 + * Macros to configure the PM register states for various resources.
 + * Note that we can make MSG_SINGULAR etc private to this driver once
 + * omap3 has been made DT only.
 + */
 +#define TWL_DFLT_DELAY 2   /* typically 2 32 KiHz cycles */
 +#define TWL_RESOURCE_SET(res, state)   \
 +   { MSG_SINGULAR(DEV_GRP_NULL, (res), (state)), TWL_DFLT_DELAY }
 +#define TWL_RESOURCE_ON(res)   TWL_RESOURCE_SET(res, RES_STATE_ACTIVE)
 +#define TWL_RESOURCE_OFF(res)  TWL_RESOURCE_SET(res, RES_STATE_OFF)
 +#define TWL_RESOURCE_RESET(res)TWL_RESOURCE_SET(res, RES_STATE_WRST)
 +/*
 + * It seems that type1 and type2 is just the resource init order
 + * number for the type1 and type2 group.
 + */
 +#define TWL_RESOURCE_GROUP_RESET(group, type1, type2)  \
 +   { MSG_BROADCAST(DEV_GRP_NULL, (group), (type1), (type2),\
 +   RES_STATE_WRST), TWL_DFLT_DELAY }
 +#define TWL_REMAP_SLEEP(res, devgrp, typ, typ2)  
   \
 +   { .resource = (res), .devgroup = (devgrp),  \
 + .type = (typ), .type2 = (typ2),   \
 + .remap_off = TWL_REMAP_OFF,   \
 + .remap_sleep = TWL_REMAP_SLEEP, }
 +
  static int twl4030_write_script_byte(u8 address, u8 byte)
  {
 int err;
 @@ -502,7 +537,8 @@ int twl4030_remove_script(u8 flags)
 return err;
  }

 -static int twl4030_power_configure_scripts(struct twl4030_power_data *pdata)
 +static int
 +twl4030_power_configure_scripts(const struct twl4030_power_data *pdata)
  {
 int err;
 int i;
 @@ -518,7 +554,8 @@ static int twl4030_power_configure_scripts(struct 
 twl4030_power_data *pdata)
 return 0;
  }

 -static int 

Re: [PATCH 2/2] gpio: of: Allow -gpio suffix for property names

[Thierry Reding]

On Mon, Jun 02, 2014 at 04:14:23PM -0700, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [140602 16:06]:
  * Linus Walleij linus.wall...@linaro.org [140425 00:53]:
   On Wed, Apr 23, 2014 at 5:28 PM, Thierry Reding
   thierry.red...@gmail.com wrote:
   
From: Thierry Reding tred...@nvidia.com
   
Many bindings use the -gpio suffix in property names. Support this in
addition to the -gpios suffix when requesting GPIOs using the new
descriptor-based API.
   
Signed-off-by: Thierry Reding tred...@nvidia.com
   
   It appears this can save quite a lot of code in drivers, work that
   I trust Thierry to persue based on this to some extent so patch is
   tentatively applied unless something comes up.
  
  Looks like this patch causes a regression where GPIOs on I2C will
  no longer return -EPROBE_DEFER but seem to return -ENOENT instead.
  
  This breaks drivers using things like devm_gpiod_get_index()
  on a GPIO that's on a I2C bus not probed yet.
  
  Reverting commit dd34c37aa3e (gpio: of: Allow -gpio suffix for
  property names) fixes things.
 
 Looks like something like below fixes the issue.
 
 Regards,
 
 Tony
 
 8 ---
 From: Tony Lindgren t...@atomide.com
 Date: Mon, 2 Jun 2014 16:13:46 -0700
 Subject: [PATCH] gpio: of: Fix handling for deferred probe for -gpio suffix
 
 Commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names)
 added parsing for both -gpio and -gpios suffix but also changed
 the handling for deferred probe unintentionally. Because of the
 looping the second name will now return -ENOENT instead of
 -EPROBE_DEFER. Fix the issue by breaking out of the loop if
 -EPROBE_DEFER is encountered.
 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 --- a/drivers/gpio/gpiolib.c
 +++ b/drivers/gpio/gpiolib.c
 @@ -2614,7 +2614,7 @@ static struct gpio_desc *of_find_gpio(struct device 
 *dev, const char *con_id,
  
   desc = of_get_named_gpiod_flags(dev-of_node, prop_name, idx,
   of_flags);
 - if (!IS_ERR(desc))
 + if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
   break;
   }

This looks good to me:

Reviewed-by: Thierry Reding tred...@nvidia.com


pgpM5lu5mabwx.pgp
Description: PGP signature

Re: [RFC PATCH 00/11] Embeddable Position Independent Executable

[Pascal Hürst]

Hi Ru

On 22.04.2014 10:15, Heiko Stübner wrote:

Hi Russ,

Am Donnerstag, 24. Oktober 2013, 10:09:12 schrieb Heiko Stübner:

Am Dienstag, 17. September 2013, 14:43:26 schrieb Russ Dill:

This patch adds support for and demonstrates the usage of an embedded
position independent executable (PIE). The goal is to allow the use of C
code in situations where carefully written position independent assembly
was previously required.


As suggested yesterday evening by Kevin Hilman, just adding my 2ct of
support.

This series looks exactly like the foundation I'll need at some point in the
(probably still distant) future to handle suspend on my Rockchip platform -
where like in your example stuff like putting the ram into selfrefresh has
to be done by the os.


just as it came up recently again for me and I couldn't find any newer version,
ist this series still on the table?


We have to maintain quite some patches, to keep pm working for our 
project, so we're interested to get this mainline, too. Is someone 
taking care of these issues? Or is there something i can do to help 
getting this done?


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

[PATCH] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()

[Rostislav Lisovy]

GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.

Signed-off-by: Rostislav Lisovy lis...@merica.cz
---

Tested on custom AM335x board with two different NAND chips
(128 + 256 MiB) using GPMC configuration in FDT -- behaves
correctly.


 arch/arm/mach-omap2/gpmc-nand.c | 79 +++--
 1 file changed, 37 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..c5481a8 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -24,25 +24,6 @@
 /* minimum size for IO mapping */
 #defineNAND_IO_SIZE4
 
-static struct resource gpmc_nand_resource[] = {
-   {
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .flags  = IORESOURCE_IRQ,
-   },
-   {
-   .flags  = IORESOURCE_IRQ,
-   },
-};
-
-static struct platform_device gpmc_nand_device = {
-   .name   = omap2-nand,
-   .id = 0,
-   .num_resources  = ARRAY_SIZE(gpmc_nand_resource),
-   .resource   = gpmc_nand_resource,
-};
-
 static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
/* platforms which support all ECC schemes */
@@ -93,43 +74,41 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
 {
int err = 0;
struct gpmc_settings s;
-   struct device *dev = gpmc_nand_device.dev;
-
-   memset(s, 0, sizeof(struct gpmc_settings));
+   struct platform_device *pdev;
+   struct resource gpmc_nand_res[] = {
+   { .flags = IORESOURCE_MEM, },
+   { .flags = IORESOURCE_IRQ, },
+   { .flags = IORESOURCE_IRQ, },
+   };
 
-   gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+   BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
 
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
-   (unsigned long *)gpmc_nand_resource[0].start);
+ (unsigned long *)gpmc_nand_res[0].start);
if (err  0) {
-   dev_err(dev, Cannot request GPMC CS %d, error %d\n,
-   gpmc_nand_data-cs, err);
+   pr_err(omap2-gpmc: Cannot request GPMC CS %d, error %d\n,
+  gpmc_nand_data-cs, err);
return err;
}
-
-   gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
-   NAND_IO_SIZE - 1;
-
-   gpmc_nand_resource[1].start =
-   gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
-   gpmc_nand_resource[2].start =
-   gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+   gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
+   gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+   gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
 
if (gpmc_t) {
err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err  0) {
-   dev_err(dev, Unable to set gpmc timings: %d\n, err);
+   pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n, 
err);
return err;
}
}
 
+   memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
else
gpmc_set_legacy(gpmc_nand_data, s);
 
s.device_nand = true;
-
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err  0)
goto out_free_cs;
@@ -141,18 +120,34 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
 
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
-   dev_err(dev, Unsupported NAND ECC scheme selected\n);
-   return -EINVAL;
+   pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
+   err = -EINVAL;
+   goto out_free_cs;
}
 
-   err = platform_device_register(gpmc_nand_device);
-   if (err  0) {
-   dev_err(dev, Unable to register NAND device\n);
-   goto out_free_cs;
+
+   pdev = platform_device_alloc(omap2-nand, gpmc_nand_data-cs);
+   if (pdev) {
+   err = platform_device_add_resources(pdev, gpmc_nand_res,
+   ARRAY_SIZE(gpmc_nand_res));
+   if (!err)
+   pdev-dev.platform_data = gpmc_nand_data;
+   } else {
+ 

Re: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)

[Nishanth Menon]

Minor change in subject, +Keerthy.

On 10:01-20140604, Mark Brown wrote:
 On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
  On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter bu...@lixom.net wrote:
 
   [2.816920] smps9: failed to get the current voltage
 
  This seems to be from palmas registration failing, which in turns
  causes vmmc regulator lookup to fail. See the errors about palmas-pmic
  above.
 
 Always CC maintainers on things.  This is a bug in the driver, it needs
 to support retrieving voltages at all times (and would probably run into
 trouble anyway).
Full thread: http://marc.info/?t=14018453804r=1w=2

Yeah, this does seems to be a regression. The following is based on
next-20140604.

Seems to help my OMAP5uevm.
If this makes sense, I will repost it as a formal patch.

8
From 3feaa7f5c749b1673aef3fd26f43b965dd627dc9 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 4 Jun 2014 14:09:09 -0500
Subject: [PATCH] regulator: palmas: Fix SMPS list for 0V

get_voltage_sel reads from SMPS register - if the read selector value
is 0, the SMPS is actually disabled - So, this is in addition to the
ctrl_register that may also be used to enable/disable the SMPS.

The original logic(prior to commit dbabd624d4eec50b6) used to be:
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
   int min_uV, int max_uV)
snip
   if (min_uV == 0)
   return 0;

To handle this scenario, with the transition to regulator_list
implementation, we seem to have missed the data necessary to mark as
one of the valid entries as 0 'disabled regulator' which results in
0 volts - So, stick with pre-existing logic.

Without this added to the list, palmas regulator driver,
on probe, attempts to setup constraints and in the case of
OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in
regulator_list_voltage_linear_range mapping of '0', and as a fall back
of constraints not being applied, the entire regulator list is not
enumerated due to assumption that something system wide has gone bad
on with the PMIC.

Fixes: dbabd624d4eec50b6 (regulator: palmas: Reemove open coded functions with 
helper functions)
Reported-by: Olof Johansson o...@lixom.net
Signed-off-by: Nishanth Menon n...@ti.com
---
 drivers/regulator/palmas-regulator.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 864ed02..b982f0f 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -37,12 +37,14 @@ struct regs_info {
 };
 
 static const struct regulator_linear_range smps_low_ranges[] = {
+   REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
REGULATOR_LINEAR_RANGE(51, 0x7, 0x79, 1),
REGULATOR_LINEAR_RANGE(165, 0x7A, 0x7f, 0),
 };
 
 static const struct regulator_linear_range smps_high_ranges[] = {
+   REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
REGULATOR_LINEAR_RANGE(100, 0x1, 0x6, 0),
REGULATOR_LINEAR_RANGE(102, 0x7, 0x79, 2),
REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
-- 
1.7.9.5


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

Re: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Olof Johansson]

On Wed, Jun 4, 2014 at 2:01 AM, Mark Brown broo...@kernel.org wrote:
 On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
 On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter bu...@lixom.net wrote:

  [2.816920] smps9: failed to get the current voltage

 This seems to be from palmas registration failing, which in turns
 causes vmmc regulator lookup to fail. See the errors about palmas-pmic
 above.

 Always CC maintainers on things.

What maintainer did I not cc? I missed the linux-omap list but I
included you and Tony.


-Olof
--
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: am335x: system doesn't reboot after flashing NAND

[Yegor Yefremov]

On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote:
 Hi,

 On 06/04/2014 11:25 AM, Yegor Yefremov wrote:
 On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote:
 On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote:
 On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 Kernel: 3.14, 3.15 (I haven't tried another kernels)

 As soon as I write something to my NAND flash (via cat image 
 /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset
 button, I see only C and nothing happens before I make a power
 cycle. Any idea?

 Just forgot to mention, that I was actually booting from MMC (mmc1).
 The boot sequence is UART0...XIP...MMC0...NAND.

 Can you try to get XIP out of the boot sequence and see if it works?
 Maybe try to boot from mmc directly?

 This would prove that NAND/GPMC driver is leaving some state that doesn't
 go well with the bootROM XIP.

 This configuration is soldered. It won't be easy to change.

 Most likely XIP is the issue if sysboot has not changed.

 The way ROM works for XIP boot is:

 1) Set chip select 0 base address to 0x0800'
 2) Read memory at 0x0800'
 3) If something else other than 0x0 or ~0x0 is found, jump to
 0x0800' and start executing.

 Can you check to see the contents of 0x0800' before and after nand
 write using mtdblock?

 Before writing:

 # devmem 0x0800 32
 0x

 After writing:

 # devmem 0x0800 32
 0xE0E0E0E0

 Okay, so this is the cause of failure to boot. I am not sure what
 operation by NAND driver causes this value to change. Perhaps you could
 bisect a bit by dumping this address at various points during the write
 operation?

 If you have a debugger it will become easy to do this.

The 0x8000 address seems to be the beginning of NAND region:

ranges = 0 0 0x0800 0x1000;   /* CS0: NAND */

I've taken this example from am335x_evm.dts. I have tried to change
the mapping to 0x9000, but kernel still uses 0x8000, Where in
the kernel will ranges be evaluated? I'm digging thorugh
arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found
the place.

Yegor
--
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] regulator: core: print error value when constraints are not applied

[Nishanth Menon]

With commit 064d5cd110f94ce41ca5681dcda8b77fa63d5b95
(regulator: core: Fix the init of DT defined fixed regulators)
We ensure that regulator must be capable of providing it's current
voltage when constraints are used, however adding the return value in
the print is a little more informative to explain the nature of the
failure involved.

So, instead of providing message such as:
smps9: failed to get the current voltage

having error value added to the message such as:
smps9: failed to get the current voltage(-22)

is a little more informative for debugging the error.

Signed-off-by: Nishanth Menon n...@ti.com
---
 drivers/regulator/core.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 4c1f999..b4902ab 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -846,7 +846,9 @@ static int machine_constraints_voltage(struct regulator_dev 
*rdev,
rdev-constraints-min_uV == rdev-constraints-max_uV) {
int current_uV = _regulator_get_voltage(rdev);
if (current_uV  0) {
-   rdev_err(rdev, failed to get the current voltage\n);
+   rdev_err(rdev,
+failed to get the current voltage(%d)\n,
+current_uV);
return current_uV;
}
if (current_uV  rdev-constraints-min_uV ||
@@ -856,8 +858,8 @@ static int machine_constraints_voltage(struct regulator_dev 
*rdev,
rdev-constraints-max_uV);
if (ret  0) {
rdev_err(rdev,
-   failed to apply %duV constraint\n,
-   rdev-constraints-min_uV);
+   failed to apply %duV constraint(%d)\n,
+   rdev-constraints-min_uV, ret);
return ret;
}
}
-- 
1.7.9.5

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

Re: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)

[Mark Brown]

On Wed, Jun 04, 2014 at 02:34:31PM -0500, Nishanth Menon wrote:

 Seems to help my OMAP5uevm.
 If this makes sense, I will repost it as a formal patch.

Yes, this makes sense - there was a similar issue with one of the other
drivers.


signature.asc
Description: Digital signature

Re: mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Mark Brown]

On Wed, Jun 04, 2014 at 12:37:52PM -0700, Olof Johansson wrote:
 On Wed, Jun 4, 2014 at 2:01 AM, Mark Brown broo...@kernel.org wrote:

  Always CC maintainers on things.

 What maintainer did I not cc? I missed the linux-omap list but I
 included you and Tony.

Liam mainly.


signature.asc
Description: Digital signature

Re: [PATCH V2 2/2] power: twl4030_charger: attempt to power off in case of critical events

[Grazvydas Ignotas]

On Wed, Jun 4, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote:
 On 06/04/2014 05:04 AM, Grazvydas Ignotas wrote:
 On Thu, May 29, 2014 at 12:46 AM, Nishanth Menon n...@ti.com wrote:
 Attempt to power off in case of critical events such as battery removal,
 over voltage events.

 There is no guarentee that we'd be in a safe scenario here, but the very
 least we can try to do is to power off the device to prevent damage to
 the system instead of just printing a message and hoping for the best.

 At least battery temperature out of range does seem to happen quite
 often while charging on hot summer day. I'd prefer my pandora to not
 shutdown in such case, it could just stop charging instead.
 Yeah, We could call
   twl4030_charger_enable_ac(false);
   twl4030_charger_enable_usb(bci, false);

 But then, is that sufficient?
 From the TRM:
 7.5.8 Battery Temperature Out-of-Range Detection
 Battery temperature out-of-range detection detects whether the battery
 temperature is within a specific
 range. Detection is possible for two temperature ranges. When the
 battery temperature is not in the
 2–50°C range or is in the 3–43°C range, the TBATOR1 and TBATOR2 status
 bits rise and an interrupt is
 generated.
 This MADC monitoring function can be enabled by writing to the
 TBATOR1EN (BCIMFEN2[3]) and
 TBATOR2EN (BCIMFEN2[1]) fields.

 Battery pack at high temperature is a risk, no? and it may not be just
 charger that might be causing such a condition. Is'nt it safer to shut
 the device down in such a case?

I don't know, so far nobody has complained about the battery exploding
and anybody getting hurt, but it would make the device unusable for
people in hot climates. From what I remember the automatic charge is
stopped automatically on this condition, as some people complained
they couldn't charge their device and saw these messages in dmesg. I
guess mainline could choose the safer option and shutdown, no strong
opinion about this.

-- 
Gražvydas
--
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] hsi: omap_ssi_port: use normal module refcounting

[Sebastian Reichel]

Hi,

On Wed, Jun 04, 2014 at 10:00:59AM +0200, Arnd Bergmann wrote:
 The ref_module() function is used for internal housekeeping of the
 module code, it's not normally used by subsystems or device drivers,
 and the use of ref_module in the omap_ssi_port driver causes a link
 build error when modules are disabled:
 
 hsi/controllers/omap_ssi_port.c: In function 'ssi_port_probe':
 hsi/controllers/omap_ssi_port.c:1119:2: error: implicit declaration of 
 function 'ref_module' [-Werror=implicit-function-declaration]
 
 This changes the omap_ssi_port driver to use try_module_get()
 and module_put() instead, which is the normal way to ensure that
 the driver providing a device used in another module does not
 go away.

Thanks, applied:

https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/commit/?h=for-nextid=b357d7b58f379ebe8038cd97b6204f2f5c52220d

-- Sebastian


signature.asc
Description: Digital signature