Re: debugging

[Ryan]

Hi Felipe,

On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>
> Hi,
>
> (please avoid top-posting)
>
> Ryan  writes:
>> Hi Tony,
>>
>> Thanks for your response. I dont see any prints. I suspect that it
>> might be hanging before the serial port is initialized
>>
>> All i see is after arch_reset is called. I can see that is mmc clk and
>> data signals toggling. This makes me think that boot rom has loaded
>> the xloader into sram.
>
> you might wanna consider openocd if your jtag interface is available
> somewhere on your pcb. Just keep in mind that you might have to fiddle a
> bit with some TCL config files to get openocd to behave correctly with
> your board.
>

I managed to connect a lauterbach debugger. to my target. This is what
i did to test

1. reset the board.  & stop at u-boot prompt
2. Do a system.attach on the T32 (Lauterbach says that system is ready)
3. I do a run on the T32. I see that the status changes on T32 to run.
4. Now, i try to play with the u-boot prompt and board does not respond.

Any idea what i am doing wrong? The PC is pointing to some address
0x28000 and does not change.
I expect the PC to be some address in the RAM since mmu is off.

Also, do i need to compile the x-loader and u-boot with some special
options & how do i tell the T32 to
pick the map file for x-loader and u-boot?

Thanks you,
ryan





> cheers
>
>> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>>> * Ryan  [151209 09:03]:
 Hello,

 On a custom 4460 board. The x-loader hangs at some place when we
 reboot. This happens occasionally on an android port by linaro.

 I just want to find out how to debug in this case. How can i get to
 know where the hang takes place. After boot rom, i can see the mmc clk
 toggling
 indicating that xloader is in sram when the hang takes place and not
 sure where the hang is.

 Do i need Lauterbach to debug - Is it possible to connect the emulator
 across reboot. If so, how? or is there any other way i can debug this

 Also, i want to check - If i can turn off the dplls? If so, how?

 I tried to do a disable on all the clocks in the clock list using
 clk_disable call just before reboot and that does not seem to help.
>>>
>>> You can add selected serial print statements very early into u-boot
>>> MLO (and probably x-loader). You need to keep them down to minimum
>>> so the image still fits into SRAM. If you enable debug, then that also
>>> needs to be limited to selected files only as enabling debug for the
>>> whole MLO/x-loader in the Makefile will make it too big.
>>>
>>> Regards,
>>>
>>> Tony
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> balbi
--
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: debugging

[Felipe Balbi]

Hi,

Ryan  writes:
> Hi Felipe,
>
> On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> (please avoid top-posting)
>>
>> Ryan  writes:
>>> Hi Tony,
>>>
>>> Thanks for your response. I dont see any prints. I suspect that it
>>> might be hanging before the serial port is initialized
>>>
>>> All i see is after arch_reset is called. I can see that is mmc clk and
>>> data signals toggling. This makes me think that boot rom has loaded
>>> the xloader into sram.
>>
>> you might wanna consider openocd if your jtag interface is available
>> somewhere on your pcb. Just keep in mind that you might have to fiddle a
>> bit with some TCL config files to get openocd to behave correctly with
>> your board.
>>
>
> I managed to connect a lauterbach debugger. to my target. This is what
> i did to test
>
> 1. reset the board.  & stop at u-boot prompt
> 2. Do a system.attach on the T32 (Lauterbach says that system is ready)
> 3. I do a run on the T32. I see that the status changes on T32 to run.
> 4. Now, i try to play with the u-boot prompt and board does not
> respond.

is CPU, perhaps, halted ?

> Any idea what i am doing wrong? The PC is pointing to some address
> 0x28000 and does not change.

yeah, it's halted. I don't know much about T32, you might wanna read its
documentation, though.

> I expect the PC to be some address in the RAM since mmu is off.
>
> Also, do i need to compile the x-loader and u-boot with some special
> options & how do i tell the T32 to pick the map file for x-loader and
> u-boot?

yeah, you gotta read T32's documentation. I can't help there :-p

-- 
balbi


signature.asc
Description: PGP signature

debugging

[Ryan]

Hello,

On a custom 4460 board. The x-loader hangs at some place when we
reboot. This happens occasionally on an android port by linaro.

I just want to find out how to debug in this case. How can i get to
know where the hang takes place. After boot rom, i can see the mmc clk
toggling
indicating that xloader is in sram when the hang takes place and not
sure where the hang is.

Do i need Lauterbach to debug - Is it possible to connect the emulator
across reboot. If so, how? or is there any other way i can debug this

Also, i want to check - If i can turn off the dplls? If so, how?

I tried to do a disable on all the clocks in the clock list using
clk_disable call just before reboot and that does not seem to help.

Thank you.
ryan
--
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: debugging

[Ryan]

Hi Tony,

Thanks for your response. I dont see any prints. I suspect that it
might be hanging before the serial port is initialized
All i see is after arch_reset is called. I can see that is mmc clk and
data signals toggling. This makes me think that
 boot rom has loaded the xloader into sram.

Thanks,



On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
> * Ryan  [151209 09:03]:
>> Hello,
>>
>> On a custom 4460 board. The x-loader hangs at some place when we
>> reboot. This happens occasionally on an android port by linaro.
>>
>> I just want to find out how to debug in this case. How can i get to
>> know where the hang takes place. After boot rom, i can see the mmc clk
>> toggling
>> indicating that xloader is in sram when the hang takes place and not
>> sure where the hang is.
>>
>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>> across reboot. If so, how? or is there any other way i can debug this
>>
>> Also, i want to check - If i can turn off the dplls? If so, how?
>>
>> I tried to do a disable on all the clocks in the clock list using
>> clk_disable call just before reboot and that does not seem to help.
>
> You can add selected serial print statements very early into u-boot
> MLO (and probably x-loader). You need to keep them down to minimum
> so the image still fits into SRAM. If you enable debug, then that also
> needs to be limited to selected files only as enabling debug for the
> whole MLO/x-loader in the Makefile will make it too big.
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Felipe Balbi]

Hi,

(please avoid top-posting)

Ryan  writes:
> Hi Tony,
>
> Thanks for your response. I dont see any prints. I suspect that it
> might be hanging before the serial port is initialized
>
> All i see is after arch_reset is called. I can see that is mmc clk and
> data signals toggling. This makes me think that boot rom has loaded
> the xloader into sram.

you might wanna consider openocd if your jtag interface is available
somewhere on your pcb. Just keep in mind that you might have to fiddle a
bit with some TCL config files to get openocd to behave correctly with
your board.

cheers

> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>> * Ryan  [151209 09:03]:
>>> Hello,
>>>
>>> On a custom 4460 board. The x-loader hangs at some place when we
>>> reboot. This happens occasionally on an android port by linaro.
>>>
>>> I just want to find out how to debug in this case. How can i get to
>>> know where the hang takes place. After boot rom, i can see the mmc clk
>>> toggling
>>> indicating that xloader is in sram when the hang takes place and not
>>> sure where the hang is.
>>>
>>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>>> across reboot. If so, how? or is there any other way i can debug this
>>>
>>> Also, i want to check - If i can turn off the dplls? If so, how?
>>>
>>> I tried to do a disable on all the clocks in the clock list using
>>> clk_disable call just before reboot and that does not seem to help.
>>
>> You can add selected serial print statements very early into u-boot
>> MLO (and probably x-loader). You need to keep them down to minimum
>> so the image still fits into SRAM. If you enable debug, then that also
>> needs to be limited to selected files only as enabling debug for the
>> whole MLO/x-loader in the Makefile will make it too big.
>>
>> Regards,
>>
>> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: debugging

[Tony Lindgren]

* Ryan  [151209 09:03]:
> Hello,
> 
> On a custom 4460 board. The x-loader hangs at some place when we
> reboot. This happens occasionally on an android port by linaro.
> 
> I just want to find out how to debug in this case. How can i get to
> know where the hang takes place. After boot rom, i can see the mmc clk
> toggling
> indicating that xloader is in sram when the hang takes place and not
> sure where the hang is.
> 
> Do i need Lauterbach to debug - Is it possible to connect the emulator
> across reboot. If so, how? or is there any other way i can debug this
> 
> Also, i want to check - If i can turn off the dplls? If so, how?
> 
> I tried to do a disable on all the clocks in the clock list using
> clk_disable call just before reboot and that does not seem to help.

You can add selected serial print statements very early into u-boot
MLO (and probably x-loader). You need to keep them down to minimum
so the image still fits into SRAM. If you enable debug, then that also
needs to be limited to selected files only as enabling debug for the
whole MLO/x-loader in the Makefile will make it too big.

Regards,

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

[PATCH v3 07/10] dmaengine: edma: Reduce debug print verbosity for non verbose debugging

[Peter Ujfalusi]

Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2f58c04cbcb1..6d9edc47150d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i  nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-   dev_dbg(echan-vchan.chan.device-dev,
+   dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
@@ -560,9 +560,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
 
-   dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-   dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-   dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+   dev_dbg(dev, %s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n,
+   __func__, echan-ch_num, nslots, period_len, buf_len);
 
for (i = 0; i  nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -596,8 +595,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
 
-   dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-   dev_dbg(dev,
+   dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+   dev_vdbg(dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
-- 
1.9.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 v2 11/14] dma: edma: Reduce debug print verbosity for non verbose debugging

[Peter Ujfalusi]

Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d954099650ae..e8de2e84a60a 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i  nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-   dev_dbg(echan-vchan.chan.device-dev,
+   dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
@@ -558,9 +558,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
 
-   dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-   dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-   dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+   dev_dbg(dev, %s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n,
+   __func__, echan-ch_num, nslots, period_len, buf_len);
 
for (i = 0; i  nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -594,8 +593,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
 
-   dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-   dev_dbg(dev,
+   dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+   dev_vdbg(dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
-- 
1.9.1

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

[PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging

[Peter Ujfalusi]

Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e4f4a0cef58c..e2aa42b8342f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i  nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-   dev_dbg(echan-vchan.chan.device-dev,
+   dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
@@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
 
-   dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-   dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-   dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+   dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
+   __func__, echan-ch_num, nslots, period_len, buf_len);
 
for (i = 0; i  nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
 
-   dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-   dev_dbg(dev,
+   dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+   dev_vdbg(dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
-- 
1.9.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: [PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging

[Shevchenko, Andriy]

On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
 Do not print the paRAM information when verbose debugging is not asked and
 also reduce the number of lines printed in edma_prep_dma_cyclic()
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index e4f4a0cef58c..e2aa42b8342f 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
   for (i = 0; i  nslots; i++) {
   j = i + edesc-processed;
   edma_write_slot(echan-slot[i], edesc-pset[j]);
 - dev_dbg(echan-vchan.chan.device-dev,
 + dev_vdbg(echan-vchan.chan.device-dev,
   \n pset[%d]:\n
 chnum\t%d\n
 slot\t%d\n

I believe you may move this code to separate function and reuse it
later.
Moreover %d is not good specifier for unsigned types, maybe %u?

 @@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
   edesc-cyclic = 1;
   edesc-pset_nr = nslots;
  
 - dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
 - dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
 - dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
 + dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
 + __func__, echan-ch_num, nslots, period_len, buf_len);

Consider to use proper specifiers for size_t types, namely %zd.

  
   for (i = 0; i  nslots; i++) {
   /* Allocate a PaRAM slot, if needed */
 @@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
   else
   src_addr += period_len;
  
 - dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 - dev_dbg(dev,
 + dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 + dev_vdbg(dev,

See the first comment.

   \n pset[%d]:\n
 chnum\t%d\n
 slot\t%d\n


-- 
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging

[Peter Ujfalusi]

On 03/13/2014 02:53 PM, Shevchenko, Andriy wrote:
 On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
 Do not print the paRAM information when verbose debugging is not asked and
 also reduce the number of lines printed in edma_prep_dma_cyclic()

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index e4f4a0cef58c..e2aa42b8342f 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
  for (i = 0; i  nslots; i++) {
  j = i + edesc-processed;
  edma_write_slot(echan-slot[i], edesc-pset[j]);
 -dev_dbg(echan-vchan.chan.device-dev,
 +dev_vdbg(echan-vchan.chan.device-dev,
  \n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
 
 I believe you may move this code to separate function and reuse it
 later.

As the per patch description, I only changed the debug level in this patch.

 Moreover %d is not good specifier for unsigned types, maybe %u?

You are right for unsigned type %u is the correct. This is why we have %d
since j, echan-ch_num and echan-slot[i] are integer.

 
 @@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
  edesc-cyclic = 1;
  edesc-pset_nr = nslots;
  
 -dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
 -dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
 -dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
 +dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
 +__func__, echan-ch_num, nslots, period_len, buf_len);
 
 Consider to use proper specifiers for size_t types, namely %zd.

I just collapsed the three line of dev_dbg into one and have not really
checked the formats.
For size_t the correct format should be %zu.
I'll fix this up for the next version.

  
  for (i = 0; i  nslots; i++) {
  /* Allocate a PaRAM slot, if needed */
 @@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
  else
  src_addr += period_len;
  
 -dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 -dev_dbg(dev,
 +dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 +dev_vdbg(dev,
 
 See the first comment.

As the per patch description, I only changed the debug level in this patch.
This can be done as a separate patch later IMO as part of a bigger debug 
cleanup.

-- 
Péter
--
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: debugging options (was: Re: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c)

[Russell King - ARM Linux]

Apologies for the topic hijack.

On Sat, Jul 06, 2013 at 11:36:48PM +0200, Arnd Bergmann wrote:
 Sorry, I missed that this was going on, and I absolutely agree with your
 sentiment. From what I can tell from the git log, Tegra was the first
 to have the separate choice statement, after it just move its
 options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
 with the same method and I think from there people just copied it.
 
 I can understand why one wants to have some more structure in the list,
 given that i.MX alone has 37 options for UART addresses, but we first
 need to have a consistent method of configuring the addresses.

I don't have an option with an option after the choice or a set of
options afterwards asking for details about the selected option -
that is logical.

For example, if we were to reduce the 8250-uart based stuff down to
a single 8250-compatible uart option, and then ask for the address,
register shift and register access size.

... and of course by this time I now have a patch set which does
exactly that... and it can do more by getting rid of that 8250_32.S
file as well with another config option.  The patch below tries
hard not to break anything or lose information as to the details of
the 8250 UART in any platform which they're already known to the
kernel, but they can be trivially overridden.  Eventually (maybe
tomorrow), I expect a load of the choice config statements in
arch/arm/Kconfig.debug to go away, replaced just with a generic
Kernel low-level debugging messages via 8250 UART option.

 arch/arm/Kconfig.debug |   92 ++--
 arch/arm/include/asm/hardware/debug-8250.S |   29 --
 arch/arm/include/debug/8250.S  |   36 
 arch/arm/include/debug/mvebu.S |   30 ---
 arch/arm/include/debug/nspire.S|9 +--
 arch/arm/include/debug/pxa.S   |   33 ---
 arch/arm/include/debug/rockchip.S  |   42 -
 arch/arm/include/debug/sunxi.S |   27 --
 arch/arm/mach-dove/include/mach/debug-macro.S  |   19 
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S|   21 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S|   21 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S|   22 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S|   26 --
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 --
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -
 arch/arm/mach-rpc/include/mach/debug-macro.S   |   23 -
 21 files changed, 121 insertions(+), 458 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S

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

[RFC/PATCH 30/32] usb: chipidea: register debugging syfs on our device

[Felipe Balbi]

Don't register anything non-generic under
the gadget's device as we don't really *own*
it.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/chipidea/udc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2f45bba..f64fbea 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1767,7 +1767,7 @@ static int udc_start(struct ci13xxx *ci)
goto put_transceiver;
}
 
-   retval = dbg_create_files(ci-gadget.dev);
+   retval = dbg_create_files(ci-dev);
if (retval)
goto unreg_device;
 
@@ -1796,7 +1796,7 @@ remove_trans:
 
dev_err(dev, error = %i\n, retval);
 remove_dbg:
-   dbg_remove_files(ci-gadget.dev);
+   dbg_remove_files(ci-dev);
 unreg_device:
device_unregister(ci-gadget.dev);
 put_transceiver:
@@ -1836,7 +1836,7 @@ static void udc_stop(struct ci13xxx *ci)
if (ci-global_phy)
usb_put_phy(ci-transceiver);
}
-   dbg_remove_files(ci-gadget.dev);
+   dbg_remove_files(ci-dev);
device_unregister(ci-gadget.dev);
/* my kobject is dynamic, I swear! */
memset(ci-gadget, 0, sizeof(ci-gadget));
-- 
1.8.1.rc1.5.g7e0651a

--
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: need help debugging ISP problem

[Laurent Pinchart]

Hi Adam,

On Monday 05 November 2012 16:02:08 Adam Wozniak wrote:
 I'm working with a custom board based on an Overo WaterStorm com. The
 processor is a DM3730.  The kernel is 2.6.32 based.

2.6.32 very probably means you're using the old TI driver. Please don't. 
That's buggy and totally unsupported. I advice upgrading to the latest 
mainline kernel.

 I'm trying to stress test the camera ISP by rapidly opening and closing
 the video device with ( while true; do gst-launch v4l2src
 device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 !
 ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done )
 
 After many iterations, I will see the kernel spit out:
 
 [ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028)
 at 0xfa0bce04
 [ 2502.810516] Internal error: : 1028 [#1]
 [ ... ]
 [ 2502.846893] PC is at isp_reg_readl+0x18/0x20
 [ 2502.851196] LR is at isp_reg_readl+0x10/0x20
 [ ... ]
 [ 2503.296447] [c02954a0] (isp_reg_readl+0x18/0x20) from [c02954f8]
 (isp_reg_and_or+0x1c/0x38)
 [ 2503.305206] [c02954f8] (isp_reg_and_or+0x1c/0x38) from [c029bad0]
 (isppreview_config_cfa+0x38/0x90)
 [ 2503.314666] [c029bad0] (isppreview_config_cfa+0x38/0x90) from
 [c029bc5c] (isppreview_config_datapath+0x134/0x330)
 [ 2503.325347] [c029bc5c] (isppreview_config_datapath+0x134/0x330)
 from [c029be68] (isppreview_s_pipeline+0x10/0xd0)
 [ 2503.336029] [c029be68] (isppreview_s_pipeline+0x10/0xd0) from
 [c0296e98] (isp_s_pipeline+0x1d8/0x280)
 [ 2503.345672] [c0296e98] (isp_s_pipeline+0x1d8/0x280) from
 [bf036b98] (cammux_streamon+0x218/0xa28 [cammux])
 [ ... ]
 
 
 The register we're trying to access here is the ISP PRV_PCR.  If I try
 to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL
 access faults in the same way (i.e. the whole ISP is borked, not just
 the previewer).
 
 At first I thought the clocks were being disabled somehow, but tracking
 them seems to indicate that's not the case.  Adding an early return in
 arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable
 disabling of clocks) does NOT help.
 
 What else might I be missing?  What is necessary to be able to read the
 ISP registers?

-- 
Regards,

Laurent Pinchart

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

[PATCH 4/5] staging: omap-thermal: add IRQ debugging messaging

[Eduardo Valentin]

For debugging purposes, print the IRQ event for the domain being processed.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/staging/omap-thermal/omap-bandgap.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
b/drivers/staging/omap-thermal/omap-bandgap.c
index 1cae5ed..c5f39ec 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -113,6 +113,11 @@ static irqreturn_t talert_irq_handler(int irq, void *data)
 
omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
 
+   dev_dbg(bg_ptr-dev,
+   %s: IRQ from %s sensor: hotevent %d coldevent %d\n,
+   __func__, bg_ptr-pdata-sensors[i].domain,
+   t_hot, t_cold);
+
/* read temperature */
temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
temp = tsr-bgap_dtemp_mask;
-- 
1.7.7.1.488.ge8e1c

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

[PATCHv2 4/5] staging: omap-thermal: add IRQ debugging messaging

[Eduardo Valentin]

For debugging purposes, print the IRQ event for the domain being processed.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
 drivers/staging/omap-thermal/omap-bandgap.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
b/drivers/staging/omap-thermal/omap-bandgap.c
index 1cae5ed..3eb726f 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -113,6 +113,11 @@ static irqreturn_t talert_irq_handler(int irq, void *data)
 
omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
 
+   dev_dbg(bg_ptr-dev,
+   %s: IRQ from %s sensor: hotevent %d coldevent %d\n,
+   __func__, bg_ptr-conf-sensors[i].domain,
+   t_hot, t_cold);
+
/* read temperature */
temp = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
temp = tsr-bgap_dtemp_mask;
-- 
1.7.7.1.488.ge8e1c

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

need help debugging ISP problem

[Adam Wozniak]

I'm working with a custom board based on an Overo WaterStorm com. The 
processor is a DM3730.  The kernel is 2.6.32 based.


I'm trying to stress test the camera ISP by rapidly opening and closing 
the video device with ( while true; do gst-launch v4l2src 
device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! 
ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done )


After many iterations, I will see the kernel spit out:

[ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028) 
at 0xfa0bce04

[ 2502.810516] Internal error: : 1028 [#1]
[ ... ]
[ 2502.846893] PC is at isp_reg_readl+0x18/0x20
[ 2502.851196] LR is at isp_reg_readl+0x10/0x20
[ ... ]
[ 2503.296447] [c02954a0] (isp_reg_readl+0x18/0x20) from [c02954f8] 
(isp_reg_and_or+0x1c/0x38)
[ 2503.305206] [c02954f8] (isp_reg_and_or+0x1c/0x38) from [c029bad0] 
(isppreview_config_cfa+0x38/0x90)
[ 2503.314666] [c029bad0] (isppreview_config_cfa+0x38/0x90) from 
[c029bc5c] (isppreview_config_datapath+0x134/0x330)
[ 2503.325347] [c029bc5c] (isppreview_config_datapath+0x134/0x330) 
from [c029be68] (isppreview_s_pipeline+0x10/0xd0)
[ 2503.336029] [c029be68] (isppreview_s_pipeline+0x10/0xd0) from 
[c0296e98] (isp_s_pipeline+0x1d8/0x280)
[ 2503.345672] [c0296e98] (isp_s_pipeline+0x1d8/0x280) from 
[bf036b98] (cammux_streamon+0x218/0xa28 [cammux])

[ ... ]


The register we're trying to access here is the ISP PRV_PCR.  If I try 
to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL 
access faults in the same way (i.e. the whole ISP is borked, not just 
the previewer).


At first I thought the clocks were being disabled somehow, but tracking 
them seems to indicate that's not the case.  Adding an early return in 
arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable 
disabling of clocks) does NOT help.


What else might I be missing?  What is necessary to be able to read the 
ISP registers?


--Adam

--
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: [RESUBMIT PATCH] ARM: OMAP2+: am33xx: Add low level debugging support

[Tony Lindgren]

* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]:
 On Thu, May 10, 2012 at 14:23:01, Hiremath, Vaibhav wrote:
  From: Afzal Mohammed af...@ti.com
  
  Add support for low level debugging on AM335X EVM (AM33XX family).
  Currently only support for UART1 console, which is used on AM335X EVM
  is added.
  
  Signed-off-by: Afzal Mohammed af...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  Reviewed-by: Kevin Hilman khil...@ti.com
  Cc: Tony Lindgren t...@atomide.com
  Cc: Paul Walmsley p...@pwsan.com
  ---
  This patch had been Reviewed and accepted earlier, but got
  missed during last merge window. Resubmitting again, without
  code-change.
  
   arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
   arch/arm/plat-omap/include/plat/serial.h   |4 
   arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
   3 files changed, 26 insertions(+), 1 deletions(-)
  
 
 Tony,
 
 Can this be merged now???

Yes applying into devel-am33xx branch.

Regards,

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

RE: [RESUBMIT PATCH] ARM: OMAP2+: am33xx: Add low level debugging support

[Hiremath, Vaibhav]

On Thu, May 10, 2012 at 14:23:01, Hiremath, Vaibhav wrote:
 From: Afzal Mohammed af...@ti.com
 
 Add support for low level debugging on AM335X EVM (AM33XX family).
 Currently only support for UART1 console, which is used on AM335X EVM
 is added.
 
 Signed-off-by: Afzal Mohammed af...@ti.com
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 Reviewed-by: Kevin Hilman khil...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Paul Walmsley p...@pwsan.com
 ---
 This patch had been Reviewed and accepted earlier, but got
 missed during last merge window. Resubmitting again, without
 code-change.
 
  arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
  arch/arm/plat-omap/include/plat/serial.h   |4 
  arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
  3 files changed, 26 insertions(+), 1 deletions(-)
 

Tony,

Can this be merged now???

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

[RESUBMIT PATCH] ARM: OMAP2+: am33xx: Add low level debugging support

[Vaibhav Hiremath]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
This patch had been Reviewed and accepted earlier, but got
missed during last merge window. Resubmitting again, without
code-change.

 arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index cdfc2a1..d7f844a 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI81XXUART3   @ ti81Xx UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI81XX_UART3_BASE)
b   98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -109,6 +113,17 @@ omap_uart_lsr: .word   0
str \rp, [\tmp, #8] @ omap_uart_lsr
b   10b

+   /* AM33XX: Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   str \rp, [\tmp, #4] @ omap_uart_virt
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   str \rp, [\tmp, #8] @ omap_uart_lsr
+
+   b   10b
+
/* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index b073e5f..28e2d25 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -60,6 +60,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM33XX serial port */
+#define AM33XX_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -93,6 +96,7 @@
 #define TI81XXUART181
 #define TI81XXUART282
 #define TI81XXUART383
+#define AM33XXUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index cc3f11b..ac43233 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI81XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI81XXUART##p)

+#define DEBUG_LL_AM33XX(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM33XXUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -183,6 +187,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8148 base boards using UART1 */
DEBUG_LL_TI81XX(1, ti8148evm);

+   /* AM33XX base boards using UART1 */
+   DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
 }

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

PM debugging in debugfs is non-functional on 24xx

[Paul Walmsley]

Hi

I think this is a known issue, but the debugfs pm_debug/count file is 
non-functional on 242x.  

root@(none):/debug/pm_debug# cat count 
core_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-M
EMBANK2-OFF:0,RET-MEMBANK3-OFF:0
mpu_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dsp_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
gfx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_clkdm-core_pwrdm (1)
core_l4_clkdm-core_pwrdm (27)
core_l3_clkdm-core_pwrdm (4)
gfx_clkdm-gfx_pwrdm (0)
dsp_clkdm-dsp_pwrdm (0)
iva1_clkdm-dsp_pwrdm (0)
mpu_clkdm-mpu_pwrdm (0)
prm_clkdm-wkup_pwrdm (0)
cm_clkdm-core_pwrdm (0)

That's with MPU retention enabled... so those counts are wrong.

Anyway, just hoping that someone out there is motivated to fix this -


- Paul
--
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-V4 3/3] arm:omap:am33xx: Add low level debugging support

[Hiremath, Vaibhav]

 -Original Message-
 From: Hilman, Kevin
 Sent: Thursday, December 01, 2011 5:03 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
 ker...@lists.infradead.org; p...@pwsan.com; Mohammed, Afzal
 Subject: Re: [PATCH-V4 3/3] arm:omap:am33xx: Add low level debugging
 support
 
 Hi Vaibhav,
 
 Vaibhav Hiremath hvaib...@ti.com writes:
 
  From: Afzal Mohammed af...@ti.com
 
  Add support for low level debugging on AM335X EVM (AM33XX family).
  Currently only support for UART1 console, which is used on AM335X EVM
  is added.
 
  Signed-off-by: Afzal Mohammed af...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 
 One minor comment below...
 
  ---
   arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
   arch/arm/plat-omap/include/plat/serial.h   |4 
   arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
   3 files changed, 26 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
 b/arch/arm/mach-omap2/include/mach/debug-macro.S
  index 13f98e5..ce543ae 100644
  --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
  +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
  @@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
  beq 82f @ configure UART2
  cmp \rp, #TI816XUART3   @ ti816x UART offsets different
  beq 83f @ configure UART3
  +   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
  +   beq 84f @ configure UART1
  cmp \rp, #ZOOM_UART @ only on zoom2/3
  beq 95f @ configure ZOOM_UART
 
  @@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
  b   98f
   83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
  b   98f
  -
  +84:ldr \rp, =AM33XX_UART1_BASE
  +   and \rp, \rp, #0x00ff
  +   b   97f
   95:ldr \rp, =ZOOM_UART_BASE
  str \rp, [\tmp, #0] @ omap_uart_phys
  ldr \rp, =ZOOM_UART_VIRT
  @@ -110,6 +114,17 @@ omap_uart_lsr: .word   0
  b   10b
 
  /* Store both phys and virt address for the uart */
 
 Please update this comment to clarify that this block is for AM33xx
 only, and update the following one as the catch all.
 
Ok, will update.

  +97:add \rp, \rp, #0x4400   @ phys base
  +   str \rp, [\tmp, #0] @ omap_uart_phys
  +   sub \rp, \rp, #0x4400   @ phys base
  +   add \rp, \rp, #0xf900   @ virt base
  +   str \rp, [\tmp, #4] @ omap_uart_virt
  +   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
  +   str \rp, [\tmp, #8] @ omap_uart_lsr
 
 The last 3 lines are unnecessarily duplicated.  They can be shared with
 the common block that follows.  IOW, only the base addresses are
 different, the rest of the operations are shared.
 
I thought about this, but then code looks complex  ugly, just to save
duplication of 3 lines. So I added separate code for AM33xx devices.

If you still think it should be done, then How about below change -


-   /* Store both phys and virt address for the uart */
-98:add \rp, \rp, #0x4800   @ phys base
+   /* AM33XX: Store both phys and virt address for the uart */
+96:add \rp, \rp, #0x4400   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
-   sub \rp, \rp, #0x4800   @ phys base
-   add \rp, \rp, #0xfa00   @ virt base
-   str \rp, [\tmp, #4] @ omap_uart_virt
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+97:str \rp, [\tmp, #4] @ omap_uart_virt
mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
str \rp, [\tmp, #8] @ omap_uart_lsr

b   10b

+   /* Store both phys and virt address for the uart */
+98:add \rp, \rp, #0x4800   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4800   @ phys base
+   add \rp, \rp, #0xfa00   @ virt base
+   b   97b
+


Thanks,
Vaibhav

  +   b   10b
  +
  +   /* Store both phys and virt address for the uart */
   98:add \rp, \rp, #0x4800   @ phys base
  str \rp, [\tmp, #0] @ omap_uart_phys
  sub \rp, \rp, #0x4800   @ phys base
 
 Kevin
--
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

Re: [PATCH-V4 3/3] arm:omap:am33xx: Add low level debugging support

[Kevin Hilman]

Hiremath, Vaibhav hvaib...@ti.com writes:

 Vaibhav Hiremath hvaib...@ti.com writes:
 
  From: Afzal Mohammed af...@ti.com
 
  Add support for low level debugging on AM335X EVM (AM33XX family).
  Currently only support for UART1 console, which is used on AM335X EVM
  is added.
 
  Signed-off-by: Afzal Mohammed af...@ti.com
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 
 One minor comment below...
 
  ---
   arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
   arch/arm/plat-omap/include/plat/serial.h   |4 
   arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
   3 files changed, 26 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
 b/arch/arm/mach-omap2/include/mach/debug-macro.S
  index 13f98e5..ce543ae 100644
  --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
  +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
  @@ -72,6 +72,8 @@ omap_uart_lsr:   .word   0
 beq 82f @ configure UART2
 cmp \rp, #TI816XUART3   @ ti816x UART offsets different
 beq 83f @ configure UART3
  +  cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
  +  beq 84f @ configure UART1
 cmp \rp, #ZOOM_UART @ only on zoom2/3
 beq 95f @ configure ZOOM_UART
 
  @@ -100,7 +102,9 @@ omap_uart_lsr: .word   0
 b   98f
   83:   mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
 b   98f
  -
  +84:   ldr \rp, =AM33XX_UART1_BASE
  +  and \rp, \rp, #0x00ff
  +  b   97f
   95:   ldr \rp, =ZOOM_UART_BASE
 str \rp, [\tmp, #0] @ omap_uart_phys
 ldr \rp, =ZOOM_UART_VIRT
  @@ -110,6 +114,17 @@ omap_uart_lsr:.word   0
 b   10b
 
 /* Store both phys and virt address for the uart */
 
 Please update this comment to clarify that this block is for AM33xx
 only, and update the following one as the catch all.
 
 Ok, will update.

  +97:   add \rp, \rp, #0x4400   @ phys base
  +  str \rp, [\tmp, #0] @ omap_uart_phys
  +  sub \rp, \rp, #0x4400   @ phys base
  +  add \rp, \rp, #0xf900   @ virt base
  +  str \rp, [\tmp, #4] @ omap_uart_virt
  +  mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
  +  str \rp, [\tmp, #8] @ omap_uart_lsr
 
 The last 3 lines are unnecessarily duplicated.  They can be shared with
 the common block that follows.  IOW, only the base addresses are
 different, the rest of the operations are shared.
 
 I thought about this, but then code looks complex  ugly, just to save
 duplication of 3 lines. So I added separate code for AM33xx devices.

Yeah, you're right.

Your original version is better.   Please just update the comments
around the 2 blocks then.

Thanks,

Kevin
--
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-V5 3/3] arm:omap:am33xx: Add low level debugging support

[hvaibhav]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 13f98e5..7da7126 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3   @ ti816x UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b   98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -109,6 +113,17 @@ omap_uart_lsr: .word   0
str \rp, [\tmp, #8] @ omap_uart_lsr
b   10b

+   /* AM33XX: Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   str \rp, [\tmp, #4] @ omap_uart_virt
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   str \rp, [\tmp, #8] @ omap_uart_lsr
+
+   b   10b
+
/* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index 1ab9fd6..e988c92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM33XX serial port */
+#define AM33XX_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI816XUART181
 #define TI816XUART282
 #define TI816XUART383
+#define AM33XXUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 2d45ea3..ff59570 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI816XUART##p)

+#define DEBUG_LL_AM33XX(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM33XXUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -181,6 +185,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);

+   /* AM33XX base boards using UART1 */
+   DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
 }

--
1.7.0.4

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

Re: [PATCH-V4 3/3] arm:omap:am33xx: Add low level debugging support

[Kevin Hilman]

Hi Vaibhav,

Vaibhav Hiremath hvaib...@ti.com writes:

 From: Afzal Mohammed af...@ti.com

 Add support for low level debugging on AM335X EVM (AM33XX family).
 Currently only support for UART1 console, which is used on AM335X EVM
 is added.

 Signed-off-by: Afzal Mohammed af...@ti.com
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com

One minor comment below...

 ---
  arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
  arch/arm/plat-omap/include/plat/serial.h   |4 
  arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
  3 files changed, 26 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
 b/arch/arm/mach-omap2/include/mach/debug-macro.S
 index 13f98e5..ce543ae 100644
 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
 +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
 @@ -72,6 +72,8 @@ omap_uart_lsr:  .word   0
   beq 82f @ configure UART2
   cmp \rp, #TI816XUART3   @ ti816x UART offsets different
   beq 83f @ configure UART3
 + cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
 + beq 84f @ configure UART1
   cmp \rp, #ZOOM_UART @ only on zoom2/3
   beq 95f @ configure ZOOM_UART

 @@ -100,7 +102,9 @@ omap_uart_lsr:.word   0
   b   98f
  83:  mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
   b   98f
 -
 +84:  ldr \rp, =AM33XX_UART1_BASE
 + and \rp, \rp, #0x00ff
 + b   97f
  95:  ldr \rp, =ZOOM_UART_BASE
   str \rp, [\tmp, #0] @ omap_uart_phys
   ldr \rp, =ZOOM_UART_VIRT
 @@ -110,6 +114,17 @@ omap_uart_lsr:   .word   0
   b   10b

   /* Store both phys and virt address for the uart */

Please update this comment to clarify that this block is for AM33xx
only, and update the following one as the catch all.

 +97:  add \rp, \rp, #0x4400   @ phys base
 + str \rp, [\tmp, #0] @ omap_uart_phys
 + sub \rp, \rp, #0x4400   @ phys base
 + add \rp, \rp, #0xf900   @ virt base
 + str \rp, [\tmp, #4] @ omap_uart_virt
 + mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
 + str \rp, [\tmp, #8] @ omap_uart_lsr

The last 3 lines are unnecessarily duplicated.  They can be shared with
the common block that follows.  IOW, only the base addresses are
different, the rest of the operations are shared.

 + b   10b
 +
 + /* Store both phys and virt address for the uart */
  98:  add \rp, \rp, #0x4800   @ phys base
   str \rp, [\tmp, #0] @ omap_uart_phys
   sub \rp, \rp, #0x4800   @ phys base

Kevin
--
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-V4 3/3] arm:omap:am33xx: Add low level debugging support

[Vaibhav Hiremath]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   17 -
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 13f98e5..ce543ae 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -72,6 +72,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3   @ ti816x UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -100,7 +102,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b   98f
-
+84:ldr \rp, =AM33XX_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
str \rp, [\tmp, #0] @ omap_uart_phys
ldr \rp, =ZOOM_UART_VIRT
@@ -110,6 +114,17 @@ omap_uart_lsr: .word   0
b   10b

/* Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   str \rp, [\tmp, #0] @ omap_uart_phys
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   str \rp, [\tmp, #4] @ omap_uart_virt
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   str \rp, [\tmp, #8] @ omap_uart_lsr
+
+   b   10b
+
+   /* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
str \rp, [\tmp, #0] @ omap_uart_phys
sub \rp, \rp, #0x4800   @ phys base
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index 1ab9fd6..e988c92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM33XX serial port */
+#define AM33XX_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI816XUART181
 #define TI816XUART282
 #define TI816XUART383
+#define AM33XXUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 2d45ea3..ff59570 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -103,6 +103,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI816XUART##p)

+#define DEBUG_LL_AM33XX(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM33XXUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -181,6 +185,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);

+   /* AM33XX base boards using UART1 */
+   DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
 }

--
1.7.0.4

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

RE: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support

[Hiremath, Vaibhav]

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Friday, October 07, 2011 4:39 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm-
 ker...@lists.infradead.org; Mohammed, Afzal
 Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging
 support
 
 * hvaib...@ti.com hvaib...@ti.com [110920 06:59]:
  From: Afzal Mohammed af...@ti.com
 
  Add support for low level debugging on AM335X EVM (AM33XX family).
  Currently only support for UART1 console, which is used on AM335X EVM
  is added.
 
 Let's wait a bit on this one as there are other DEBUG_LL patches
 pending from Nico.
 
Tony,

Is there any branch or repo against which I can rebase my patches?

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

Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support

[Tony Lindgren]

* Hiremath, Vaibhav hvaib...@ti.com [07 06:42]:
  -Original Message-
  From: Tony Lindgren [mailto:t...@atomide.com]
  Sent: Friday, October 07, 2011 4:39 AM
  To: Hiremath, Vaibhav
  Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm-
  ker...@lists.infradead.org; Mohammed, Afzal
  Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging
  support
  
  * hvaib...@ti.com hvaib...@ti.com [110920 06:59]:
   From: Afzal Mohammed af...@ti.com
  
   Add support for low level debugging on AM335X EVM (AM33XX family).
   Currently only support for UART1 console, which is used on AM335X EVM
   is added.
  
  Let's wait a bit on this one as there are other DEBUG_LL patches
  pending from Nico.
  
 Tony,
 
 Is there any branch or repo against which I can rebase my patches?

I recommend the current fixes branch.

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

Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support

[Tony Lindgren]

* hvaib...@ti.com hvaib...@ti.com [110920 06:59]:
 From: Afzal Mohammed af...@ti.com
 
 Add support for low level debugging on AM335X EVM (AM33XX family).
 Currently only support for UART1 console, which is used on AM335X EVM
 is added.

Let's wait a bit on this one as there are other DEBUG_LL patches
pending from Nico.

Regards,

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

[PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support

[hvaibhav]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   22 ++
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 48adfe9..f649973 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -78,6 +78,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3   @ ti816x UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM33XXUART1   @ AM33XX UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -106,6 +108,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b   98f
+84:ldr \rp, =AM33XX_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
@@ -121,6 +126,23 @@ omap_uart_lsr: .word   0
b   10b

/* Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   mrc p15, 0, \rv, c1, c0
+   tst \rv, #1 @ MMU enabled?
+   ldreq   \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
+   ldrne   \rv, =omap_uart_phys@ MMU enabled
+   str \rp, [\rv, #0]
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   add \rv, \rv, #4@ omap_uart_virt
+   str \rp, [\rv, #0]
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   add \rv, \rv, #4@ omap_uart_lsr
+   str \rp, [\rv, #0]
+
+   b   10b
+
+   /* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index de3b10c..ad19377 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM33XX serial port */
+#define AM33XX_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI816XUART181
 #define TI816XUART282
 #define TI816XUART383
+#define AM33XXUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index a067484..bd1e051 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -97,6 +97,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI816XUART##p)

+#define DEBUG_LL_AM33XX(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM33XXUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -173,6 +177,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);

+   /* AM33XX base boards using UART1 */
+   DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
 }

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

[RFC PATCH-V2 4/4] AM335X: Add low level debugging support

[hvaibhav]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM. Currently only
support for UART1 console, which is used on AM335X EVM is added.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   22 ++
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 309e328..5bdfd0b 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -78,6 +78,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI81XXUART3   @ ti81Xx UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM335XUART1   @ AM335X UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -106,6 +108,9 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI81XX_UART3_BASE)
b   98f
+84:ldr \rp, =AM335X_UART1_BASE
+   and \rp, \rp, #0x00ff
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
@@ -121,6 +126,23 @@ omap_uart_lsr: .word   0
b   10b

/* Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   mrc p15, 0, \rv, c1, c0
+   tst \rv, #1 @ MMU enabled?
+   ldreq   \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
+   ldrne   \rv, =omap_uart_phys@ MMU enabled
+   str \rp, [\rv, #0]
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   add \rv, \rv, #4@ omap_uart_virt
+   str \rp, [\rv, #0]
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   add \rv, \rv, #4@ omap_uart_lsr
+   str \rp, [\rv, #0]
+
+   b   10b
+
+   /* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index 865b13e..d7c1216 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM335X serial port */
+#define AM335X_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI81XXUART181
 #define TI81XXUART282
 #define TI81XXUART383
+#define AM335XUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 8d052e7..3592ce4 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -97,6 +97,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI81XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI81XXUART##p)

+#define DEBUG_LL_AM335X(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM335X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM335XUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -178,6 +182,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8148 base boards using UART1 */
DEBUG_LL_TI81XX(1, ti8148evm);

+   /* AM335x base boards using UART1 */
+   DEBUG_LL_AM335X(1, am335xevm);
} while (0);
 }

--
1.6.2.4

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

RE: [RFC: PATCH 4/4] AM335X: Add low level debugging support

[Hiremath, Vaibhav]

 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Thursday, August 11, 2011 4:01 PM
 To: linux-omap@vger.kernel.org
 Cc: t...@atomide.com; Hilman, Kevin; p...@pwsan.com; linux-arm-
 ker...@lists.infradead.org; Mohammed, Afzal; Hiremath, Vaibhav
 Subject: [RFC: PATCH 4/4] AM335X: Add low level debugging support
 
 From: Afzal Mohammed af...@ti.com
 
 Add support for low level debugging on AM335X EVM. Currently only
 support for UART1 console, which is used on AM335X EVM is added.
 
 Signed-off-by: Afzal Mohammed af...@ti.com
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/mach-omap2/include/mach/debug-macro.S |   21
 +
  arch/arm/plat-omap/include/plat/serial.h   |4 
  arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
  3 files changed, 31 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
 b/arch/arm/mach-omap2/include/mach/debug-macro.S
 index 309e328..a99ddbd 100644
 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
 +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
 @@ -78,6 +78,8 @@ omap_uart_lsr:  .word   0
   beq 82f @ configure UART2
   cmp \rp, #TI81XXUART3   @ ti81Xx UART offsets different
   beq 83f @ configure UART3
 + cmp \rp, #AM335XUART1   @ AM335X UART offsets different
 + beq 84f @ configure UART1
   cmp \rp, #ZOOM_UART @ only on zoom2/3
   beq 95f @ configure ZOOM_UART
 
 @@ -106,6 +108,8 @@ omap_uart_lsr:.word   0
   b   98f
  83:  mov \rp, #UART_OFFSET(TI81XX_UART3_BASE)
   b   98f
 +84:  mov \rp, #UART_OFFSET(AM335X_UART1_BASE)
[Hiremath, Vaibhav] My bad, the above line results into build failure when you 
enable DEBUG_LL option,

arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:138: Error: invalid constant (408) after fixup
arch/arm/kernel/debug.S:157: Error: invalid constant (e09000) after fixup
arch/arm/kernel/debug.S:173: Error: invalid constant (e09000) after fixup
make[1]: *** [arch/arm/kernel/debug.o] Error 1
make: *** [arch/arm/kernel] Error 2


When I submitted the patch, I only tried building it with omap2plus_defconfig 
and missed to enable DEBUG_LL option. 

I have fixed it with following change,

-84:mov \rp, #UART_OFFSET(AM335X_UART1_BASE)
+84:ldr \rp, =AM335X_UART1_BASE
+   and \rp, \rp, #0x00ff

This will get merged in next patch version.

Thanks,
Vaibhav


 + b   97f
  95:  ldr \rp, =ZOOM_UART_BASE
   mrc p15, 0, \rv, c1, c0
   tst \rv, #1 @ MMU enabled?
 @@ -121,6 +125,23 @@ omap_uart_lsr:   .word   0
   b   10b
 
   /* Store both phys and virt address for the uart */
 +97:  add \rp, \rp, #0x4400   @ phys base
 + mrc p15, 0, \rv, c1, c0
 + tst \rv, #1 @ MMU enabled?
 + ldreq   \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
 + ldrne   \rv, =omap_uart_phys@ MMU enabled
 + str \rp, [\rv, #0]
 + sub \rp, \rp, #0x4400   @ phys base
 + add \rp, \rp, #0xf900   @ virt base
 + add \rv, \rv, #4@ omap_uart_virt
 + str \rp, [\rv, #0]
 + mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
 + add \rv, \rv, #4@ omap_uart_lsr
 + str \rp, [\rv, #0]
 +
 + b   10b
 +
 + /* Store both phys and virt address for the uart */
  98:  add \rp, \rp, #0x4800   @ phys base
   mrc p15, 0, \rv, c1, c0
   tst \rv, #1 @ MMU enabled?
 diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-
 omap/include/plat/serial.h
 index 865b13e..d7c1216 100644
 --- a/arch/arm/plat-omap/include/plat/serial.h
 +++ b/arch/arm/plat-omap/include/plat/serial.h
 @@ -59,6 +59,9 @@
  /* AM3505/3517 UART4 */
  #define AM35XX_UART4_BASE0x4809E000  /* Only on AM3505/3517 */
 
 +/* AM335X serial port */
 +#define AM335X_UART1_BASE0x44E09000
 +
  /* External port on Zoom2/3 */
  #define ZOOM_UART_BASE   0x1000
  #define ZOOM_UART_VIRT   0xfa40
 @@ -92,6 +95,7 @@
  #define TI81XXUART1  81
  #define TI81XXUART2  82
  #define TI81XXUART3  83
 +#define AM335XUART1  84
  #define ZOOM_UART95  /* Only on zoom2/3 */
 
  /* This is only used by 8250.c for omap1510 */
 diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-
 omap/include/plat/uncompress.h
 index 8d052e7..3592ce4 100644

[RFC: PATCH 4/4] AM335X: Add low level debugging support

[hvaibhav]

From: Afzal Mohammed af...@ti.com

Add support for low level debugging on AM335X EVM. Currently only
support for UART1 console, which is used on AM335X EVM is added.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   21 +
 arch/arm/plat-omap/include/plat/serial.h   |4 
 arch/arm/plat-omap/include/plat/uncompress.h   |6 ++
 3 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 309e328..a99ddbd 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -78,6 +78,8 @@ omap_uart_lsr:.word   0
beq 82f @ configure UART2
cmp \rp, #TI81XXUART3   @ ti81Xx UART offsets different
beq 83f @ configure UART3
+   cmp \rp, #AM335XUART1   @ AM335X UART offsets different
+   beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART

@@ -106,6 +108,8 @@ omap_uart_lsr:  .word   0
b   98f
 83:mov \rp, #UART_OFFSET(TI81XX_UART3_BASE)
b   98f
+84:mov \rp, #UART_OFFSET(AM335X_UART1_BASE)
+   b   97f
 95:ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
@@ -121,6 +125,23 @@ omap_uart_lsr: .word   0
b   10b

/* Store both phys and virt address for the uart */
+97:add \rp, \rp, #0x4400   @ phys base
+   mrc p15, 0, \rv, c1, c0
+   tst \rv, #1 @ MMU enabled?
+   ldreq   \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
+   ldrne   \rv, =omap_uart_phys@ MMU enabled
+   str \rp, [\rv, #0]
+   sub \rp, \rp, #0x4400   @ phys base
+   add \rp, \rp, #0xf900   @ virt base
+   add \rv, \rv, #4@ omap_uart_virt
+   str \rp, [\rv, #0]
+   mov \rp, #(UART_LSR  OMAP_PORT_SHIFT)
+   add \rv, \rv, #4@ omap_uart_lsr
+   str \rp, [\rv, #0]
+
+   b   10b
+
+   /* Store both phys and virt address for the uart */
 98:add \rp, \rp, #0x4800   @ phys base
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h 
b/arch/arm/plat-omap/include/plat/serial.h
index 865b13e..d7c1216 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
 /* AM3505/3517 UART4 */
 #define AM35XX_UART4_BASE  0x4809E000  /* Only on AM3505/3517 */

+/* AM335X serial port */
+#define AM335X_UART1_BASE  0x44E09000
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
@@ -92,6 +95,7 @@
 #define TI81XXUART181
 #define TI81XXUART282
 #define TI81XXUART383
+#define AM335XUART184
 #define ZOOM_UART  95  /* Only on zoom2/3 */

 /* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 8d052e7..3592ce4 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -97,6 +97,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI81XX_UART##p##_BASE, OMAP_PORT_SHIFT,   \
TI81XXUART##p)

+#define DEBUG_LL_AM335X(p, mach)   \
+   _DEBUG_LL_ENTRY(mach, AM335X_UART##p##_BASE, OMAP_PORT_SHIFT,   \
+   AM335XUART##p)
+
 static inline void __arch_decomp_setup(unsigned long arch_id)
 {
int port = 0;
@@ -178,6 +182,8 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8148 base boards using UART1 */
DEBUG_LL_TI81XX(1, ti8148evm);

+   /* AM335x base boards using UART1 */
+   DEBUG_LL_AM335X(1, am335xevm);
} while (0);
 }

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

Debugging failure to get MMC2 IRQ 86

[Elvis Dowson]

Hi,
  I get an error when attempting to obtain an IRQ (86) for MMC2 controller, 
which is connected to a Murata TI WL1271 wlan module, using the TI proprietary 
driver.

TIWLAN: 2769.576375: pInitParams-RoamingScanning_2_4G_enable 0 
SDIO clock Configuration is now set to 24Mhz
After sdioDrv_ConnectBus, iStatus=0 
After SD_IO_GO_IDLE_STATE, iStatus=0 
sdioDrv_ExecuteCmd() SDIO Command error status = 0x18000
After VDD_VOLTAGE_WINDOW, iStatus=-1 
TIWLAN: 2770.045094: Try to SDBus Connect again...
SDIO clock Configuration is now set to 24Mhz
sdioDrv_InitHw() - request_irq FAILED!!

More specifically, in file 
ti_wlan_driver/external_drivers/omap3530/Linux/sdio/SdioDrv.c

line 201:

#define INT_MMC2_IRQ   86
#define OMAP_MMC_IRQ   INT_MMC2_IRQ

It fails in the following function call:

line 778: in function sdioDrv_InitHw():

rc = request_irq(OMAP_MMC_IRQ, 
 sdiodrv_irq, 
 0, 
 SDIO_DRIVER_NAME, 
 g_drv);
if (rc != 0)
{
PERR (sdioDrv_InitHw() - request_irq FAILED!!\n);
goto err;
}

What could the reason be for not being able to obtain this IRQ 86 for MMC2 
controller? Its pretty standard, and shouldn't have a problem getting allocated.

Best regards,

Elvis Dowson


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

Debugging Linux OMAP kernel with kgdb and Eclipse

[Elvis Dowson]

Hi,
   I'm trying to setup a kernel debugging environment for the Gumstix Overo 
Earth (TI OMAP 3503) + Palo43 using Eclipse. 

I have enabled kgdb in the kernel (linux-omap-2.6.32 based android kernel).

My bootargs were

# setenv console ttyS2,115200n8
# setenv mmcargs 'setenv bootargs console=${console} vram=12M omapfb.vram=0:4M 
omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} 
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait init=/init kgdboc=${console} 
kgdbwait'

The kernel boots and waits correctly for input as follows:

console [ttyS2] enabled
kgdb: Registered I/O driver kgdboc.
kgdb: Waiting for connection from remote gdb...

I have also configure Eclipse IDE, and built the kernel, and when I run it in 
debug mode, it launches the kernel and the whole android OS boots correctly, 
and Eclipse IDE shows a number of threads running, but I can seem to see any 
source code highlighted, even through I set a breakpoint in board-overo.c (my 
board file) for the init board routine. It should have stopped and paused 
execution at the breakpoint. 

Question 01: When building from Eclipse IDE, it builds uImage, but for the 
debug settings, I selected vmlinux that was generated in the root folder. I ran 
uImage on the target board, but for the executable for the debug session I used 
vmimage. Is that correct?

When I launch Eclipse debugger, I can see a number of threads running, it 
doesn't display any source code, I can't pause any threads, and the breakpoints 
don't appear to be working. 

What should I do ?

Best regards,

Elvis Dowson
--
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 10/10] OMAP2+: clock: reduce the amount of standard debugging while disabling unused clocks

[Paul Walmsley]

Reduce the amount of debugging generated by default when unused clocks
are being disabled by the clock code.  The previous code would only
generate debug-level messages, but some people who wished to run
production kernels with debug-level messages enabled reported that the
large number of clock disable messages were slowing boot.  Now to
enable clock-by-clock disable messages, DEBUG needs to be defined in
mach-omap2/clock.c.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tuukka Tikkanen tuukka.tikka...@nokia.com
Cc: Tim Bird tim.b...@am.sony.com
---
 arch/arm/mach-omap2/clock.c |2 +-
 arch/arm/plat-omap/clock.c  |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 605f531..b5babf5 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -395,7 +395,7 @@ void omap2_clk_disable_unused(struct clk *clk)
if ((regval32  (1  clk-enable_bit)) == v)
return;
 
-   printk(KERN_DEBUG Disabling unused clock \%s\\n, clk-name);
+   pr_debug(Disabling unused clock \%s\\n, clk-name);
if (cpu_is_omap34xx()) {
omap2_clk_enable(clk);
omap2_clk_disable(clk);
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 7190cbd..fc62fb5 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -60,7 +60,7 @@ void clk_disable(struct clk *clk)
 
spin_lock_irqsave(clockfw_lock, flags);
if (clk-usecount == 0) {
-   printk(KERN_ERR Trying disable clock %s with 0 usecount\n,
+   pr_err(Trying disable clock %s with 0 usecount\n,
   clk-name);
WARN_ON(1);
goto out;
@@ -397,6 +397,7 @@ static int __init clk_disable_unused(void)
struct clk *ck;
unsigned long flags;
 
+   pr_info(clock: disabling unused clocks to save power\n);
list_for_each_entry(ck, clocks, node) {
if (ck-ops == clkops_null)
continue;
@@ -418,7 +419,7 @@ late_initcall(clk_disable_unused);
 int __init clk_init(struct clk_functions * custom_clocks)
 {
if (!custom_clocks) {
-   printk(KERN_ERR No custom clock functions registered\n);
+   pr_err(No custom clock functions registered\n);
BUG();
}
 


--
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: [PATCHv3] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Ramirez Luna, Omar]

From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ramos
Falcon, Ernesto

Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.

This fix also uses DYNEXTBASE address to filter symbols that
match low addresses in the hash table and are not useful to
print. Any address below DYNEXTBASE is not valid for the DSP.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/dsp/bridge/core/io_sm.c |   72 +--
 1 files changed, 54 insertions(+), 18 deletions(-)


I pushed this patch to have the feature in, but we need to think on how to make 
this code easier to read.

Pushed to dspbridge.

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

[PATCHv3] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Ernesto Ramos]

Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.

This fix also uses DYNEXTBASE address to filter symbols that
match low addresses in the hash table and are not useful to
print. Any address below DYNEXTBASE is not valid for the DSP.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/dsp/bridge/core/io_sm.c |   72 +--
 1 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index 53753ce..0f9e1b1 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -1948,9 +1948,9 @@ int print_dsp_trace_buffer(struct bridge_dev_context 
*hbridge_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
-   pr_info(%s: DSP Trace Buffer Begin:\n
+   pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
-   __func__, psz_buf);
+   psz_buf);
 
 
/* convert to offset */
@@ -2057,8 +2057,10 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+   u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
+   u32 dyn_ext_base;
u32 i;
u32 offset_output;
u32 total_size;
@@ -2066,6 +2068,7 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+   const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = bridge_context-hdev_obj;
 
@@ -2135,8 +2138,6 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
total_size = MAX_MMU_DBGBUFF;
 
buffer = kzalloc(total_size, GFP_ATOMIC);
-   buffer_end =  buffer + total_size / 4;
-
if (!buffer) {
status = -ENOMEM;
pr_debug(%s: Failed to 
@@ -2144,6 +2145,9 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
goto func_end;
}
 
+   buffer_beg = buffer;
+   buffer_end =  buffer + total_size / 4;
+
/* Read bytes from the DSP trace buffer... */
status = (*intf_fxns-pfn_brd_read)(bridge_context,
(u8 *)buffer, (u32)trace_begin,
@@ -2154,8 +2158,8 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
goto func_end;
}
 
-   pr_err(Aproximate Crash Position:\n);
-   pr_err(--\n);
+   pr_err(\nAproximate Crash Position:\n
+   --\n);
 
exc_type = buffer[3];
if (!exc_type)
@@ -2163,15 +2167,42 @@ int dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
else
i = buffer[80]; /* NRP */
 
-   if ((*buffer  0x0100)  (node_find_addr(node_mgr, i,
+   status =
+   cod_get_sym_value(code_mgr, DYNEXTBASE, dyn_ext_base);
+   if (DSP_FAILED(status)) {
+   status = -EFAULT;
+   goto func_end;
+   }
+
+   if ((i  dyn_ext_base)  (node_find_addr(node_mgr, i,
0x1000, offset_output, name) == 0))
pr_err(0x%-8x [\%s\ + 0x%x]\n, i, name,
i - offset_output);
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
 
-   pr_err(Execution Info:\n);
-   pr_err(---\n);
+   buffer += 4;
+
+   pr_err(\nExecution Info:\n
+   ---\n);
+
+   if (*buffer  ARRAY_SIZE(exec_ctxt)) {
+   pr_err(Execution context \t%s\n,
+   exec_ctxt[*buffer++]);
+   } else {
+   pr_err(Execution context corrupt\n);
+   kfree(buffer_beg);
+   return -EFAULT;
+   }
+   pr_err(Task Handle\t\t0x%x\n, *buffer++);
+   pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+   pr_err(Stack Top\t\t0x%x\n, *buffer++);
+   pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+   pr_err(Stack Size\t\t0x%x\n, *buffer++);
+   

[PATCH] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Ramos Falcon, Ernesto]

Some execution info is missing at the beginning of the trace buffer printout. 
This fix is to include this information according to the buffer contents 
description and also couple of cosmetic changes to make the traces more 
readable.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/dsp/bridge/wmd/io_sm.c |   44 ---
 1 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c 
index 1a5f794..f52c7b3 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -1960,9 +1960,9 @@ dsp_status print_dsp_trace_buffer(struct wmd_dev_context 
*hwmd_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
-   pr_info(%s: DSP Trace Buffer Begin:\n
+   pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
-   __func__, psz_buf);
+   psz_buf);
 
 
/* convert to offset */
@@ -2069,6 +2069,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+   u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
u32 i;
@@ -2078,6 +2079,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+   const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = wmd_context-hdev_obj;
 
@@ -2147,6 +2149,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
total_size = MAX_MMU_DBGBUFF;
 
buffer = mem_calloc(total_size, MEM_NONPAGED);
+   buffer_beg = buffer;
buffer_end =  buffer + total_size / 4;
 
if (!buffer) {
@@ -2166,7 +2169,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
goto func_end;
}
 
-   pr_err(Aproximate Crash Position:\n);
+   pr_err(\nAproximate Crash Position:\n);
pr_err(--\n);
 
exc_type = buffer[3];
@@ -2182,7 +2185,27 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
 
-   pr_err(Execution Info:\n);
+   buffer += 4;
+
+   pr_err(\nExecution Info:\n);
+   pr_err(---\n);
+
+   if (*buffer  ARRAY_SIZE(exec_ctxt)) {
+   pr_err(Execution context \t%s\n,
+   exec_ctxt[*buffer++]);
+   } else {
+   pr_err(Execution context corrupt\n);
+   kfree(buffer_beg);
+   return -EFAULT;
+   }
+   pr_err(Task Handle\t\t0x%x\n, *buffer++);
+   pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+   pr_err(Stack Top\t\t0x%x\n, *buffer++);
+   pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+   pr_err(Stack Size\t\t0x%x\n, *buffer++);
+   pr_err(Stack Size In Use\t0x%x\n, *buffer++);
+
+   pr_err(\nCPU Registers\n);
pr_err(---\n);
 
for (i = 0; i  32; i++) {
@@ -2216,16 +2239,21 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
if (i == 4 || i == 6 || i == 8)
pr_err(B%d 0x%-8x [Function Argument %d]\n,
i, *buffer++, i-2);
-   else if (i == 15)
+   else if (i == 14)
pr_err(B14 0x%-8x [Data Page Pointer]\n,
*buffer++);
else
pr_err(B%d 0x%x\n, i, *buffer++);
}
 
+   pr_err(\n);
+
for (i = 0; i  ARRAY_SIZE(dsp_regs); i++)
pr_err(%s 0x%x\n, dsp_regs[i], *buffer++);
 
+   pr_err(\nStack:\n);
+   pr_err(--\n);
+
for (i = 0; buffer  buffer_end; i++, buffer++) {
if ((*buffer  0x0100)  (node_find_addr(node_mgr,
*buffer , 0x600, offset_output, name) == @@ 
-2236,7 +2264,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context 
*wmd_context)
else
pr_err([%d] 0x%x\n, i, *buffer);
}
-   kfree(buffer - total_size / 4);
+   

Re: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Nishanth Menon]

Ramos Falcon, Ernesto had written, on 05/13/2010 10:40 AM, the following:

Resending this patch rebased to the last changes included in dspbridge.
---

Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/dsp/bridge/core/io_sm.c |   44 +++---
 1 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index d6c1a98..d11bd9f 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -1949,9 +1949,9 @@ dsp_status print_dsp_trace_buffer(struct 
bridge_dev_context *hbridge_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
-   pr_info(%s: DSP Trace Buffer Begin:\n
+   pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
-   __func__, psz_buf);
+   psz_buf);
 
 
 		/* convert to offset */

@@ -2058,6 +2058,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+   u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
u32 i;
@@ -2067,6 +2068,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+   const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = bridge_context-hdev_obj;
 
@@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context *bridge_context)

total_size = MAX_MMU_DBGBUFF;
 
 		buffer = kzalloc(total_size, GFP_ATOMIC);

+   buffer_beg = buffer;
buffer_end =  buffer + total_size / 4;
 
 		if (!buffer) {

@@ -2155,7 +2158,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
goto func_end;
}
 
-		pr_err(Aproximate Crash Position:\n);

+   pr_err(\nAproximate Crash Position:\n);
pr_err(--\n);
 
 		exc_type = buffer[3];

@@ -2171,7 +2174,27 @@ dsp_status dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
 
-		pr_err(Execution Info:\n);

+   buffer += 4;
+
+   pr_err(\nExecution Info:\n);
+   pr_err(---\n);
+
+   if (*buffer  ARRAY_SIZE(exec_ctxt)) {
+   pr_err(Execution context \t%s\n,
+   exec_ctxt[*buffer++]);
+   } else {
+   pr_err(Execution context corrupt\n);
+   kfree(buffer_beg);
+   return -EFAULT;
+   }
+   pr_err(Task Handle\t\t0x%x\n, *buffer++);
+   pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+   pr_err(Stack Top\t\t0x%x\n, *buffer++);
+   pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+   pr_err(Stack Size\t\t0x%x\n, *buffer++);
+   pr_err(Stack Size In Use\t0x%x\n, *buffer++);
+

How about casting buffer to a structure and using it?
the use of buffer++ etc is a nightmare as can be seen here..


+   pr_err(\nCPU Registers\n);
pr_err(---\n);

btw, linux allows you to use string in a single pr_err.. e.g.
pr_err(\n CPU Registers\n
   \n);

it is a bit easier on the system without going thru two function call 
overhead


 
 		for (i = 0; i  32; i++) {

@@ -2205,16 +2228,21 @@ dsp_status dump_dsp_stack(struct bridge_dev_context 
*bridge_context)
if (i == 4 || i == 6 || i == 8)
pr_err(B%d 0x%-8x [Function Argument %d]\n,
i, *buffer++, i-2);
-   else if (i == 15)
+   else if (i == 14)
pr_err(B14 0x%-8x [Data Page Pointer]\n,
*buffer++);
else
pr_err(B%d 0x%x\n, i, *buffer++);
}
 
+		pr_err(\n);

+
for (i = 0; i  ARRAY_SIZE(dsp_regs); i++)
pr_err(%s 0x%x\n, dsp_regs[i], *buffer++);
 
+		pr_err(\nStack:\n);

+   pr_err(--\n);
+
for (i = 0; buffer  buffer_end; i++, buffer++) {
  

RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Kanigeri, Hari]

Ernesto

 @@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
 *bridge_context)
   total_size = MAX_MMU_DBGBUFF;
 
   buffer = kzalloc(total_size, GFP_ATOMIC);
 + buffer_beg = buffer;
   buffer_end =  buffer + total_size / 4;
 
   if (!buffer) {

-- Shouldn't this check be present before the above 2 statements ?

   for (i = 0; buffer  buffer_end; i++, buffer++) {
   if ((*buffer  0x0100)  (node_find_addr(node_mgr,

-- Is 0x0100 MAX_MMU_DBGBUFF ? 

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

RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Ramos Falcon, Ernesto]

-Original Message-
From: Menon, Nishanth
Sent: Thursday, May 13, 2010 10:49 AM
To: Ramos Falcon, Ernesto
Cc: linux-omap@vger.kernel.org; Ameya Palande; Contreras Felipe (Nokia-
D/Helsinki)
Subject: Re: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault
debugging trace

Ramos Falcon, Ernesto had written, on 05/13/2010 10:40 AM, the following:
 Resending this patch rebased to the last changes included in dspbridge.
 ---

 Some execution info is missing at the beginning of the
 trace buffer printout. This fix is to include this information
 according to the buffer contents description and
 also couple of cosmetic changes to make the traces more
 readable.

 Signed-off-by: Ernesto Ramos erne...@ti.com
 ---
  drivers/dsp/bridge/core/io_sm.c |   44 +++--
-
  1 files changed, 36 insertions(+), 8 deletions(-)

 diff --git a/drivers/dsp/bridge/core/io_sm.c
b/drivers/dsp/bridge/core/io_sm.c
 index d6c1a98..d11bd9f 100644
 --- a/drivers/dsp/bridge/core/io_sm.c
 +++ b/drivers/dsp/bridge/core/io_sm.c
 @@ -1949,9 +1949,9 @@ dsp_status print_dsp_trace_buffer(struct
bridge_dev_context *hbridge_context)
  if (DSP_FAILED(status))
  goto func_end;
  /* Pack and do newline conversion */
 -pr_info(%s: DSP Trace Buffer Begin:\n
 +pr_info(DSP Trace Buffer Begin:\n
  ===\n%s\n,
 -__func__, psz_buf);
 +psz_buf);


  /* convert to offset */
 @@ -2058,6 +2058,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
  u32 size;
  } mmu_fault_dbg_info;
  u32 *buffer;
 +u32 *buffer_beg;
  u32 *buffer_end;
  u32 exc_type;
  u32 i;
 @@ -2067,6 +2068,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
  const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
  IRP, NRP, AMR, SSR,
  ILC, RILC, IER, CSR};
 +const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
  struct bridge_drv_interface *intf_fxns;
  struct dev_object *dev_object = bridge_context-hdev_obj;

 @@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
  total_size = MAX_MMU_DBGBUFF;

  buffer = kzalloc(total_size, GFP_ATOMIC);
 +buffer_beg = buffer;
  buffer_end =  buffer + total_size / 4;

  if (!buffer) {
 @@ -2155,7 +2158,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
  goto func_end;
  }

 -pr_err(Aproximate Crash Position:\n);
 +pr_err(\nAproximate Crash Position:\n);
  pr_err(--\n);

  exc_type = buffer[3];
 @@ -2171,7 +2174,27 @@ dsp_status dump_dsp_stack(struct
bridge_dev_context *bridge_context)
  else
  pr_err(0x%-8x [Unable to match to a symbol.]\n, i);

 -pr_err(Execution Info:\n);
 +buffer += 4;
 +
 +pr_err(\nExecution Info:\n);
 +pr_err(---\n);
 +
 +if (*buffer  ARRAY_SIZE(exec_ctxt)) {
 +pr_err(Execution context \t%s\n,
 +exec_ctxt[*buffer++]);
 +} else {
 +pr_err(Execution context corrupt\n);
 +kfree(buffer_beg);
 +return -EFAULT;
 +}
 +pr_err(Task Handle\t\t0x%x\n, *buffer++);
 +pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
 +pr_err(Stack Top\t\t0x%x\n, *buffer++);
 +pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
 +pr_err(Stack Size\t\t0x%x\n, *buffer++);
 +pr_err(Stack Size In Use\t0x%x\n, *buffer++);
 +
How about casting buffer to a structure and using it?
the use of buffer++ etc is a nightmare as can be seen here..


I don't see the need to use a structure for this set of data if anyway I need 
to use buffer++ for the rest of the buffer data. Furthermore, if I declare a 
structure I need to initialize it using buffer as a reference.
I don't think is such a nightmare.

 +pr_err(\nCPU Registers\n);
  pr_err(---\n);
btw, linux allows you to use string in a single pr_err.. e.g.
pr_err(\n CPU Registers\n
\n);

it is a bit easier on the system without going thru two function call
overhead

OK. I'll change that.


  for (i = 0; i  32; i++) {
 @@ -2205,16 +2228,21 @@ dsp_status dump_dsp_stack(struct
bridge_dev_context *bridge_context)
  if (i == 4 || i == 6 || i == 8)
  pr_err(B%d 0x%-8x [Function Argument %d]\n,
  i, *buffer++, i-2);
 -else if (i == 15)
 +else if (i == 14

RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace

[Ramos Falcon, Ernesto]

Hi,

-Original Message-
From: Kanigeri, Hari
Sent: Thursday, May 13, 2010 10:55 AM
To: Ramos Falcon, Ernesto; linux-omap@vger.kernel.org
Cc: Ameya Palande; Contreras Felipe (Nokia-D/Helsinki)
Subject: RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault
debugging trace

Ernesto

 @@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
 *bridge_context)
  total_size = MAX_MMU_DBGBUFF;

  buffer = kzalloc(total_size, GFP_ATOMIC);
 +buffer_beg = buffer;
  buffer_end =  buffer + total_size / 4;

  if (!buffer) {

-- Shouldn't this check be present before the above 2 statements ?


I think in this case does not affect those two assignments could be avoid it, 
so OK.

  for (i = 0; buffer  buffer_end; i++, buffer++) {
  if ((*buffer  0x0100)  (node_find_addr(node_mgr,

-- Is 0x0100 MAX_MMU_DBGBUFF ?

OK, I'll change.

Thank you,
Best regards,
Hari
--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Felipe Contreras]

On Wed, May 5, 2010 at 2:58 PM, Felipe Contreras
felipe.contre...@nokia.com wrote:
 Hey Ernesto,

 On Fri, Apr 30, 2010 at 09:24:15PM +0200, ext Ramos Falcon, Ernesto wrote:
 This patch seems to be doing a lot of things. Couldn't it have been
 split?
 
 Also, from the commit message it seems to implement a new feature,
 however, I heard it's supposed to fix memory corruption too. Is that
 true? If that's the case the code that fixes that would have to be
 separate.
 
 I understand this patch was already pushed to dspbridge branch, but I
 think such important changes should be properly recorded in the
 history.

 I agree important changes must be properly recorded but in this case
 the patch introduces only one new feature and because of the way that
 it is implemented using gpt8 overflow interrupt instead of mailbox to
 inform about the MMU Fault, the problem of the memory corruption was
 fixed indirectly, however these changes are part of the feature design
 itself and I don't see the need to split this new feature.

 In general, logically independent changes should end up as separate
 patches. Many times it looks like a patch cannot be split further, but
 with a little bit of creativity it usually can.

 I can think of one patch that switches to gpt8 overflow, and another one
 that actually shows the extra information.

 Anyway, I ask because we found some issues with the latest commits of
 dspbridge, and I would like to isolate the memory corruption fix just to
 be safe.

Disregard that. This patch doesn't actually fix the corruption. I sent
one proposal for a patch that does.

 Also, from that description it looks like there might be still a problem
 in the mailbox that is hidded by this patch... so it's more like a
 workaround, not really a fix.

I've extracted the GPT8 related changes, which are good in themselves,
and I sent a separate patch for reference. I also cleaned the patch a
bit.

Now I wonder if there are some situations where we might not want to
use GPT8, but the mailbox interrupt. Maybe some baseimages are not
using GPT8, or maybe the system doesn't have OMAP_DM_TIMER.

Also, all this MMU fault backtracing and so on seems to consume quite
a bit of code. Production systems most likely would want to have this
off (specially when constrained by size), so it should be a
configuration option.

Cheers.

-- 
Felipe Contreras
--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Felipe Contreras]

Hey Ernesto,

On Fri, Apr 30, 2010 at 09:24:15PM +0200, ext Ramos Falcon, Ernesto wrote:
 This patch seems to be doing a lot of things. Couldn't it have been
 split?
 
 Also, from the commit message it seems to implement a new feature,
 however, I heard it's supposed to fix memory corruption too. Is that
 true? If that's the case the code that fixes that would have to be
 separate.
 
 I understand this patch was already pushed to dspbridge branch, but I
 think such important changes should be properly recorded in the
 history.
 
 I agree important changes must be properly recorded but in this case
 the patch introduces only one new feature and because of the way that
 it is implemented using gpt8 overflow interrupt instead of mailbox to
 inform about the MMU Fault, the problem of the memory corruption was
 fixed indirectly, however these changes are part of the feature design
 itself and I don't see the need to split this new feature.

In general, logically independent changes should end up as separate
patches. Many times it looks like a patch cannot be split further, but
with a little bit of creativity it usually can.

I can think of one patch that switches to gpt8 overflow, and another one
that actually shows the extra information.

Anyway, I ask because we found some issues with the latest commits of
dspbridge, and I would like to isolate the memory corruption fix just to
be safe.

Also, from that description it looks like there might be still a problem
in the mailbox that is hidded by this patch... so it's more like a
workaround, not really a fix.

Cheers.

-- 
Felipe Contreras
--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Felipe Contreras]

On Fri, Apr 9, 2010 at 3:15 AM, Guzman Lugo, Fernando x0095...@ti.com wrote:
 From db3d76a2e89a1c227322a2732ddf7ebf5cd4b4cf Mon Sep 17 00:00:00 2001
 From: Ernesto Ramos erne...@ti.com
 Date: Wed, 24 Mar 2010 11:12:05 -0600
 Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements

 These changes allow for DSP task information to be printed
 by the MPU dspbridge when DSP MMU fault ocurrs.

 Signed-off-by: Cris Jansson cjans...@ti.com
 [change to open source coding style]
 Signed-off-by: Ernesto Ramos erne...@ti.com

This patch seems to be doing a lot of things. Couldn't it have been split?

Also, from the commit message it seems to implement a new feature,
however, I heard it's supposed to fix memory corruption too. Is that
true? If that's the case the code that fixes that would have to be
separate.

I understand this patch was already pushed to dspbridge branch, but I
think such important changes should be properly recorded in the
history.

Cheers.

-- 
Felipe Contreras
--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Ramirez Luna, Omar]

From db3d76a2e89a1c227322a2732ddf7ebf5cd4b4cf Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Wed, 24 Mar 2010 11:12:05 -0600
Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements

These changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.

Signed-off-by: Cris Jansson cjans...@ti.com
[change to open source coding style]
Signed-off-by: Ernesto Ramos erne...@ti.com
---

Pushed to dspbridge.

- omar
--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Ramos Falcon, Ernesto]

From 4aee61479659b42127d107da6054e1c22be56d66 Mon Sep 17 00:00:00 2001
From: Cris Jansson cjans...@ti.com
Date: Wed, 24 Mar 2010 11:12:05 -0600
Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements

These changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.

Signed-off-by: Cris Jansson cjans...@ti.com
[change to open source coding style]
Signed-off-by: Ernesto Ramos erne...@ti.com
---
 arch/arm/plat-omap/include/dspbridge/cod.h   |1 +
 arch/arm/plat-omap/include/dspbridge/dbll.h  |3 +-
 arch/arm/plat-omap/include/dspbridge/gh.h|2 +
 arch/arm/plat-omap/include/dspbridge/io_sm.h |5 +
 arch/arm/plat-omap/include/dspbridge/nldr.h  |2 +
 arch/arm/plat-omap/include/dspbridge/node.h  |   15 +
 drivers/dsp/bridge/Makefile  |1 +
 drivers/dsp/bridge/gen/gh.c  |   24 ++
 drivers/dsp/bridge/pmgr/dbll.c   |   84 
 drivers/dsp/bridge/rmgr/nldr.c   |   80 
 drivers/dsp/bridge/rmgr/node.c   |   31 ++
 drivers/dsp/bridge/wmd/io_sm.c   |  568 +-
 drivers/dsp/bridge/wmd/ue_deh.c  |   65 +++-
 13 files changed, 771 insertions(+), 110 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/cod.h 
b/arch/arm/plat-omap/include/dspbridge/cod.h
index 3d76a6b..e508565 100644
--- a/arch/arm/plat-omap/include/dspbridge/cod.h
+++ b/arch/arm/plat-omap/include/dspbridge/cod.h
@@ -26,6 +26,7 @@
 #define COD_MAXPATHLENGTH   255
 #define COD_TRACEBEGSYS_PUTCBEG
 #define COD_TRACEENDSYS_PUTCEND
+#define COD_TRACECURPOSBRIDGE_SYS_PUTC_current
 #define COD_TRACESECT   trace
 #define COD_TRACEBEGOLD PUTCBEG
 #define COD_TRACEENDOLD PUTCEND
diff --git a/arch/arm/plat-omap/include/dspbridge/dbll.h 
b/arch/arm/plat-omap/include/dspbridge/dbll.h
index daf8a0a..01c4647 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbll.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbll.h
@@ -51,5 +51,6 @@ extern void dbll_set_attrs(struct dbll_tar_obj *target,
 extern void dbll_unload(struct dbll_library_obj *lib, struct dbll_attrs 
*attrs);
 extern dsp_status dbll_unload_sect(struct dbll_library_obj *lib,
   char *sectName, struct dbll_attrs *attrs);
-
+bool dbll_find_dsp_symbol(struct dbll_library_obj *zl_lib, u32 address,
+   u32 offset_range, u32 *sym_addr_output, char *name_output);
 #endif /* DBLL_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/gh.h 
b/arch/arm/plat-omap/include/dspbridge/gh.h
index e4da0f2..55c0489 100644
--- a/arch/arm/plat-omap/include/dspbridge/gh.h
+++ b/arch/arm/plat-omap/include/dspbridge/gh.h
@@ -27,4 +27,6 @@ extern void gh_exit(void);
 extern void *gh_find(struct gh_t_hash_tab *hash_tab, void *key);
 extern void gh_init(void);
 extern void *gh_insert(struct gh_t_hash_tab *hash_tab, void *key, void *value);
+void gh_iterate(struct gh_t_hash_tab *hash_tab,
+   void (*callback)(void *, void *), void *user_data);
 #endif /* GH_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h 
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index aa4d0cf..66aa50f 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -293,4 +293,9 @@ extern void io_sm_init(void);
 extern dsp_status print_dsp_trace_buffer(struct wmd_dev_context
 *hwmd_context);

+dsp_status dump_dsp_stack(struct wmd_dev_context *wmd_context);
+
+void dump_dl_modules(struct wmd_dev_context *wmd_context);
+
+
 #endif /* IOSM_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/nldr.h 
b/arch/arm/plat-omap/include/dspbridge/nldr.h
index 2ec928a..2b930d1 100644
--- a/arch/arm/plat-omap/include/dspbridge/nldr.h
+++ b/arch/arm/plat-omap/include/dspbridge/nldr.h
@@ -49,5 +49,7 @@ extern dsp_status nldr_load(struct nldr_nodeobject 
*nldr_node_obj,
enum nldr_phase phase);
 extern dsp_status nldr_unload(struct nldr_nodeobject *nldr_node_obj,
  enum nldr_phase phase);
+dsp_status nldr_find_addr(struct nldr_nodeobject *nldr_node, u32 sym_addr,
+   u32 offset_range, void *offset_output, char *sym_name);

 #endif /* NLDR_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/node.h 
b/arch/arm/plat-omap/include/dspbridge/node.h
index f2375a2..57d820b 100644
--- a/arch/arm/plat-omap/include/dspbridge/node.h
+++ b/arch/arm/plat-omap/include/dspbridge/node.h
@@ -566,4 +566,19 @@ extern dsp_status node_get_uuid_props(void *hprocessor,
  OUT struct dsp_ndbprops
  *node_props);

+/**
+ * node_find_addr() - Find the closest symbol to the given address.
+ *
+ * @node_mgr:  Node manager handle
+ * @sym_addr:  Given address to find the closest symbol
+ * @offset_range:  offset range to look fo the closest symbol

Re: PATCH] DSPBRIDGE: MMU-Fault debugging enhancements

[Ameya Palande]

Hi Ernesto,

On Fri, 2010-03-05 at 01:39 +0100, ext Ramos Falcon, Ernesto wrote:
 From 1d7f5d634176be558d5a60e26ee2bdeddffd7d3b Mon Sep 17 00:00:00 2001
 From: Cris Jansson cjans...@ti.com
 Date: Thu, 25 Feb 2010 11:38:23 -0600
 Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements
 
 These changes allow for DSP task information to be printed
 by the MPU dspbridge when DSP MMU fault ocurrs.
 
 Signed-off-by: Cris Jansson cjans...@ti.com
 [change to open soutce coding style]

source

 Signed-off-by: Ernesto Ramos erne...@ti.com
 ---
  arch/arm/plat-omap/include/dspbridge/dbll.h  |3 +
  arch/arm/plat-omap/include/dspbridge/gh.h|3 +
  arch/arm/plat-omap/include/dspbridge/io_sm.h |5 +
  arch/arm/plat-omap/include/dspbridge/nldr.h  |3 +
  arch/arm/plat-omap/include/dspbridge/node.h  |   12 +
  drivers/dsp/bridge/Makefile  |1 +
  drivers/dsp/bridge/gen/gh.c  |   22 ++
  drivers/dsp/bridge/pmgr/dbll.c   |   62 +++
  drivers/dsp/bridge/rmgr/nldr.c   |   71 
  drivers/dsp/bridge/rmgr/node.c   |   31 ++
  drivers/dsp/bridge/wmd/io_sm.c   |  515 
 --
  drivers/dsp/bridge/wmd/ue_deh.c  |   67 +++-
  12 files changed, 680 insertions(+), 115 deletions(-)

Snip

 +
 +/*
 + *  node_find_addr 
 + * Purpose:
 + * Find the closest symbol to the given address.
 + * Parameters:
 + *
 + */

Since you are adhering to open source coding style why not use linux
kernel commenting style at all places in patch ;)

Cheers,
Ameya.

--
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] DSPBRIDGE: MMU-Fault debugging enhancements

[Ramos Falcon, Ernesto]

From 1d7f5d634176be558d5a60e26ee2bdeddffd7d3b Mon Sep 17 00:00:00 2001
From: Cris Jansson cjans...@ti.com
Date: Thu, 25 Feb 2010 11:38:23 -0600
Subject: [PATCH] DSPBRIDGE: MMU-Fault debugging enhancements

These changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.

Signed-off-by: Cris Jansson cjans...@ti.com
[change to open soutce coding style]
Signed-off-by: Ernesto Ramos erne...@ti.com
---
 arch/arm/plat-omap/include/dspbridge/dbll.h  |3 +
 arch/arm/plat-omap/include/dspbridge/gh.h|3 +
 arch/arm/plat-omap/include/dspbridge/io_sm.h |5 +
 arch/arm/plat-omap/include/dspbridge/nldr.h  |3 +
 arch/arm/plat-omap/include/dspbridge/node.h  |   12 +
 drivers/dsp/bridge/Makefile  |1 +
 drivers/dsp/bridge/gen/gh.c  |   22 ++
 drivers/dsp/bridge/pmgr/dbll.c   |   62 +++
 drivers/dsp/bridge/rmgr/nldr.c   |   71 
 drivers/dsp/bridge/rmgr/node.c   |   31 ++
 drivers/dsp/bridge/wmd/io_sm.c   |  515 --
 drivers/dsp/bridge/wmd/ue_deh.c  |   67 +++-
 12 files changed, 680 insertions(+), 115 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/dbll.h 
b/arch/arm/plat-omap/include/dspbridge/dbll.h
index 8c6eea7..3443f09 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbll.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbll.h
@@ -56,6 +56,9 @@
extern DSP_STATUS DBLL_unloadSect(struct DBLL_LibraryObj *lib,
  char *sectName,
  struct DBLL_Attrs *attrs);
+   bool dbll_find_symbol(struct DBLL_LibraryObj *zl_lib, u32 address,
+   u32 offset_range, u32 *sym_addr_output, char *name_output);
+

 #endif /* DBLL_ */

diff --git a/arch/arm/plat-omap/include/dspbridge/gh.h 
b/arch/arm/plat-omap/include/dspbridge/gh.h
index 8bff0b4..c19c242 100644
--- a/arch/arm/plat-omap/include/dspbridge/gh.h
+++ b/arch/arm/plat-omap/include/dspbridge/gh.h
@@ -26,4 +26,7 @@ extern void GH_exit(void);
 extern void *GH_find(struct GH_THashTab *hashTab, void *key);
 extern void GH_init(void);
 extern void *GH_insert(struct GH_THashTab *hashTab, void *key, void *value);
+void gh_iterate(struct GH_THashTab *hash_tab,
+   void (*callback)(void *, void *), void *user_data);
+
 #endif /* GH_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h 
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index cc365ec..dfb431d 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -296,4 +296,9 @@
extern DSP_STATUS PrintDspTraceBuffer(struct WMD_DEV_CONTEXT
*hWmdContext);

+   DSP_STATUS dump_dsp_stack(struct WMD_DEV_CONTEXT *wmd_context);
+
+   void dump_dl_modules(struct WMD_DEV_CONTEXT *wmd_context);
+
+
 #endif /* IOSM_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/nldr.h 
b/arch/arm/plat-omap/include/dspbridge/nldr.h
index 4f0639a..0f82a69 100644
--- a/arch/arm/plat-omap/include/dspbridge/nldr.h
+++ b/arch/arm/plat-omap/include/dspbridge/nldr.h
@@ -51,5 +51,8 @@
enum NLDR_PHASE phase);
extern DSP_STATUS NLDR_Unload(struct NLDR_NODEOBJECT *hNldrNode,
enum NLDR_PHASE phase);
+   DSP_STATUS nldr_find_addr(
+   struct NLDR_NODEOBJECT *nldr_node, u32 sym_addr,
+   u32 offset_range, void *offset_output, char *sym_name);

 #endif /* NLDR_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/node.h 
b/arch/arm/plat-omap/include/dspbridge/node.h
index 2a45fc0..0b2ed79 100644
--- a/arch/arm/plat-omap/include/dspbridge/node.h
+++ b/arch/arm/plat-omap/include/dspbridge/node.h
@@ -575,4 +575,16 @@
OUT struct DSP_NDBPROPS
*pNodeProps);

+
+/*
+ *  node_find_addr 
+ * Purpose:
+ * Find the closest symbol to the given address.
+ * Parameters:
+ *
+ */
+   DSP_STATUS node_find_addr(struct NODE_MGR *node_mgr,
+   u32 sym_addr, u32 offset_range,
+   void *sym_addr_output, char *sym_name);
+
 #endif /* NODE_ */
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index 8ae4d21..ca6af08 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -35,5 +35,6 @@ ccflags-y += -Idrivers/dsp/bridge/services
 ccflags-y += -Idrivers/dsp/bridge/wmd
 ccflags-y += -Idrivers/dsp/bridge/pmgr
 ccflags-y += -Idrivers/dsp/bridge/rmgr
+ccflags-y += -Idrivers/dsp/bridge/dynload
 ccflags-y += -Idrivers/dsp/bridge/hw
 ccflags-y += -Iarch/arm
diff --git a/drivers/dsp/bridge/gen/gh.c b/drivers/dsp

[PATCH 10/12] DSPBRIDGE: Remove custom debugging implementation

[Omar Ramirez Luna]

Replace custom debug implementation with a friendly set
of pr_err, pr_info and dev_dbg messages.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
 arch/arm/plat-omap/include/dspbridge/dbg.h |   65 --
 arch/arm/plat-omap/include/dspbridge/gt.h  |  271 --
 drivers/dsp/bridge/Makefile|4 +-
 drivers/dsp/bridge/gen/_gt_para.c  |   95 
 drivers/dsp/bridge/gen/gt.c|  336 
 drivers/dsp/bridge/rmgr/drv_interface.c|   16 --
 drivers/dsp/bridge/services/dbg.c  |   81 ---
 drivers/dsp/bridge/services/services.c |   13 +-
 8 files changed, 4 insertions(+), 877 deletions(-)
 delete mode 100644 drivers/dsp/bridge/gen/_gt_para.c
 delete mode 100644 drivers/dsp/bridge/gen/gt.c
 delete mode 100644 drivers/dsp/bridge/services/dbg.c

diff --git a/arch/arm/plat-omap/include/dspbridge/dbg.h 
b/arch/arm/plat-omap/include/dspbridge/dbg.h
index 4d01eca..828fd71 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbg.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbg.h
@@ -21,69 +21,4 @@
 #include dspbridge/host_os.h
 #include linux/types.h
 
-/* Levels of trace debug messages: */
-#define DBG_ENTER   (u8)(0x01) /* Function entry point. */
-#define DBG_LEVEL1  (u8)(0x02) /* Display debugging state/varibles */
-#define DBG_LEVEL2  (u8)(0x04) /* Display debugging state/varibles */
-#define DBG_LEVEL3  (u8)(0x08) /* Display debugging state/varibles */
-#define DBG_LEVEL4  (u8)(0x10) /* Display debugging state/varibles */
-#define DBG_LEVEL5  (u8)(0x20) /* Module Init, Exit */
-#define DBG_LEVEL6  (u8)(0x40) /* Warn SERVICES Failures */
-#define DBG_LEVEL7  (u8)(0x80) /* Warn Critical Errors */
-
-#if (defined(CONFIG_BRIDGE_DEBUG) || defined(DDSP_DEBUG_PRODUCT))  GT_TRACE
-
-/*
- *   DBG_Exit 
- *  Purpose:
- *  Discontinue usage of module; free resources when reference count
- *  reaches 0.
- *  Parameters:
- *  Returns:
- *  Requires:
- *  DBG initialized.
- *  Ensures:
- *  Resources used by module are freed when cRef reaches zero.
- */
-   extern void DBG_Exit(void);
-
-/*
- *   DBG_Init 
- *  Purpose:
- *  Initializes private state of DBG module.
- *  Parameters:
- *  Returns:
- *  TRUE if initialized; FALSE if error occured.
- *  Requires:
- *  Ensures:
- */
-   extern bool DBG_Init(void);
-
-/*
- *   DBG_Trace 
- *  Purpose:
- *  Output a trace message to the debugger, if the given trace level
- *  is unmasked.
- *  Parameters:
- *  bLevel: Trace level.
- *  pstrFormat: sprintf-style format string.
- *  ...:Arguments for format string.
- *  Returns:
- *  DSP_SOK:Success, or trace level masked.
- *  DSP_EFAIL:  On Error.
- *  Requires:
- *  DBG initialized.
- *  Ensures:
- *  Debug message is printed to debugger output window, if trace level
- *  is unmasked.
- */
-   extern DSP_STATUS DBG_Trace(IN u8 bLevel, IN char *pstrFormat, ...);
-#else
-
-#define DBG_Exit(void) do {} while (0)
-#define DBG_Init(void) true
-#define DBG_Trace(bLevel, pstrFormat, args...) do {} while (0)
-
-#endif /* (CONFIG_BRIDGE_DEBUG || DDSP_DEBUG_PRODUCT)  GT_TRACE */
-
 #endif /* DBG_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/gt.h 
b/arch/arm/plat-omap/include/dspbridge/gt.h
index 9097910..116bb6f 100644
--- a/arch/arm/plat-omap/include/dspbridge/gt.h
+++ b/arch/arm/plat-omap/include/dspbridge/gt.h
@@ -34,275 +34,4 @@
 
 #include dspbridge/host_os.h
 
-#if !defined(GT_ASSERT) || GT_TRACE
-#define GT_ASSERT 1
-#endif
-
-struct GT_Config {
-   Fxn PRINTFXN;
-   Fxn PIDFXN;
-   Fxn TIDFXN;
-   Fxn ERRORFXN;
-};
-
-extern struct GT_Config *GT;
-
-struct GT_Mask {
-   char *modName;
-   u8 *flags;
-} ;
-
-/*
- *  New GT Class defenitions.
- *
- *  The following are the explanations and how it could be used in the code
- *
- *  -   GT_ENTEROn Entry to Functions
- *
- *  -   GT_1CLASS   Display level of debugging status- Object/Automatic
- *  variables
- *  -   GT_2CLASS    do 
- *
- *  -   GT_3CLASS    do  + It can be used(recommended) for debug
- * status in the ISR, IST
- *  -   GT_4CLASS    do 
- *
- *  -   GT_5CLASS   Display entry for module init/exit functions
- *
- *  -   GT_6CLASS   Warn whenever SERVICES function fails
- *
- *  -   GT_7CLASS   Warn failure of Critical failures
- *
- */
-
-#define GT_ENTER   ((u8)0x01)
-#define GT_1CLASS  ((u8)0x02)
-#define GT_2CLASS  ((u8)0x04)
-#define GT_3CLASS  ((u8)0x08)
-#define GT_4CLASS  ((u8)0x10)
-#define GT_5CLASS  ((u8)0x20)
-#define GT_6CLASS  ((u8)0x40)
-#define GT_7CLASS  ((u8)0x80)
-
-#ifdef _LINT_
-
-/* LINTLIBRARY */
-
-/*
- *   GT_assert 
- */
-/* ARGSUSED */
-void GT_assert(struct GT_Mask mask, s32 expr)
-{
-}
-
-/*
- *   GT_config

RE: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed

[Paul Walmsley]

On Wed, 16 Dec 2009, Shilimkar, Santosh wrote:

 I tried this on couple of boards and at least it doesn't work with the 
 options and mentioned bootargs. The low level debug prints are still not 
 coming on console.
 
 I haven't debugged it though.

It works on Beagle, at least.  That's the only one that I've tested so 
far.

If you're using the kernel commandline from u-boot, don't forget to update 
it.


- Paul
--
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: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed

[Kevin Hilman]

Paul Walmsley p...@pwsan.com writes:

 On Wed, 16 Dec 2009, Shilimkar, Santosh wrote:

 I tried this on couple of boards and at least it doesn't work with the 
 options and mentioned bootargs. The low level debug prints are still not 
 coming on console.
 
 I haven't debugged it though.

 It works on Beagle, at least.  That's the only one that I've tested so 
 far.


I've been using the earlyprink patch for PM debug on several OMAP3
boards without any problems.

Kevin
--
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: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed

[Shilimkar, Santosh]

Tony,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
 Lindgren
 Sent: Wednesday, December 16, 2009 6:24 AM
 To: linux-omap@vger.kernel.org
 Subject: Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch 
 removed
 
 Hi all,
 
 Recent commit 93fd03a8c6728b58879f8af20ffd55d9c32a778b added
 support for CONFIG_EARLY_PRINTK on ARM. Recent earlier kernels
 should work too by applying the patch in the commit above.
 
 This means we can now get rid of the old printk.c hack in the
 omap-debug branch, so I've deleted that branch.
 
 To use the earlyprintk, just do the following:
 
 1. Make sure you have the necessary .config options set
 
 CONFIG_DEBUG_LL=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_OMAP_LL_DEBUG_UART1=y
 # CONFIG_OMAP_LL_DEBUG_UART2 is not set
 # CONFIG_OMAP_LL_DEBUG_UART3 is not set
 
 The LL_DEBUG_UART above is typically 1, but it's 3 on Nokia
 boards.
 
 2. Edit the kernel CMDLINE in your .config to have debug earlyprintk
 
 Optionally if you have a JTAG console, you can use CONFIG_DEBUG_ICEDCC
 instead LL_DEBUG_UART.
 
 I've also added these instructions to:
 
 http://www.elinux.org/Debugging_OMAP_kernel
I tried this on couple of boards and at least it doesn't work with the options 
and mentioned bootargs. The low level debug prints are still not coming on 
console.

I haven't debugged it though.

Regards,
Santosh



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

Low level debugging using CONFIG_EARLY_PRINTK=y, omap-debug branch removed

[Tony Lindgren]

Hi all,

Recent commit 93fd03a8c6728b58879f8af20ffd55d9c32a778b added
support for CONFIG_EARLY_PRINTK on ARM. Recent earlier kernels
should work too by applying the patch in the commit above.

This means we can now get rid of the old printk.c hack in the
omap-debug branch, so I've deleted that branch.

To use the earlyprintk, just do the following:

1. Make sure you have the necessary .config options set

CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
CONFIG_OMAP_LL_DEBUG_UART1=y
# CONFIG_OMAP_LL_DEBUG_UART2 is not set
# CONFIG_OMAP_LL_DEBUG_UART3 is not set

The LL_DEBUG_UART above is typically 1, but it's 3 on Nokia
boards.

2. Edit the kernel CMDLINE in your .config to have debug earlyprintk

Optionally if you have a JTAG console, you can use CONFIG_DEBUG_ICEDCC
instead LL_DEBUG_UART.

I've also added these instructions to:

http://www.elinux.org/Debugging_OMAP_kernel

Regards,

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

[PATCH] ARM: Do early I/O mapping if spinlock debugging is enabled (Re: [PATCH 3/4] ARM: OMAP3: Add support for 3430 SDP, v3)

[Tony Lindgren]

* Kevin Hilman khil...@deeprootsystems.com [090401 16:18]:
 Tony Lindgren t...@atomide.com writes:
 
  * Paul Walmsley p...@pwsan.com [090401 12:04]:
  On Wed, 1 Apr 2009, Syed Mohammed, Khasim wrote:
  
-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Gadiyar, Anand
Sent: Wednesday, April 01, 2009 1:55 PM
To: Russell King - ARM Linux
Cc: Tony Lindgren; linux-arm-ker...@lists.arm.linux.org.uk; 
linux-omap@vger.kernel.org
Subject: RE: [PATCH 3/4] ARM: OMAP3: Add support for 3430 SDP, v3

On Wed, Apr 01, 2009 at 12:18 AM, Russell King - ARM Linux wrote:
 On Tue, Mar 31, 2009 at 05:12:18PM +0530, Gadiyar, Anand wrote:
  I could not run the 3430 SDP defconfig from mainline. The image 
  hangs at
  Starting kernel  Enabling CONFIG_DEBUG_LL does not help.

 Did you add the necessary patch to kernel/printk.c ?


Silly me, I had not done this (despite having read this so many times 
on this list).

Here's what I get now after adding the patch.

snip

  Not seeing this on overo at least.
 
 
 And my Beagle is booting fine with mainline and attached .config.

snip

Well turns out it's the same old bug again Juha tracked down earlier..

If CONFIG_DEBUG_SPINLOCK is set, and CONFIG_DEBUG_LL is not set, the IO
does not get mapped. Juha's earlier patch is attached.

Russell, got any better fixes in mind for this?

Tony
From c699464bd92629fda1062223467588fcb0e97bca Mon Sep 17 00:00:00 2001
From: Juha Yrjola juha.yrj...@solidboot.com
Date: Fri, 16 Jan 2009 16:00:50 +0200
Subject: [PATCH] ARM: Do early I/O mapping if spinlock debugging is enabled

At least on OMAP, sched_clock() requires the I/O maps to be initialized.
Spinlock debugging invokes sched_clock() very early.

Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 21e17dc..1bc918c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -282,7 +282,7 @@ __create_page_tables:
 	.endif
 	str	r6, [r0]
 
-#ifdef CONFIG_DEBUG_LL
+#if defined(CONFIG_DEBUG_LL) || defined(CONFIG_DEBUG_SPINLOCK)
 	ldr	r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags
 	/*
 	 * Map in IO space for serial debugging.

Re: [PATCH 1/9] ARM: Do early I/O mapping if spinlock debugging is enabled

[Tony Lindgren]

* David Brownell davi...@pacbell.net [090128 15:51]:
 On Wednesday 28 January 2009, Russell King - ARM Linux wrote:
   
   At least on OMAP, sched_clock() requires the I/O maps to be initialized.
   Spinlock debugging invokes sched_clock() very early.
  
  NAK.  This doesn't and can't work on every platform out there.  The
  only viable fix is that sched_clock() must NOT be used early.
  
  If the kernel is using sched_clock() early, that's a bug.
 
 So you're saying that spinlock debugging is buggy???

It used to be that CONFIG_PRINTK_TIME had a similar issue..
Anyways, dropping this patch from omap-fixes, sounds like
how to fix it needs to get sorted out on LKML.

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

[PATCH 1/9] ARM: Do early I/O mapping if spinlock debugging is enabled

[Tony Lindgren]

From: Juha Yrjola juha.yrj...@solidboot.com

At least on OMAP, sched_clock() requires the I/O maps to be initialized.
Spinlock debugging invokes sched_clock() very early.

Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/kernel/head.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 21e17dc..1bc918c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -282,7 +282,7 @@ __create_page_tables:
.endif
str r6, [r0]
 
-#ifdef CONFIG_DEBUG_LL
+#if defined(CONFIG_DEBUG_LL) || defined(CONFIG_DEBUG_SPINLOCK)
ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags
/*
 * Map in IO space for serial debugging.

--
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/9] ARM: Do early I/O mapping if spinlock debugging is enabled

[Russell King - ARM Linux]

On Wed, Jan 28, 2009 at 10:23:05AM -0800, Tony Lindgren wrote:
 From: Juha Yrjola juha.yrj...@solidboot.com
 
 At least on OMAP, sched_clock() requires the I/O maps to be initialized.
 Spinlock debugging invokes sched_clock() very early.

NAK.  This doesn't and can't work on every platform out there.  The
only viable fix is that sched_clock() must NOT be used early.

If the kernel is using sched_clock() early, that's a bug.
--
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: [REVIEW] v4l2 debugging: match drivers by name instead of the deprecated ID

[Mauro Carvalho Chehab]

On Mon, 22 Dec 2008 13:28:37 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 On Monday 22 December 2008 12:11:33 Mauro Carvalho Chehab wrote:
  On Sat, 20 Dec 2008 13:45:56 +0100
 
  Hans Verkuil hverk...@xs4all.nl wrote:
   Hi all,
  
   Jean Delvare has stated repeatedly that the I2C driver IDs will have to
   go. However, one major user inside V4L2 are the VIDIOC_G_CHIP_IDENT and
   VIDIOC_DBG_G/S_REGISTER ioctls.
  
   These ioctls are meant as debugging and testing ioctls and (in the case
   of G_CHIP_IDENT) for internal use in the kernel (e.g. a bridge driver
   that needs to know which I2C chip variant is present).
  
   These ioctls should not be used in applications and luckily this is
   indeed the case. I scanned the major applications and did a google
   search and everything came up clean.
  
   I made the following changes:
  
   #define V4L2_CHIP_MATCH_HOST   0  /* Match against chip ID on host
   (0 for the host) */
   #define V4L2_CHIP_MATCH_I2C_DRIVER 1  /* Match against I2C driver name
   */ #define V4L2_CHIP_MATCH_I2C_ADDR   2  /* Match against I2C 7-bit
   address */
  
   struct v4l2_match_info {
   __u32 type; /* Match type */
   union {
   __u32 addr;
   char name[32];
   };
   } __attribute__ ((packed));
  
   struct v4l2_register {
   struct v4l2_match_info match;
   __u64 reg;
   __u64 val;
   } __attribute__ ((packed));
  
   /* VIDIOC_DBG_G_CHIP_IDENT */
   struct v4l2_chip_ident {
   struct v4l2_match_info match;
   __u32 ident;
   __u32 revision;
   } __attribute__ ((packed));
  
   So the match will now be done against either a chip address or a driver
   name.
  
   I also added additional comments in videodev2.h, warning against ever
   using it in applications:
  
   #if 1 /*KEEP*/
   /* Experimental, meant for debugging, testing and internal use.
  Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
  You must be root to use these ioctls. Never use these in
   applications! */ #define VIDIOC_DBG_S_REGISTER_IOW('V', 79, struct
   v4l2_register) #define VIDIOC_DBG_G_REGISTER   _IOWR('V', 80, struct
   v4l2_register)
  
   /* Experimental, meant for debugging, testing and internal use.
  Never use this ioctl in applications! */
   #define VIDIOC_DBG_G_CHIP_IDENT _IOWR('V', 81, struct v4l2_chip_ident)
   #endif
  
   And VIDIOC_G_CHIP_IDENT was renamed to VIDIOC_DBG_G_CHIP_IDENT, again
   to clearly mark this as a debugging API.
  
   All this is available in this tree:
   http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-drvid
 
  Seems ok to me, but, while you're there, you should add another field to
  get/set register routines, in order to provide the size of the register.
  This will allow removing some hacks at the debug application needed by
  some usb devices.
 
 Good idea. I'll do that.

Btw, I'm fixing some troubles with v4l2-dbg, and I'll add a handler for AC97
registers on em28xx. I'll probably add another type of debug - something like:

#define V4L2_CHIP_MATCH_AC97   3

For accessing the AC97 chip connected into em28xx AC97 port.

   Now, the main question I have is whether I should keep the old
   VIDIOC_G_CHIP_IDENT around for 2.6.29 with a big warning if someone
   tries to use it, or do we just change it since 1) it is marked
   experimental and for debugging purposes only, and 2) I cannot find a
   single application that uses it and even Google throws up only a
   handful of pages.
 
  IMO, return -EINVAL and print an error at dmesg.
 
 OK. Should I mark it in the feature-removal document as well for removal in 
 2.6.30? I think that would be a good idea otherwise we'll be stuck with it 
 forever.

Sure.

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

[PATCH 3/3] OMAP3 clock: Add debugging in omap3_noncore_dpll_enable()

[Paul Walmsley]

For testing only, not for merging.

Add some debugging in omap3_noncore_dpll_enable() to try to figure out what
is wrong with ehci-omap.c.
---
 arch/arm/mach-omap2/clock34xx.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 2c655be..9f7c5bf 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -275,6 +275,10 @@ static int omap3_noncore_dpll_enable(struct clk *clk)
if (!dd)
return -EINVAL;
 
+   pr_info(clock: %s: clk-rate = %ld, hdwr rate = %d, parent 
+   rate = %ld\n, clk-name, clk-rate,
+   omap2_get_dpll_rate(clk), dd-bypass_clk-rate);
+
if (clk-rate == dd-bypass_clk-rate)
r = _omap3_noncore_dpll_bypass(clk);
else


--
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] Powerdomain debugging

[Peter 'p2' De Schrijver]

Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/Makefile|2 +-
 arch/arm/mach-omap2/powerdomain-debug.c |   50 +++
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/powerdomain-debug.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d89b7cb..e1adb0e 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -24,7 +24,7 @@ obj-y += pm.o
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
 obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o
-obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_PM_DEBUG) += pm-debug.o powerdomain-debug.o
 endif
 
 # SmartReflex driver
diff --git a/arch/arm/mach-omap2/powerdomain-debug.c 
b/arch/arm/mach-omap2/powerdomain-debug.c
new file mode 100644
index 000..dda88e1
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomain-debug.c
@@ -0,0 +1,50 @@
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include mach/powerdomain.h
+
+
+int show_off_mode_count(struct powerdomain *pwrdm, void *user)
+{
+   struct seq_file *s = (struct seq_file *)user;
+
+   if (strcmp(pwrdm-name, emu_pwrdm) 
+   strcmp(pwrdm-name, wkup_pwrdm))
+   seq_printf(s, %s : %d\n, pwrdm-name, pwrdm-offstate_count);
+
+   return 0;
+}
+
+int show_off_mode_counters(struct seq_file *s, void *unused)
+{
+   pwrdm_for_each(show_off_mode_count, s);
+
+   return 0;
+}
+
+static int off_mode_counter_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, show_off_mode_counters, inode-i_private);
+}
+
+static const struct file_operations debug_fops = {
+   .open   = off_mode_counter_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
+static int __init off_mode_counter_debug(void)
+{
+   struct dentry *d;
+
+   d = debugfs_create_dir(off_mode_counters, NULL);
+   if (IS_ERR(d))
+   return PTR_ERR(d);
+
+   debugfs_create_file(count, S_IRUGO,
+   d, NULL, debug_fops);
+
+   return 0;
+}
+
+late_initcall(off_mode_counter_debug);
-- 
1.5.6.3

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

Re: [PATCH 1/3] Power off on state counter debugging

[Kevin Hilman]

Peter 'p2' De Schrijver wrote:

Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/Makefile  |2 +-
 arch/arm/mach-omap2/off-state-counter-debug.c |   50 +
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/off-state-counter-debug.c


How about calling this powerdomain-debug.c and conditionally compiling 
based on CONFIG_PM_DEBUG.


There will probably be some other things besides off-mode counters to 
add here down the road.


Kevin


diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0d8507c..a48f832 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,7 +5,7 @@
 # Common support
 obj-y := irq.o id.o io.o memory.o control.o prcm.o clock.o mux.o \
devices.o serial.o gpmc.o timer-gp.o powerdomain.o \
-   clockdomain.o
+   clockdomain.o off-state-counter-debug.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
diff --git a/arch/arm/mach-omap2/off-state-counter-debug.c b/arch/arm/mach-omap2/off-state-counter-debug.c

new file mode 100644
index 000..7db54b6
--- /dev/null
+++ b/arch/arm/mach-omap2/off-state-counter-debug.c
@@ -0,0 +1,50 @@
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include asm/arch/powerdomain.h
+
+
+int show_off_mode_count(struct powerdomain *pwrdm, void *user)
+{
+   struct seq_file *s = (struct seq_file *)user;
+
+   if (strcmp(pwrdm-name, emu_pwrdm) 
+   strcmp(pwrdm-name, wkup_pwrdm))
+   seq_printf(s, %s : %d\n, pwrdm-name, pwrdm-offstate_count);
+
+   return 0;
+}
+
+int show_off_mode_counters(struct seq_file *s, void *unused)
+{
+   pwrdm_for_each(show_off_mode_count, s);
+
+   return 0;
+}
+
+static int off_mode_counter_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, show_off_mode_counters, inode-i_private);
+}
+
+static const struct file_operations debug_fops = {
+   .open   = off_mode_counter_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
+static int __init off_mode_counter_debug(void)
+{
+   struct dentry *d;
+
+   d = debugfs_create_dir(off_mode_counters, NULL);
+   if (IS_ERR(d))
+   return PTR_ERR(d);
+
+   debugfs_create_file(count, S_IRUGO,
+   d, NULL, debug_fops);
+
+   return 0;
+}
+
+late_initcall(off_mode_counter_debug);


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

JTAG debugging of the kernel

[Peter Barada]

I've been trying to use JTAG (and an Abatron BDI-2000) to debug the ALSA
driver to determine why madplay can't keep up when pulling .mp3 from an
SD card, and have not had any luck trying to halt via JTAG and set/stop
at breakpoints within the kernelthe kernel.  I've found that JTAG works
for a while on kernel startup, but stops working at a non-reproducible
point in the startup code.

Have people had success using a BDI-2000 to debug the kernel after it
has completed startup?

Any suggestions on what can cause the JTAG to stop working after the
kernel starts?

Thanks in advance!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: JTAG debugging of the kernel

[Peter Barada]

On Fri, 2008-08-15 at 23:04 +0530, Syed Mohammed, Khasim wrote:
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter
  Barada
  Sent: Friday, August 15, 2008 8:34 PM
  To: linux-omap@vger.kernel.org
  Subject: JTAG debugging of the kernel
  
  I've been trying to use JTAG (and an Abatron BDI-2000) to debug the ALSA
  driver to determine why madplay can't keep up when pulling .mp3 from an
  SD card, and have not had any luck trying to halt via JTAG and set/stop
  at breakpoints within the kernelthe kernel.  I've found that JTAG works
  for a while on kernel startup, but stops working at a non-reproducible
  point in the startup code.
  
  Have people had success using a BDI-2000 to debug the kernel after it
  has completed startup?
  
  Any suggestions on what can cause the JTAG to stop working after the
  kernel starts?
  
 
 I think you should disable Power Management. Which kernel are you using now?

2.6.22.18.  I'm planning to move to 2.6.26 after the dust settles...

I'll try w/o power management, but any idea why power management might
affect JTAG?

 Regards,
 Khasim
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: JTAG debugging of the kernel

[Josh Karabin]

Peter Barada wrote:

On Fri, 2008-08-15 at 23:04 +0530, Syed Mohammed, Khasim wrote:

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter
Barada



Any suggestions on what can cause the JTAG to stop working after the
kernel starts?


I think you should disable Power Management. Which kernel are you using now?


2.6.22.18.  I'm planning to move to 2.6.26 after the dust settles...

I'll try w/o power management, but any idea why power management might
affect JTAG?


The guy I share an office with (who's out on vacation) worked through 
this with their tech support, who suggested replacing WFI instructions 
with NOPs.


Look at cpu_v7_do_idle in arch/arm/mm/proc-v7.S.  Changing the WFI to a 
NOP did the trick for him.


Presumably power management was off, but even WFI (wait for interrupt) 
put the CPU in a state that wasn't handled by the BDI firmware at the 
time.  I'm not sure if they resolved the issue in a later firmware 
update or not.  We didn't think the workaround was worthy of a Kconfig 
option - hopefully updated firmware for the BDI box will address the issue.



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

[PATCH] Add option for DSP bridge debugging.

[Felipe Contreras]

---
 drivers/dsp/dspbridge/Kconfig   |3 +++
 drivers/dsp/dspbridge/mpu_driver/src/Kbuild |2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/dsp/dspbridge/Kconfig b/drivers/dsp/dspbridge/Kconfig
index 5d5622d..580c148 100644
--- a/drivers/dsp/dspbridge/Kconfig
+++ b/drivers/dsp/dspbridge/Kconfig
@@ -29,4 +29,7 @@ config BRIDGE_PM
DSP Bridge employs power management techniques to save dynamic and
static power consumption of the IVA sub system.
 
+config BRIDGE_DEBUG
+   bool DSP Bridge Debug Support
+
 endif
diff --git a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild 
b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
index b6ad62a..62ca643 100644
--- a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
+++ b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
@@ -33,7 +33,7 @@ ccflags-y = -DDISABLE_BRIDGE_PM
 endif
 
 # Debug
-ifeq ($(CONFIG_DEBUG_KERNEL),y)
+ifeq ($(CONFIG_BRIDGE_DEBUG),y)
 ccflags-y += -DGT_TRACE -DDEBUG
 endif
 
-- 
1.5.6.2.1.g1a51b

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

RE: [PATCH] Add option for DSP bridge debugging.

[Kanigeri, Hari]

Hi Felipe,
  The bridge debug option looks good.

Thank you,
Best regards,
Hari

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:linux-omap-
 [EMAIL PROTECTED] On Behalf Of Felipe Contreras
 Sent: Monday, August 04, 2008 8:48 AM
 To: linux-omap@vger.kernel.org
 Cc: Felipe Contreras
 Subject: [PATCH] Add option for DSP bridge debugging.

 ---
  drivers/dsp/dspbridge/Kconfig   |3 +++
  drivers/dsp/dspbridge/mpu_driver/src/Kbuild |2 +-
  2 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/drivers/dsp/dspbridge/Kconfig b/drivers/dsp/dspbridge/Kconfig
 index 5d5622d..580c148 100644
 --- a/drivers/dsp/dspbridge/Kconfig
 +++ b/drivers/dsp/dspbridge/Kconfig
 @@ -29,4 +29,7 @@ config BRIDGE_PM
 DSP Bridge employs power management techniques to save dynamic and
 static power consumption of the IVA sub system.

 +config BRIDGE_DEBUG
 +   bool DSP Bridge Debug Support
 +
  endif
 diff --git a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
 b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
 index b6ad62a..62ca643 100644
 --- a/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
 +++ b/drivers/dsp/dspbridge/mpu_driver/src/Kbuild
 @@ -33,7 +33,7 @@ ccflags-y = -DDISABLE_BRIDGE_PM
  endif

  # Debug
 -ifeq ($(CONFIG_DEBUG_KERNEL),y)
 +ifeq ($(CONFIG_BRIDGE_DEBUG),y)
  ccflags-y += -DGT_TRACE -DDEBUG
  endif

 --
 1.5.6.2.1.g1a51b

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

[PATCH 1/3] Power off on state counter debugging

[Peter 'p2' De Schrijver]

Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/Makefile  |2 +-
 arch/arm/mach-omap2/off-state-counter-debug.c |   50 +
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/off-state-counter-debug.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0d8507c..a48f832 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,7 +5,7 @@
 # Common support
 obj-y := irq.o id.o io.o memory.o control.o prcm.o clock.o mux.o \
devices.o serial.o gpmc.o timer-gp.o powerdomain.o \
-   clockdomain.o
+   clockdomain.o off-state-counter-debug.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
diff --git a/arch/arm/mach-omap2/off-state-counter-debug.c 
b/arch/arm/mach-omap2/off-state-counter-debug.c
new file mode 100644
index 000..7db54b6
--- /dev/null
+++ b/arch/arm/mach-omap2/off-state-counter-debug.c
@@ -0,0 +1,50 @@
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include asm/arch/powerdomain.h
+
+
+int show_off_mode_count(struct powerdomain *pwrdm, void *user)
+{
+   struct seq_file *s = (struct seq_file *)user;
+
+   if (strcmp(pwrdm-name, emu_pwrdm) 
+   strcmp(pwrdm-name, wkup_pwrdm))
+   seq_printf(s, %s : %d\n, pwrdm-name, pwrdm-offstate_count);
+
+   return 0;
+}
+
+int show_off_mode_counters(struct seq_file *s, void *unused)
+{
+   pwrdm_for_each(show_off_mode_count, s);
+
+   return 0;
+}
+
+static int off_mode_counter_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, show_off_mode_counters, inode-i_private);
+}
+
+static const struct file_operations debug_fops = {
+   .open   = off_mode_counter_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
+static int __init off_mode_counter_debug(void)
+{
+   struct dentry *d;
+
+   d = debugfs_create_dir(off_mode_counters, NULL);
+   if (IS_ERR(d))
+   return PTR_ERR(d);
+
+   debugfs_create_file(count, S_IRUGO,
+   d, NULL, debug_fops);
+
+   return 0;
+}
+
+late_initcall(off_mode_counter_debug);
-- 
1.5.6.3

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

Can't build the DSP/BIOS LINK messaging library (OSK 5912, for CCS debugging)

[Pablo Ravest]

Hi Everyone,
I'm new to this, and probably this is a very basic problem, but I'm
still stuck with it so maybe someone can help.

I'm following the dspusersguide for CCS debugging with osk5912 and
JTAG emulator.
I can't seem to build the dsplinkmsg.pjt... here is an extract from
the log (the first lines):


 timake.exe dsplinkmsg.pjt debug
---  dsplinkmsg.pjt - Debug  ---
[mqabuf.c] C:\CCStudio_v3.3\C5500\cgtools\bin\cl55 -g -mg -q -pdr
-pdv -pden -frC:/CCStudio_v3.3/boards
/osk5912/dsplink/dsp/make/OMAP/Debug
-iC:/CCStudio_v3.3/messaging/include
-iC:/CCStudio_v3.3/boards/osk5912/dsplink/dsp/make/OMAP/../../../dsp/src/mqa
-iC:/CCStudio_v3.3/boards/osk5912/dsplink/dsp/make/OMAP/../../../dsp/src/mqt
-iC:/CCStudio_v3.3/boards/osk5912/dsplink/dsp/make/OMAP/../../../dsp/inc
-iC:/CCStudio_v3.3/boards/osk5912/dsplink/dsp/make/OMAP/../../../dsp/inc/OMAP
-d_DEBUG -d_MSGQ_COMPONENT -dUSE_CCS_BREAKPOINT -ml -mn
-vcore:2.1 -@../../make/OMAP/Debug.lkf mqabuf.c
C:/CCStudio_v3.3/boards/osk5912/dsplink/dsp/make/OMAP/../../../dsp/inc/mqabuf.h,
line 63: error #20:
   identifier MSGQ_AllocatorFxns is undefined
 extern MSGQ_AllocatorFxns MQABUF_FXNS ;
  ^
mqabuf.c, line 82: error #20: identifier MSGQ_Status is undefined
 MSGQ_Status
 ^
mqabuf.c, line 83: error #20: identifier MSGQ_AllocatorHandle is undefined
 MQABUF_open (MSGQ_AllocatorHandle mqaHandle) ;
^
mqabuf.c, line 110: error #20: identifier MSGQ_Status is undefined
 MSGQ_Status
 ^
mqabuf.c, line 111: error #20: identifier MSGQ_AllocatorHandle is undefined
 MQABUF_close (MSGQ_AllocatorHandle mqaHandle) ;
 ^
mqabuf.c, line 145: error #20: identifier MSGQ_AllocatorHandle is undefined
 MQABUF_alloc (MSGQ_AllocatorHandle mqaHandle, Uint16 * size) ;
.
.



I have found the undefined objects in different msgq.h files in my
computer, but replacing the msgq.h located in
C:\CCStudio_v3.3\bios_5_31_02\packages\ti\bios\include doesn't work
because other objects become undefined.

The only thing I think is important to point out is that I'm working
with CCS 3.3 and when I tried to install the MSGQ component
(ALL-2.20-SA-to-UA-mq-1.01.00) from the osk5912 cdrom I got the
following warning:
Setup has not found any valid products to update. Your system may be
already up-to-date or you are attempting to install a serial update
out of sequence. Setup will now abort

Thanks

Pablo Ravest
Universidad de Chile
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] 24XX: PM: Move debugging related code to pm-debug.c

[Jouni Hogander]

Move debugging and serial console handling to pm-debug.c.

Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
 arch/arm/mach-omap2/Makefile   |2 +
 arch/arm/mach-omap2/pm-debug.c |  275 
 arch/arm/mach-omap2/pm.h   |   31 +
 arch/arm/mach-omap2/pm24xx.c   |  258 +-
 4 files changed, 309 insertions(+), 257 deletions(-)
 create mode 100644 arch/arm/mach-omap2/pm-debug.c
 create mode 100644 arch/arm/mach-omap2/pm.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 462f685..8f80382 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -16,6 +16,8 @@ ifeq ($(CONFIG_ARCH_OMAP2),y)
 obj-$(CONFIG_PM) += pm24xx.o sleep24xx.o
 endif
 
+obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)   += clock24xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += clock34xx.o
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
new file mode 100644
index 000..361e52b
--- /dev/null
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -0,0 +1,275 @@
+/*
+ * linux/arch/arm/mach-omap2/pm_debug.c
+ *
+ * OMAP Power Management debug routines
+ *
+ * Copyright (C) 2005 Texas Instruments, Inc.
+ * Copyright (C) 2006-2008 Nokia Corporation
+ *
+ * Written by:
+ * Richard Woodruff [EMAIL PROTECTED]
+ * Tony Lindgren
+ * Juha Yrjola
+ * Amit Kucheria [EMAIL PROTECTED]
+ * Igor Stoppa [EMAIL PROTECTED]
+ * Jouni Hogander
+ *
+ * Based on pm.c for omap2
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/err.h
+
+#include asm/arch/clock.h
+#include asm/arch/board.h
+
+#include prm.h
+#include pm.h
+
+#ifdef CONFIG_PM_DEBUG
+int omap2_pm_debug = 0;
+
+static int serial_console_clock_disabled;
+static int serial_console_uart;
+static unsigned int serial_console_next_disable;
+
+static struct clk *console_iclk, *console_fclk;
+
+static void serial_console_kick(void)
+{
+   serial_console_next_disable = omap2_read_32k_sync_counter();
+   /* Keep the clocks on for 4 secs */
+   serial_console_next_disable += 4 * 32768;
+}
+
+static void serial_wait_tx(void)
+{
+   static const unsigned long uart_bases[3] = {
+   0x4806a000, 0x4806c000, 0x4806e000
+   };
+   unsigned long lsr_reg;
+   int looped = 0;
+
+   /* Wait for TX FIFO and THR to get empty */
+   lsr_reg = IO_ADDRESS(uart_bases[serial_console_uart - 1] + (5  2));
+   while ((__raw_readb(lsr_reg)  0x60) != 0x60)
+   looped = 1;
+   if (looped)
+   serial_console_kick();
+}
+
+u32 omap2_read_32k_sync_counter(void)
+{
+return omap_readl(OMAP2_32KSYNCT_BASE + 0x0010);
+}
+
+void serial_console_fclk_mask(u32 *f1, u32 *f2)
+{
+   switch (serial_console_uart)  {
+   case 1:
+   *f1 = ~(1  21);
+   break;
+   case 2:
+   *f1 = ~(1  22);
+   break;
+   case 3:
+   *f2 = ~(1  2);
+   break;
+   }
+}
+
+void serial_console_sleep(int enable)
+{
+   if (console_iclk == NULL || console_fclk == NULL)
+   return;
+
+   if (enable) {
+   BUG_ON(serial_console_clock_disabled);
+   if (clk_get_usecount(console_fclk) == 0)
+   return;
+   if ((int) serial_console_next_disable - (int) 
omap2_read_32k_sync_counter() = 0)
+   return;
+   serial_wait_tx();
+   clk_disable(console_iclk);
+   clk_disable(console_fclk);
+   serial_console_clock_disabled = 1;
+   } else {
+   int serial_wakeup = 0;
+   u32 l;
+
+   switch (serial_console_uart)  {
+   case 1:
+   l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
+   if (l  OMAP24XX_ST_UART1)
+   serial_wakeup = 1;
+   break;
+   case 2:
+   l = prm_read_mod_reg(CORE_MOD, PM_WKST1);
+   if (l  OMAP24XX_ST_UART2)
+   serial_wakeup = 1;
+   break;
+   case 3:
+   l = prm_read_mod_reg(CORE_MOD, OMAP24XX_PM_WKST2);
+   if (l  OMAP24XX_ST_UART3)
+   serial_wakeup = 1;
+   break;
+   }
+   if (serial_wakeup)
+   serial_console_kick();
+   if (!serial_console_clock_disabled)
+   return;
+   clk_enable(console_iclk);
+   clk_enable(console_fclk);
+   serial_console_clock_disabled = 0;
+   }
+}
+
+void pm_init_serial_console(void