Re: [PATCH] OMAP: McBSP: tx_irq_completion used in rx_irq_handler

[Peter Ujfalusi]

On Wednesday 08 September 2010 20:29:01 ext Scott Ellis wrote:
> Looks like a typo from commit d6d834b010.
> 
> Signed-off-by: Scott Ellis 
> ---
>  arch/arm/plat-omap/mcbsp.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
> index e31496e..0c8612f 100644
> --- a/arch/arm/plat-omap/mcbsp.c
> +++ b/arch/arm/plat-omap/mcbsp.c
> @@ -156,7 +156,7 @@ static irqreturn_t omap_mcbsp_rx_irq_handler(int irq,
> void *dev_id) /* Writing zero to RSYNC_ERR clears the IRQ */
>   MCBSP_WRITE(mcbsp_rx, SPCR1, MCBSP_READ_CACHE(mcbsp_rx, SPCR1));
>   } else {
> - complete(&mcbsp_rx->tx_irq_completion);
> + complete(&mcbsp_rx->rx_irq_completion);
>   }
> 
>   return IRQ_HANDLED;

Acked-by: Peter Ujfalusi 
--
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 00/10] split out emac cpdma and mdio for reuse

[Michael Williamson]

On 09/09/2010 05:24 PM, Cyril Chemparathy wrote:
> Hi Mike,
> 
> [...]
>> An EMAC soft-reset clobbering the MDIO controller state is a
>> possibility.  I will poll TI designers to see if this could be the case.
> 
> To test this theory out, I hacked up a crude
> beat-it-to-death-and-see-if-it-breaks kinda patch (attached).  This
> tests 1 mdio read cycles while constantly doing an emac soft-reset.
> 
> I ran this on a dm365 evm, and the test didn't raise a single failed read:
>> davinci_mdio davinci_mdio.0: davinci mdio revision 1.4
>> davinci_mdio davinci_mdio.0: detected phy mask fffc
>> 1 test loops completed, 1 reads ok
> 
> The failure in question seems to be limited to the da8xx family (tested
> da830 evm), where:
>> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
>> davinci_mdio davinci_mdio.0: detected phy mask fff1
>> idle triggered!!
> 
> The MDIO module upgrade (rev 1.4 -> 1.5) could have something to do with
> this behavior.  Even so, I can't explain why this issue wasn't seen on
> da8xx prior to this series.  The original code should (at least in
> theory) have sporadically locked up on emac open.
> 

I think, if I understand it correctly, that in the previous version of 
this code, the emac was reset *prior* to enabling, scanning, and assigning 
the associated phy on the MDIO bus.  The new implementation sets up and scans 
the MDIO bus first, then comes back around to the EMAC second... hits a reset,
and doesn't re-ENABLE the MDIO.

Also, maybe hitting the EMAC reset while the MDIO state machine is up is *bad*, 
I 
seem to recall some text in the user's guide about waiting for the state
machine to stop before disabling it.  I wonder if that also applies to reset?

-Mike
--
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 00/10] split out emac cpdma and mdio for reuse

[Michael Williamson]

Hi Cyril,

On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
> Hi Mike,
> 
> [...]
>> The hang is in wait_for_user_access() in the davinci_mdio_read() call.  
>> Looks like
>> the state machine got put back into IDLE somewhere between the MDIO probe 
>> and the 
>> EMAC probe. Seems like there should be some sort of time-out and error 
>> message 
>> in the wait_for_user_access() method (maybe even a check for IDLE??)
>>
>> If I add a patch to check the state machine for IDLE and then re-enable it 
>> in the
>> davinci_mdio_read() call, it is able to press on and come up.  I don't see 
>> any calls
>> to the davinci_mdio_suspend() call, so I am wondering if the EMAC probe 
>> routine, 
>> particularly the application of the SOFTRESET, is causing the MDIO to drop 
>> back to 
>> IDLE / disabled.
>>
>> I can post the patch if you like, but it is a bit of a hack...
> 
> An EMAC soft-reset clobbering the MDIO controller state is a
> possibility.  I will poll TI designers to see if this could be the case.
> 
> In any case, a couple of unanswered questions remain:
> 
>   1. Why don't other davinci devices display similar behavior?
> 
>   2. If the answer to #1 above is that the timing window is pretty slim
>  (i.e., only if an MDIO read/write is in progress during EMAC
>  soft-reset), why do we hit this situation consistently on
>  mityomap?

Has it been confirmed that this only happens on mityomap?  Has anyone had 
success
using a da850 evm or other da850 platform?  The configuration for the mityomap, 
wrt 
to the EMAC/MII/MDIO, is pretty much identical to the da850 evm using the MII 
interface.  
The only difference I am aware of is the assigned address to the PHY chip.  The 
reference clocks and rates are identical, AFAIK, to the evm.

> 
> I have put together a quick patch (tested dm365).  See attached.

Your patch doesn't work with my board.  It does attempt to reset the bus on the 
read call, 
but following wait_for_user_access() calls are timing out and the _read() and 
_write() calls punt.  
I bumped up the MDIO_TIMEOUT to 100 ms, and it works.  I'm wondering if the 
scanning logic 
has to complete an entire cycle (all 32 phys) before issuing a request, and if 
it's a lot 
slower than expected.

I also found that the initial scanning logic would not reliably find the PHY 
until I bumped
up the delay time following the reset operation.  Sometimes it would, sometimes 
no.

Also, your while(1) loops with the continue conditions on the second 
wait_for_user_access() 
in the read and writes might need some consideration, i.e.:

while (1) {
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
if (ret < 0)
break;

__raw_writel(reg, &data->regs->user[0].access);

ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
^ <--- this will re-issue the request what 
you want?
if (ret < 0)
break;

reg = __raw_readl(&data->regs->user[0].access);
ret = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO;
break;
}

Also, on the shutdown, I get a major kernel trace.  Here is the dump, as much 
as I could catch of it (I need a better terminal program)

Deconfiguring network interfaces... [ cut here ]
WARNING: at kernel/softirq.c:143 local_bh_enable+0x40/0xb4()
Modules linked in:
[] (unwind_backtrace+0x0/0xec) from [] 
(warn_slowpath_common+0x4c/0x64)
[] (warn_slowpath_common+0x4c/0x64) from [] 
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null+0x1c/0x24) from [] 
(local_bh_enable+0x40/0xb4)
[] (local_bh_enable+0x40/0xb4) from [] 
(__netif_receive_skb+0xf8/0x3d0)
[] (__netif_receive_skb+0xf8/0x3d0) from [] 
(emac_rx_handler+0x40/0xcc)
[] (emac_rx_handler+0x40/0xcc) from [] 
(__cpdma_chan_free+0xac/0xb0)
[] (__cpdma_chan_free+0xac/0xb0) from [] 
(__cpdma_chan_process+0xe4/0x114)
[] (__cpdma_chan_process+0xe4/0x114) from [] 
(cpdma_chan_stop+0xf0/0x1c8)
[] (cpdma_chan_stop+0xf0/0x1c8) from [] 
(cpdma_ctlr_stop+0x80/0xe4)
[] (cpdma_ctlr_stop+0x80/0xe4) from [] 
(emac_dev_stop+0xb0/0x13c)
[] (emac_dev_stop+0xb0/0x13c) from [] 
(__dev_close+0x74/0x98)
[] (__dev_close+0x74/0x98) from [] 
(__dev_change_flags+0xac/0x13c)
[] (__dev_change_flags+0xac/0x13c) from [] 
(dev_change_flags+0x10/0x44)
[] (dev_change_flags+0x10/0x44) from [] 
(devinet_ioctl+0x2dc/0x6f4)
[] (devinet_ioctl+0x2dc/0x6f4) from [] 
(sock_ioctl+0x1fc/0x258)
[] (sock_ioctl+0x1fc/0x258) from [] 
(do_vfs_ioctl+0x550/0x5c0)
[] (do_vfs_ioctl+0x550/0x5c0) from [] (sys_ioctl+0x38/0x5c)
[] (sys_ioctl+0x38/0x5c) from [] (ret_fast_syscall+0x0/0x2c)
---[ end trace 0e686330480db12e ]---
[ cut here ]
WARNING: at drivers/net/davinci_emac.c:1025 __cpdma_chan_free+0xac/0xb0()
Modules li

Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse

[Cyril Chemparathy]

Hi Mike,

[...]
> An EMAC soft-reset clobbering the MDIO controller state is a
> possibility.  I will poll TI designers to see if this could be the case.

To test this theory out, I hacked up a crude
beat-it-to-death-and-see-if-it-breaks kinda patch (attached).  This
tests 1 mdio read cycles while constantly doing an emac soft-reset.

I ran this on a dm365 evm, and the test didn't raise a single failed read:
> davinci_mdio davinci_mdio.0: davinci mdio revision 1.4
> davinci_mdio davinci_mdio.0: detected phy mask fffc
> 1 test loops completed, 1 reads ok

The failure in question seems to be limited to the da8xx family (tested
da830 evm), where:
> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
> davinci_mdio davinci_mdio.0: detected phy mask fff1
> idle triggered!!

The MDIO module upgrade (rev 1.4 -> 1.5) could have something to do with
this behavior.  Even so, I can't explain why this issue wasn't seen on
da8xx prior to this series.  The original code should (at least in
theory) have sporadically locked up on emac open.

Regards
Cyril.
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
index d34a53a..8cd6d28 100644
--- a/drivers/net/davinci_mdio.c
+++ b/drivers/net/davinci_mdio.c
@@ -157,6 +157,56 @@ static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
 	return 0;
 }
 
+#if 0 /* DM365 */
+#define EMAC_BASE			(0x01D07000)
+#define EMAC_CNTRL_OFFSET		(0x)
+#define PHY_ADDR			1
+#endif
+
+#if 1 /* DA8XX */
+#define EMAC_BASE			(0x01e2)
+#define EMAC_CNTRL_OFFSET		(0x3000)
+#define PHY_ADDR			1	/* 1-3 is ok on da830 evm */
+#endif
+
+#define EMAC_SOFTRESET			(0x174)
+#define PHY_REGMII_PHYSID1
+
+static void mdio_emac_soft_reset_test(struct davinci_mdio_data *data)
+{
+	struct davinci_mdio_regs __iomem *regs = data->regs;
+	int loops = 0, status_ok = 0;
+	void __iomem *emac;
+	u32 reg;
+
+	emac = ioremap(EMAC_BASE + EMAC_CNTRL_OFFSET, SZ_4K);
+	if (WARN_ON(!emac))
+		return;
+
+	for (loops = 0; loops < 1; loops++) {
+		while (__raw_readl(®s->user[0].access) &
+USERACCESS_GO)
+			;
+
+		reg = (USERACCESS_GO | USERACCESS_READ |
+		   (PHY_REG << 21) | (PHY_ADDR << 16));
+		__raw_writel(reg, ®s->user[0].access);
+
+		while (__raw_readl(®s->user[0].access) &
+USERACCESS_GO) {
+			__raw_writel(1, emac + EMAC_SOFTRESET);
+			if (__raw_readl(®s->control) & CONTROL_IDLE) {
+printk(KERN_ERR "idle triggered!!\n");
+return;
+			}
+		}
+		if (__raw_readl(®s->user[0].access) & USERACCESS_ACK)
+			status_ok++;
+	}
+	printk(KERN_ERR "%d test loops completed, %d reads ok\n", loops,
+			status_ok);
+}
+
 static int __devinit davinci_mdio_probe(struct platform_device *pdev)
 {
 	struct mdio_platform_data *pdata = pdev->dev.platform_data;
@@ -262,6 +312,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
 	}
 	data->bus->phy_mask = phy_mask;
 
+	mdio_emac_soft_reset_test(data);
+
 	/* register the mii bus */
 	ret = mdiobus_register(data->bus);
 	if (ret)

Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse

[Cyril Chemparathy]

Hi Mike,

[...]
> The hang is in wait_for_user_access() in the davinci_mdio_read() call.  Looks 
> like
> the state machine got put back into IDLE somewhere between the MDIO probe and 
> the 
> EMAC probe. Seems like there should be some sort of time-out and error 
> message 
> in the wait_for_user_access() method (maybe even a check for IDLE??)
> 
> If I add a patch to check the state machine for IDLE and then re-enable it in 
> the
> davinci_mdio_read() call, it is able to press on and come up.  I don't see 
> any calls
> to the davinci_mdio_suspend() call, so I am wondering if the EMAC probe 
> routine, 
> particularly the application of the SOFTRESET, is causing the MDIO to drop 
> back to 
> IDLE / disabled.
> 
> I can post the patch if you like, but it is a bit of a hack...

An EMAC soft-reset clobbering the MDIO controller state is a
possibility.  I will poll TI designers to see if this could be the case.

In any case, a couple of unanswered questions remain:

  1. Why don't other davinci devices display similar behavior?

  2. If the answer to #1 above is that the timing window is pretty slim
 (i.e., only if an MDIO read/write is in progress during EMAC
 soft-reset), why do we hit this situation consistently on
 mityomap?

I have put together a quick patch (tested dm365).  See attached.

Regards
Cyril.
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
index d34a53a..96a0f9e 100644
--- a/drivers/net/davinci_mdio.c
+++ b/drivers/net/davinci_mdio.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 
+#define MDIO_TIMEOUT		10		/* msecs */
 #define PHY_REG_MASK		0x1f
 #define PHY_ID_MASK		0x1f
 
@@ -85,31 +86,74 @@ struct davinci_mdio_data {
 	bool		suspended;
 };
 
+static void __davinci_mdio_reset(struct mii_bus *bus)
+{
+	struct davinci_mdio_data *data = bus->priv;
+	u32 mdio_in_freq, div;
+
+	mdio_in_freq = clk_get_rate(data->clk);
+	div = (mdio_in_freq / data->pdata.bus_freq) - 1;
+	if (div > CONTROL_MAX_DIV)
+		div = CONTROL_MAX_DIV;
+
+	/* set enable and clock divider */
+	__raw_writel(div | CONTROL_ENABLE, &data->regs->control);
+}
+
 /* wait until hardware is ready for another user access */
-static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
+static inline int wait_for_user_access(struct davinci_mdio_data *data)
 {
-	struct davinci_mdio_regs __iomem *regs = data->regs;
+	unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
 	u32 reg;
+	int ret = -ETIMEDOUT;
 
-	while ((reg = __raw_readl(®s->user[0].access)) & USERACCESS_GO)
-		;
+	while (time_after(timeout, jiffies)) {
+		reg = __raw_readl(&data->regs->user[0].access);
+		if ((reg & USERACCESS_GO) == 0) {
+			ret = 0;
+			break;
+		}
 
-	return reg;
+		reg = __raw_readl(&data->regs->control);
+		if (reg & CONTROL_IDLE) {
+			/*
+			 * An emac soft_reset may have clobbered the mdio
+			 * controller's state machine.  We need to reset and
+			 * retry the current operation
+			 */
+			dev_warn(data->dev, "controller idle in transaction, "
+	"resetting\n");
+			__davinci_mdio_reset(data->bus);
+			ret = -EAGAIN;
+			break;
+		}
+	}
+	return ret;
 }
 
 /* wait until hardware state machine is idle */
-static inline void wait_for_idle(struct davinci_mdio_data *data)
+static inline int wait_for_idle(struct davinci_mdio_data *data)
 {
-	struct davinci_mdio_regs __iomem *regs = data->regs;
+	unsigned long timeout = jiffies + msecs_to_jiffies(MDIO_TIMEOUT);
+	int ret = -ETIMEDOUT;
+	u32 reg;
 
-	while ((__raw_readl(®s->control) & CONTROL_IDLE) == 0)
-		;
+	while (time_after(timeout, jiffies)) {
+		reg = __raw_readl(&data->regs->control);
+		if (reg & CONTROL_IDLE) {
+			ret = 0;
+			break;
+		}
+	}
+
+	return ret;
 }
 
 static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
 {
 	struct davinci_mdio_data *data = bus->priv;
 	u32 reg;
+	int ret;
 
 	if (phy_reg & ~PHY_REG_MASK || phy_id & ~PHY_ID_MASK)
 		return -EINVAL;
@@ -121,14 +165,32 @@ static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
 		return -ENODEV;
 	}
 
-	wait_for_user_access(data);
 	reg = (USERACCESS_GO | USERACCESS_READ | (phy_reg << 21) |
 	   (phy_id << 16));
-	__raw_writel(reg, &data->regs->user[0].access);
-	reg = wait_for_user_access(data);
+
+	while (1) {
+		ret = wait_for_user_access(data);
+		if (ret == -EAGAIN)
+			continue;
+		if (ret < 0)
+			break;
+
+		__raw_writel(reg, &data->regs->user[0].access);
+
+		ret = wait_for_user_access(data);
+		if (ret == -EAGAIN)
+			continue;
+		if (ret < 0)
+			break;
+
+		reg = __raw_readl(&data->regs->user[0].access);
+		ret = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO;
+		break;
+	}
+
 	spin_unlock(&data->lock);
 
-	return (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO;
+	return ret;
 }
 
 static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
@@ -136,6 +198,7 @@ static int davinci_mdio_write(struct mii_bus *bus, int phy_id,
 {
 	struct davinci_mdio_data *data = bus->priv;
 	u32 reg;
+	int ret;
 
 	

Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse

[Michael Williamson]

On 9/8/2010 8:47 PM, Michael Williamson wrote:

> Hi Cyril,
> 
> On 09/08/2010 05:59 PM, Cyril Chemparathy wrote:
>> Hi Mike,
>>
> 
> So I went in and set the debug_level to netif_msg_init() to -1 in the 
> davinci_emac
> driver.  The only thing I get during the boot process is:
> 
> net eth0: DaVinci EMAC Probe found device (regs: 01e23000, irq: 33)
> 
> which is good (I also added some debug to make sure probe actually 
> completes), but
> I don't see *anything* else.  I guess I would have expected to see something 
> out of 
> the emac_dev_open.  So I added some more debug in there, it's hanging in the 
> phy_connect() call.  The phy_id it came up with was correct "0:03".
> 
> 


The hang is in wait_for_user_access() in the davinci_mdio_read() call.  Looks 
like
the state machine got put back into IDLE somewhere between the MDIO probe and 
the 
EMAC probe. Seems like there should be some sort of time-out and error message 
in the wait_for_user_access() method (maybe even a check for IDLE??)

If I add a patch to check the state machine for IDLE and then re-enable it in 
the
davinci_mdio_read() call, it is able to press on and come up.  I don't see any 
calls
to the davinci_mdio_suspend() call, so I am wondering if the EMAC probe 
routine, 
particularly the application of the SOFTRESET, is causing the MDIO to drop back 
to 
IDLE / disabled.

I can post the patch if you like, but it is a bit of a hack...

-Mike
--
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] USB: otg: twl4030: fix phy initialization(v1)

[venki kaps]

Venkii,

On Thu, Sep 9, 2010 at 3:01 PM, Felipe Balbi  wrote:
> On Wed, Sep 08, 2010 at 08:49:08PM -0500, Ming Lei wrote:
>>
>> 2010/9/8 venki kaps :
>>
>>>  To resolve the above issue, we have made "PHY power on" in battery
>>> adc on function
>>>  and "PHY power down" in battery adc off function.
>>
>> Good news, the temperature is bad value from battery adc if otg phy is
>> power
>> down. Maybe you only need to power on otg phy before reading battery adc,
>> then
>> power down otg phy after the reading if no usb calbe is connected with
>> musb
>> for decreasing power consumption. (I am not familiar with battery adc,
>> just
>> for your refrerence)
>
> I think you only need the usb3v1 regulator. And it can even be in sleep
> mode, it doens't have to be on. What I would suggest is that usb3v1
> never to be turned off, only .

If usb3v1 put in sleep mode, then
how about VUSB3V1 real activation?
I have tried to put in sleep by using
"twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 1, VUSB_DEDICATED2);"
but still, i have been facing the issue with battery.

one thing i have not understood, why it requires to power down when
the device is booted without
a USB cable?

I have not faced any issue with Kernel 2.6.29 + same hardware
+ the same driver but the problem is facing with Kernel 2.6.32.

I strongly suspecting the problem with PMIC regulator frame work/Power
Management
since in off mode, it is getting very good power results but if system
hits INACTIVE to RETENTION during playback then power numbers will be
more
when it is booted without USB cable.

After booting, just attach/detach the usb cable, then i have not seen
any issue with power numbers in off mode, RETENTION and active states.

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

OMAP 3530 McBSP Frame Sync errors

[Gary Thomas]

I'm trying to use McBSP4 with an external CODEC which is a
slave device (i.e. the OMAP generates the Frame Sync pulses)
In this mode, the BSP is purely the master of these signals.

What can it possibly mean to get Frame Sync errors in this case
(I'm reading from the external CODEC)?

FYI, my registers look like this:
  PCR0: 0x0f0f
  RCR1: 0x0040, RCR2: 0x8041
  XCR1: 0x0040, XCR2: 0x8041
  SRGR1: 0x0f07, SRGR2: 0x101f

Any ideas or help?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
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 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, September 09, 2010 9:25 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; t...@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> "Shilimkar, Santosh"  writes:
> 
> >> -Original Message-
> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >> Sent: Thursday, September 09, 2010 8:52 PM
> >> To: Shilimkar, Santosh
> >> Cc: linux-omap@vger.kernel.org; t...@atomide.com
> >> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> >>
> >> Santosh Shilimkar  writes:
> >>
> >> > This series has few fixes, hacks to get omap4 es2.0 working
> >> > on mainline. The patches are generated against the mainline
> >> > 2.6.36-rc3.
> >>
> >> Hi Santosh, thanks for this...
> >>
> >> > The series is boot tested tested on 4430 SDP, Blaze with
> >> > omap_4430sdp_defconfig with file over NFS and MMC.
> >> >
> >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> >> > SDPs. Same observation with Panda
> >> >
> >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> >> > boot hangs. Same observation with Panda
> >>
> >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> >>
> > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> 
> Note that I said "now working".  I think you read my message as "not
> working."
> 
Yes I read it otherway ... Second time today :)

> IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> your series to current l-o master, and it works.
> 
Cool!!

> >> However, rootfs over NFS is not yet working, presumably because the
> >> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
> >> properly.
> >>
> > This is correct. We need to get the MMC fixed o.w panda is unusable in
> > it's current form.
> >
> >>
> >> > [5.794616] regulator_init_complete: incomplete constraints,
> leaving
> >> VUSIM on
> >> > [5.802764] regulator_init_complete: incomplete constraints,
> leaving
> >> VPP on
> >> > [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> >> 00:53:12 UTC (9  )
> >> > [5.849304] mmc0: new high speed MMC card at address 0001
> >> > [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> >> > [5.862091]  mmcblk0: unknown partition table
> >> > [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
> >> latency 0: 6
> >>
> >> Based on this message, this is not a mainline kernel, but one where the
> >> omap_device conversion for MMC has been applied.
> >>
> > This is mainline 2.6.36-rc3
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/omap4-for-tony
> 
> Then I don't understand where the 'omap_device: mmci-omap-hs.1:...'
> message is coming from in your kernel boot log.
> 
> It should not be present in a mainline kernel as the MMC conversion to
> hwmod/omap_device is not in mainline, or linux-omap.
> 
> That's why I assumed your boot log excerpt came from an internal kernel
> and not a mainline kernel.
> 
I might have mixed kernel Images ... Just too many things together :(

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

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Jon Hunter]

On 9/9/2010 7:47 AM, Cousson, Benoit wrote:

On 9/9/2010 2:07 PM, Balbi, Felipe wrote:

Hi Santosh,

On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:

Felipe is suggesting not to add this support where as you want to
have this support.

Sorry if I haven't understood the comment. Care to clarify


no, I suggested not to revert :-) So, just change the comment saying why
you need that extra check and remove the "this patch should be reverted
later" part :-)


We are fully aligned. On the other hand if the number of buggy devices
is very limited and not available outside TI, we'd better drop that
patch. But I'm afraid it is not the case :-(


I believe that just this week we had a case of a "buggy device" turning 
up on one of our customer's blaze boards that was upgraded to ES2.0 but 
appeared to be ES1.0. So this patch is good to have in the mainline.


Cheers
Jon
--
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 0/7] omap4: Fixes, hacks for es2.0

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Thursday, September 09, 2010 8:52 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; t...@atomide.com
>> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
>> 
>> Santosh Shilimkar  writes:
>> 
>> > This series has few fixes, hacks to get omap4 es2.0 working
>> > on mainline. The patches are generated against the mainline
>> > 2.6.36-rc3.
>> 
>> Hi Santosh, thanks for this...
>> 
>> > The series is boot tested tested on 4430 SDP, Blaze with
>> > omap_4430sdp_defconfig with file over NFS and MMC.
>> >
>> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
>> > SDPs. Same observation with Panda
>> >
>> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
>> > boot hangs. Same observation with Panda
>> 
>> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>>
> I observed the same with MMC. Ramdisk boot worked for me on PANDA.

Note that I said "now working".  I think you read my message as "not
working."

IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
your series to current l-o master, and it works.

>> However, rootfs over NFS is not yet working, presumably because the
>> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
>> properly.
>>
> This is correct. We need to get the MMC fixed o.w panda is unusable in
> it's current form.
>
>> 
>> > [5.794616] regulator_init_complete: incomplete constraints, leaving
>> VUSIM on
>> > [5.802764] regulator_init_complete: incomplete constraints, leaving
>> VPP on
>> > [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
>> 00:53:12 UTC (9  )
>> > [5.849304] mmc0: new high speed MMC card at address 0001
>> > [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
>> > [5.862091]  mmcblk0: unknown partition table
>> > [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
>> latency 0: 6
>> 
>> Based on this message, this is not a mainline kernel, but one where the
>> omap_device conversion for MMC has been applied.
>> 
> This is mainline 2.6.36-rc3 
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

Then I don't understand where the 'omap_device: mmci-omap-hs.1:...'
message is coming from in your kernel boot log.

It should not be present in a mainline kernel as the MMC conversion to
hwmod/omap_device is not in mainline, or linux-omap.

That's why I assumed your boot log excerpt came from an internal kernel
and not a mainline kernel.

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: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, September 09, 2010 8:52 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; t...@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> Santosh Shilimkar  writes:
> 
> > This series has few fixes, hacks to get omap4 es2.0 working
> > on mainline. The patches are generated against the mainline
> > 2.6.36-rc3.
> 
> Hi Santosh, thanks for this...
> 
> > The series is boot tested tested on 4430 SDP, Blaze with
> > omap_4430sdp_defconfig with file over NFS and MMC.
> >
> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> > SDPs. Same observation with Panda
> >
> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> > boot hangs. Same observation with Panda
> 
> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>
I observed the same with MMC. Ramdisk boot worked for me on PANDA.
 
> However, rootfs over NFS is not yet working, presumably because the
> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
> properly.
>
This is correct. We need to get the MMC fixed o.w panda is unusable in
it's current form.
 
> 
> > [5.794616] regulator_init_complete: incomplete constraints, leaving
> VUSIM on
> > [5.802764] regulator_init_complete: incomplete constraints, leaving
> VPP on
> > [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> 00:53:12 UTC (9  )
> > [5.849304] mmc0: new high speed MMC card at address 0001
> > [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> > [5.862091]  mmcblk0: unknown partition table
> > [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
> latency 0: 6
> 
> Based on this message, this is not a mainline kernel, but one where the
> omap_device conversion for MMC has been applied.
> 
This is mainline 2.6.36-rc3 
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-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 0/7] omap4: Fixes, hacks for es2.0

[Kevin Hilman]

Santosh Shilimkar  writes:

> This series has few fixes, hacks to get omap4 es2.0 working
> on mainline. The patches are generated against the mainline 
> 2.6.36-rc3. 

Hi Santosh, thanks for this...

> The series is boot tested tested on 4430 SDP, Blaze with 
> omap_4430sdp_defconfig with file over NFS and MMC.
>
> Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> SDPs. Same observation with Panda
>
> With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> boot hangs. Same observation with Panda

On my ES2.0 Panda, rootfs on MMC is now working with this series.

However, rootfs over NFS is not yet working, presumably because the
OMAP4 EHCI support is needed for the USB-attached smsc95xx to work properly.

Kevin

> [5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM 
> on
> [5.802764] regulator_init_complete: incomplete constraints, leaving VPP on
> [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 
> UTC (9  )
> [5.849304] mmc0: new high speed MMC card at address 0001
> [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> [5.862091]  mmcblk0: unknown partition table
> [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 
> 0: 6

Based on this message, this is not a mainline kernel, but one where the
omap_device conversion for MMC has been applied.

> [   18.424407] VFS: Cannot open root device "mmcblk0p2" or 
> unknown-block(179,2)
> [   18.431823] Please append a correct "root=" boot option; here are the 
> available  ons:
> [   18.440643] b300 7757824 mmcblk0 driver: mmcblk
> [   18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown
>
> All these patches are also available at:
>   http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary
>   head: omap4-for-tony
>
> David Anders (1):
>   omap4: Panda: Add DEBUG_LL support
>
> Eric Dumazet (1):
>   KS8851: Correct RX packet allocation
>
> Madhusudhan Chikkature (1):
>   omap4: Workaround for CMD line reset.
>
> Santosh Shilimkar (4):
>   omap4: Update id.c and cpu.h for es2.0
>   omap4: Temporary fix silicon version detection
>   omap4: l2x0: Fix init parameter for ES2.0
>   omap4: Fix bootup crash observed with higher CPU clocks
>
>  arch/arm/mach-omap2/id.c |   39 +
>  arch/arm/mach-omap2/omap4-common.c   |5 ++-
>  arch/arm/plat-omap/dmtimer.c |2 +-
>  arch/arm/plat-omap/include/plat/cpu.h|5 ++-
>  arch/arm/plat-omap/include/plat/uncompress.h |1 +
>  drivers/mmc/host/omap_hsmmc.c|8 +
>  drivers/net/ks8851.c |   39 
> ++
>  7 files changed, 71 insertions(+), 28 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Thursday, September 09, 2010 6:32 PM
> To: Balbi, Felipe
> Cc: Cousson, Benoit; linux-omap@vger.kernel.org; t...@atomide.com;
> khil...@deeprootsystems.com
> Subject: RE: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> > -Original Message-
> > From: Balbi, Felipe
> > Sent: Thursday, September 09, 2010 5:38 PM
> > To: Shilimkar, Santosh
> > Cc: Cousson, Benoit; Balbi, Felipe; linux-omap@vger.kernel.org;
> > t...@atomide.com; khil...@deeprootsystems.com
> > Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> >
> > Hi Santosh,
> >
> > On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
> > >Felipe is suggesting not to add this support where as you want to
> > >have this support.
> > >
> > >Sorry if I haven't understood the comment. Care to clarify
> >
> > no, I suggested not to revert :-) So, just change the comment saying why
> > you need that extra check and remove the "this patch should be reverted
> > later" part :-)
> >
> Ok. I agree. We can actually keep this code.
> 
> Will change the comment and send V2
> 
Updated version attached. 

Regards,
Santosh


0002-omap4-Fix-silicon-version-detection-for-early-sampl.patch
Description: 0002-omap4-Fix-silicon-version-detection-for-early-sampl.patch

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -Original Message-
> From: Balbi, Felipe
> Sent: Thursday, September 09, 2010 5:38 PM
> To: Shilimkar, Santosh
> Cc: Cousson, Benoit; Balbi, Felipe; linux-omap@vger.kernel.org;
> t...@atomide.com; khil...@deeprootsystems.com
> Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> Hi Santosh,
> 
> On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
> >Felipe is suggesting not to add this support where as you want to
> >have this support.
> >
> >Sorry if I haven't understood the comment. Care to clarify
> 
> no, I suggested not to revert :-) So, just change the comment saying why
> you need that extra check and remove the "this patch should be reverted
> later" part :-)
> 
Ok. I agree. We can actually keep this code.

Will change the comment and send V2

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

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Cousson, Benoit]

On 9/9/2010 2:07 PM, Balbi, Felipe wrote:

Hi Santosh,

On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:

Felipe is suggesting not to add this support where as you want to
have this support.

Sorry if I haven't understood the comment. Care to clarify


no, I suggested not to revert :-) So, just change the comment saying why
you need that extra check and remove the "this patch should be reverted
later" part :-)


We are fully aligned. On the other hand if the number of buggy devices 
is very limited and not available outside TI, we'd better drop that 
patch. But I'm afraid it is not the case :-(


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

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Felipe Balbi]

Hi Santosh,

On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:

Felipe is suggesting not to add this support where as you want to
have this support.

Sorry if I haven't understood the comment. Care to clarify


no, I suggested not to revert :-) So, just change the comment saying why
you need that extra check and remove the "this patch should be reverted
later" part :-)

--
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: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -Original Message-
> From: Cousson, Benoit
> Sent: Thursday, September 09, 2010 5:17 PM
> To: Balbi, Felipe
> Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; t...@atomide.com;
> khil...@deeprootsystems.com
> Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> Hi Santosh,
> 
> On 9/9/2010 1:42 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:
> >> @@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
> >>hawkeye = (idcode>>  12)&  0x;
> >>rev = (idcode>>  28)&  0xff;
> >>
> >> +  /*
> >> +   * FIXME: This patch should be reverted later.
> >> +   * Few initial ES2.0 samples IDCODE is same as ES1.0
> >> +   * Use ARM register to detect the correct ES version
> >> +   */
> >
> > I wonder if it actually doesn't make sense to keep this in tree, the
> > overhead is minimum when rev is set correctly and it's safe for the
> > initial es2.0 samples which are buggy.
> 
> Yep, I agree with that, if some early ES2 samples are already out there,
> we will have no way to control the device upgrade in the future. So we
> will still have to support these early buggy devices just in case.
> 
Felipe is suggesting not to add this support where as you want to
have this support.

Sorry if I haven't understood the comment. Care to clarify

Regards,
Santosh

 

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

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Cousson, Benoit]

Hi Santosh,

On 9/9/2010 1:42 PM, Felipe Balbi wrote:

Hi,

On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:

@@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
hawkeye = (idcode>>  12)&  0x;
rev = (idcode>>  28)&  0xff;

+   /*
+* FIXME: This patch should be reverted later.
+* Few initial ES2.0 samples IDCODE is same as ES1.0
+* Use ARM register to detect the correct ES version
+*/


I wonder if it actually doesn't make sense to keep this in tree, the
overhead is minimum when rev is set correctly and it's safe for the
initial es2.0 samples which are buggy.


Yep, I agree with that, if some early ES2 samples are already out there, 
we will have no way to control the device upgrade in the future. So we 
will still have to support these early buggy devices just in case.


Benoit


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

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Felipe Balbi]

Hi,

On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:

@@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
hawkeye = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xff;

+   /*
+* FIXME: This patch should be reverted later.
+* Few initial ES2.0 samples IDCODE is same as ES1.0
+* Use ARM register to detect the correct ES version
+*/


I wonder if it actually doesn't make sense to keep this in tree, the
overhead is minimum when rev is set correctly and it's safe for the
initial es2.0 samples which are buggy.

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

[PATCH 7/7] KS8851: Correct RX packet allocation

[Santosh Shilimkar]

From: Eric Dumazet 

Use netdev_alloc_skb_ip_align() helper and do correct allocation

Tested-by: Abraham Arce 
Signed-off-by: Abraham Arce 
---
 drivers/net/ks8851.c |   39 +--
 1 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..51919fc 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -503,30 +503,33 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
ks8851_wrreg16(ks, KS_RXQCR,
   ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
 
-   if (rxlen > 0) {
-   skb = netdev_alloc_skb(ks->netdev, rxlen + 2 + 8);
-   if (!skb) {
-   /* todo - dump frame and move on */
-   }
+   if (rxlen > 4) {
+   unsigned int rxalign;
+
+   rxlen -= 4;
+   rxalign = ALIGN(rxlen, 4);
+   skb = netdev_alloc_skb_ip_align(ks->netdev, rxalign);
+   if (skb) {
 
-   /* two bytes to ensure ip is aligned, and four bytes
-* for the status header and 4 bytes of garbage */
-   skb_reserve(skb, 2 + 4 + 4);
+   /* 4 bytes of status header + 4 bytes of
+* garbage: we put them before ethernet
+* header, so that they are copied,
+* but ignored.
+*/
 
-   rxpkt = skb_put(skb, rxlen - 4) - 8;
+   rxpkt = skb_put(skb, rxlen) - 8;
 
-   /* align the packet length to 4 bytes, and add 4 bytes
-* as we're getting the rx status header as well */
-   ks8851_rdfifo(ks, rxpkt, ALIGN(rxlen, 4) + 8);
+   ks8851_rdfifo(ks, rxpkt, rxalign + 8);
 
-   if (netif_msg_pktdata(ks))
-   ks8851_dbg_dumpkkt(ks, rxpkt);
+   if (netif_msg_pktdata(ks))
+   ks8851_dbg_dumpkkt(ks, rxpkt);
 
-   skb->protocol = eth_type_trans(skb, ks->netdev);
-   netif_rx(skb);
+   skb->protocol = eth_type_trans(skb, ks->netdev);
+   netif_rx(skb);
 
-   ks->netdev->stats.rx_packets++;
-   ks->netdev->stats.rx_bytes += rxlen - 4;
+   ks->netdev->stats.rx_packets++;
+   ks->netdev->stats.rx_bytes += rxlen;
+   }
}
 
ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
-- 
1.6.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

[PATCH 0/7] omap4: Fixes, hacks for es2.0

[Santosh Shilimkar]

This series has few fixes, hacks to get omap4 es2.0 working
on mainline. The patches are generated against the mainline 
2.6.36-rc3. 


The series is boot tested tested on 4430 SDP, Blaze with 
omap_4430sdp_defconfig with file over NFS and MMC.

Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
SDPs. Same observation with Panda

With omap3_defconfig, MMC while mounting the rootfs over MMC, the
boot hangs. Same observation with Panda

[5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on
[5.802764] regulator_init_complete: incomplete constraints, leaving VPP on
[5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC 
(9  )
[5.849304] mmc0: new high speed MMC card at address 0001
[5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
[5.862091]  mmcblk0: unknown partition table
[6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 
0: 6
[   18.424407] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
[   18.431823] Please append a correct "root=" boot option; here are the 
available  ons:
[   18.440643] b300 7757824 mmcblk0 driver: mmcblk
[   18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown

All these patches are also available at:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary
head: omap4-for-tony

David Anders (1):
  omap4: Panda: Add DEBUG_LL support

Eric Dumazet (1):
  KS8851: Correct RX packet allocation

Madhusudhan Chikkature (1):
  omap4: Workaround for CMD line reset.

Santosh Shilimkar (4):
  omap4: Update id.c and cpu.h for es2.0
  omap4: Temporary fix silicon version detection
  omap4: l2x0: Fix init parameter for ES2.0
  omap4: Fix bootup crash observed with higher CPU clocks

 arch/arm/mach-omap2/id.c |   39 +
 arch/arm/mach-omap2/omap4-common.c   |5 ++-
 arch/arm/plat-omap/dmtimer.c |2 +-
 arch/arm/plat-omap/include/plat/cpu.h|5 ++-
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 drivers/mmc/host/omap_hsmmc.c|8 +
 drivers/net/ks8851.c |   39 ++
 7 files changed, 71 insertions(+), 28 deletions(-)

--
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 6/7] omap4: Workaround for CMD line reset.

[Santosh Shilimkar]

From: Madhusudhan Chikkature 

Add a delay after CMD line reset to accomdate the reset to complete.
The SYSCTL seems to reflect SRC immediately which might not really
be indicating the complete of reset. This is observed only with ES2.0
silicon

Signed-off-by: Madhusudhan Chikkature 
---
 drivers/mmc/host/omap_hsmmc.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4a8776f..1c359f0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -986,6 +986,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
(i++ < limit))
cpu_relax();
 
+   /*
+* On OMAP4 ES2 the SRC is zero in the first loop itself strangely
+* vs on ES1 it takes some time.
+* Could be a an issue on ES2 to indicate reset complete even before
+* it is complete.
+*/
+   udelay(500);
+
if (OMAP_HSMMC_READ(host->base, SYSCTL) & bit)
dev_err(mmc_dev(host->mmc),
"Timeout waiting on controller reset in %s\n",
-- 
1.6.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

[PATCH 4/7] omap4: Panda: Add DEBUG_LL support

[Santosh Shilimkar]

From: David Anders 

Add support for use of DEBUG_LL for use with PandaBoard.

Signed-off-by: David Anders 
---
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index ddf723b..57dffa7 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -153,6 +153,7 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
 
/* omap4 based boards using UART3 */
DEBUG_LL_OMAP4(3, omap_4430sdp);
+   DEBUG_LL_OMAP4(3, omap4_panda);
 
/* zoom2/3 external uart */
DEBUG_LL_ZOOM(omap_zoom2);
-- 
1.6.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

[PATCH 2/7] omap4: Temporary fix silicon version detection

[Santosh Shilimkar]

Few initial omap4 es2 samples IDCODE is same as es1. This patch
uses ARM cpuid register to detect the ES version for such samples

This patch can be reverted once all the samples gets replaced
with new lot.

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/id.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a423c7f..487e8d6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
hawkeye = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xff;
 
+   /*
+* FIXME: This patch should be reverted later.
+* Few initial ES2.0 samples IDCODE is same as ES1.0
+* Use ARM register to detect the correct ES version
+*/
+   if (!rev) {
+   idcode = read_cpuid(CPUID_ID);
+   rev = (idcode & 0xf) - 1;
+   }
+
switch (hawkeye) {
case 0xb852:
switch (rev) {
-- 
1.6.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

[PATCH 1/7] omap4: Update id.c and cpu.h for es2.0

[Santosh Shilimkar]

This patch updates the id.c and cpu.h files to support
omap4 ES2.0 silicon detection.

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/id.c  |   29 ++---
 arch/arm/plat-omap/include/plat/cpu.h |5 -
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9a879f9..a423c7f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -298,7 +298,6 @@ static void __init omap4_check_revision(void)
u32 idcode;
u16 hawkeye;
u8 rev;
-   char *rev_name = "ES1.0";
 
/*
 * The IC rev detection is done with hawkeye and rev.
@@ -309,14 +308,30 @@ static void __init omap4_check_revision(void)
hawkeye = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xff;
 
-   if ((hawkeye == 0xb852) && (rev == 0x0)) {
-   omap_revision = OMAP4430_REV_ES1_0;
-   omap_chip.oc |= CHIP_IS_OMAP4430ES1;
-   pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
-   return;
+   switch (hawkeye) {
+   case 0xb852:
+   switch (rev) {
+   case 0:
+   omap_revision = OMAP4430_REV_ES1_0;
+   omap_chip.oc |= CHIP_IS_OMAP4430ES1;
+   break;
+   case 1:
+   omap_revision = OMAP4430_REV_ES2_0;
+   omap_chip.oc |= CHIP_IS_OMAP4430ES2;
+   break;
+   default:
+   omap_revision = OMAP4430_REV_ES2_0;
+   omap_chip.oc |= CHIP_IS_OMAP4430ES2;
+   }
+   break;
+   default:
+   /* Unknown default to latest silicon rev as default*/
+   omap_revision = OMAP4430_REV_ES2_0;
+   omap_chip.oc |= CHIP_IS_OMAP4430ES2;
}
 
-   pr_err("Unknown OMAP4 CPU id\n");
+   pr_info("OMAP%04x ES%d.0\n",
+   omap_rev() >> 16, ((omap_rev() >> 12) & 0xf) + 1);
 }
 
 #define OMAP3_SHOW_FEATURE(feat)   \
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e2ae53..9b38e4b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -391,6 +391,7 @@ IS_OMAP_TYPE(3517, 0x3517)
 
 #define OMAP443X_CLASS 0x44300044
 #define OMAP4430_REV_ES1_0 0x44300044
+#define OMAP4430_REV_ES2_0 0x44301044
 
 /*
  * omap_chip bits
@@ -417,10 +418,12 @@ IS_OMAP_TYPE(3517, 0x3517)
 #define CHIP_IS_OMAP4430ES1(1 << 8)
 #define CHIP_IS_OMAP3630ES1_1   (1 << 9)
 #define CHIP_IS_OMAP3630ES1_2   (1 << 10)
+#define CHIP_IS_OMAP4430ES2(1 << 11)
 
 #define CHIP_IS_OMAP24XX   (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
 
-#define CHIP_IS_OMAP4430   (CHIP_IS_OMAP4430ES1)
+#define CHIP_IS_OMAP4430   (CHIP_IS_OMAP4430ES1 | \
+CHIP_IS_OMAP4430ES2)
 
 /*
  * "GE" here represents "greater than or equal to" in terms of ES
-- 
1.6.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

[PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0

[Santosh Shilimkar]

On ES2.0 the L2 cache init parameter ineeds to be changed to take
care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0

This patch fixes the init parameter to update the same using
dynamic cpu version check

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap4-common.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 13dc979..2b32229 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void)
 * 32KB way size, 16-way associativity,
 * parity disabled
 */
-   l2x0_init(l2cache_base, 0x0e05, 0xcfff);
+   if (omap_rev() == OMAP4430_REV_ES2_0)
+   l2x0_init(l2cache_base, 0x0e07, 0xcfff);
+   else
+   l2x0_init(l2cache_base, 0x0e05, 0xcfff);
 
return 0;
 }
-- 
1.6.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

[PATCH 5/7] omap4: Fix bootup crash observed with higher CPU clocks

[Santosh Shilimkar]

This patch is temporary fix to below crash. This is observed when
CPU is clocked more than 600 MHz.

Unhandled fault: imprecise external abort (0x1406) at 0xbf9ef65c
Internal error: : 1406 [#1] PREEMPT SMP
last sysfs file:
Modules linked in:
CPU: 0Not tainted  (2.6.36-rc3+ #18)
PC is at kernel_thread_helper+0x0/0x14
LR is at kernel_thread_helper+0x0/0x14
pc : []lr : []psr: 0093
sp : dc83bff8  ip :   fp : 
r10:   r9 :   r8 : 
r7 : 0013  r6 : c003ce28  r5 : c008935c  r4 : 
r3 :   r2 :   r1 :   r0 : 
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7f  Table: 8000404a  DAC: 0017
Process swapper (pid: 2, stack limit = 0xdc83a2f0)
Stack: (0xdc83bff8 to 0xdc83c000)
bfe0:  
[] (kernel_thread_helper+0x0/0x14) from [] (0xfffe)
Code: c03a0ba3 c03a5fcb c045c880 c0394035 (eb017701)
---[ end trace 1b75b31a2719ed1c ]---

The timer hwmod adaptation will eventually fix it in a proper way.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Santosh Shilimkar 
---
 arch/arm/plat-omap/dmtimer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 44bafda..1d706cf 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -581,7 +581,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
 * When the functional clock disappears, too quick writes seem
 * to cause an abort. XXX Is this still necessary?
 */
-   __delay(15);
+   __delay(30);
 
return ret;
 }
-- 
1.6.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 v2 1/2] OMAP: DSS2: Introduce dss_features files

[Taneja, Archit]

Tomi Valkeinen wrote:
> On Thu, 2010-09-09 at 12:53 +0200, ext Taneja, Archit wrote:
>> Hi,
>> 
>> Tomi Valkeinen wrote:
>>> Hi,
>>> 
>>> On Wed, 2010-09-08 at 13:17 +0200, ext Archit Taneja wrote:
 Add dss_features.c and dss_features.h for the dss_features framework
 
 Signed-off-by: Archit Taneja 
 ---
  drivers/video/omap2/dss/dss_features.c |  171
>>> 
  drivers/video/omap2/dss/dss_features.h |   51 ++
  2 files changed, 222 insertions(+), 0 deletions(-)  create mode
 100644 drivers/video/omap2/dss/dss_features.c
  create mode 100644 drivers/video/omap2/dss/dss_features.h
 
 diff --git a/drivers/video/omap2/dss/dss_features.c
 b/drivers/video/omap2/dss/dss_features.c
 new file mode 100644
 index 000..e87816f
 --- /dev/null
 +++ b/drivers/video/omap2/dss/dss_features.c
 @@ -0,0 +1,171 @@
 +/*
 + * linux/drivers/video/omap2/dss/dss_features.c
 + *
 + * Copyright (C) 2010 Texas Instruments
 + * Author: Archit Taneja 
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful, ++but
 WITHOUT + * ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY +or + * FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public +License for + * more details.
 + *
 + * You should have received a copy of the GNU General Public + License
 +along with + * this program.  If not, see
> .
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +
 +#include "dss_features.h"
 +
 +/* Defines a generic omap register field */ struct dss_reg_field { +  
 enum
 dss_feat_reg_field id; +   u8 start, end;
 +};
 +
 +struct omap_dss_features {
 +  struct dss_reg_field reg_fields[MAX_DSS_REG_FIELDS];
>>> 
>>> Perhaps this should be a pointer to a list, and add a separate field
>>> for num_reg_fields. That way you don't need a MAX_DSS_REG_FIELDS
>>> definition.
>> 
>> If it is a pointer to a list then we can't initialize things
>> statically, won't we need functions at runtime to add to the list of
>> reg_fields etc, this is what I did in v1?
> 
> Something like:
> 
> static struct dss_reg_field omap2_dss_reg_fields[] = {   {FIRHINC, 11, 0},
>   {FIRVINC, 27, 16},
>   {FIFOLOWTHRESHOLD, 8, 0},
>   {FIFOHIGHTHRESHOLD, 24, 16},
>   {FIFOSIZE, 8, 0},
> };
> 
> static struct omap_dss_features omap2_dss_features = {
>.num_reg_fields = ARRAY_SIZE(omap2_dss_reg_fields),
>.reg_fields = omap2_dss_reg_fields,
> 
> ...

Oh okay..I will make this change..what do we do about dss_feature_functions?
Should I rework dss_init_overlays and dss_init_overlay_managers to loop based
on the enums ion display.h?

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

RE: [PATCH v2 1/2] OMAP: DSS2: Introduce dss_features files

[Tomi Valkeinen]

On Thu, 2010-09-09 at 12:53 +0200, ext Taneja, Archit wrote:
> Hi,
> 
> Tomi Valkeinen wrote:
> > Hi,
> > 
> > On Wed, 2010-09-08 at 13:17 +0200, ext Archit Taneja wrote:
> >> Add dss_features.c and dss_features.h for the dss_features framework
> >> 
> >> Signed-off-by: Archit Taneja 
> >> ---
> >>  drivers/video/omap2/dss/dss_features.c |  171
> > 
> >>  drivers/video/omap2/dss/dss_features.h |   51 ++
> >>  2 files changed, 222 insertions(+), 0 deletions(-)  create mode
> >> 100644 drivers/video/omap2/dss/dss_features.c
> >>  create mode 100644 drivers/video/omap2/dss/dss_features.h
> >> 
> >> diff --git a/drivers/video/omap2/dss/dss_features.c
> >> b/drivers/video/omap2/dss/dss_features.c
> >> new file mode 100644
> >> index 000..e87816f
> >> --- /dev/null
> >> +++ b/drivers/video/omap2/dss/dss_features.c
> >> @@ -0,0 +1,171 @@
> >> +/*
> >> + * linux/drivers/video/omap2/dss/dss_features.c
> >> + *
> >> + * Copyright (C) 2010 Texas Instruments
> >> + * Author: Archit Taneja 
> >> + *
> >> + * 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.
> >> + *
> >> + * This program is distributed in the hope that it will be useful, +but
> >> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> >> MERCHANTABILITY +or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >> General Public +License for + * more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License 
> >> +along
> >> with + * this program.  If not, see . + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +
> >> +#include "dss_features.h"
> >> +
> >> +/* Defines a generic omap register field */ struct dss_reg_field { +  
> >> enum
> >> dss_feat_reg_field id; +   u8 start, end;
> >> +};
> >> +
> >> +struct omap_dss_features {
> >> +  struct dss_reg_field reg_fields[MAX_DSS_REG_FIELDS];
> > 
> > Perhaps this should be a pointer to a list, and add a
> > separate field for num_reg_fields. That way you don't need a
> > MAX_DSS_REG_FIELDS definition.
> 
> If it is a pointer to a list then we can't initialize things statically, won't
> we need functions at runtime to add to the list of reg_fields etc, this is 
> what
> I did in v1?

Something like:

static struct dss_reg_field omap2_dss_reg_fields[] =
{
  {FIRHINC, 11, 0},
  {FIRVINC, 27, 16},
  {FIFOLOWTHRESHOLD, 8, 0},
  {FIFOHIGHTHRESHOLD, 24, 16},
  {FIFOSIZE, 8, 0},
};

static struct omap_dss_features omap2_dss_features = {
   .num_reg_fields = ARRAY_SIZE(omap2_dss_reg_fields),
   .reg_fields = omap2_dss_reg_fields,

...

 Tomi



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

RE: [PATCH v2 1/2] OMAP: DSS2: Introduce dss_features files

[Taneja, Archit]

Hi,

Tomi Valkeinen wrote:
> Hi,
> 
> On Wed, 2010-09-08 at 13:17 +0200, ext Archit Taneja wrote:
>> Add dss_features.c and dss_features.h for the dss_features framework
>> 
>> Signed-off-by: Archit Taneja 
>> ---
>>  drivers/video/omap2/dss/dss_features.c |  171
> 
>>  drivers/video/omap2/dss/dss_features.h |   51 ++
>>  2 files changed, 222 insertions(+), 0 deletions(-)  create mode
>> 100644 drivers/video/omap2/dss/dss_features.c
>>  create mode 100644 drivers/video/omap2/dss/dss_features.h
>> 
>> diff --git a/drivers/video/omap2/dss/dss_features.c
>> b/drivers/video/omap2/dss/dss_features.c
>> new file mode 100644
>> index 000..e87816f
>> --- /dev/null
>> +++ b/drivers/video/omap2/dss/dss_features.c
>> @@ -0,0 +1,171 @@
>> +/*
>> + * linux/drivers/video/omap2/dss/dss_features.c
>> + *
>> + * Copyright (C) 2010 Texas Instruments
>> + * Author: Archit Taneja 
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful, +but
>> WITHOUT + * ANY WARRANTY; without even the implied warranty of
>> MERCHANTABILITY +or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> General Public +License for + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License +along
>> with + * this program.  If not, see . + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#include "dss_features.h"
>> +
>> +/* Defines a generic omap register field */ struct dss_reg_field { +
>> enum
>> dss_feat_reg_field id; + u8 start, end;
>> +};
>> +
>> +struct omap_dss_features {
>> +struct dss_reg_field reg_fields[MAX_DSS_REG_FIELDS];
> 
> Perhaps this should be a pointer to a list, and add a
> separate field for num_reg_fields. That way you don't need a
> MAX_DSS_REG_FIELDS definition.

If it is a pointer to a list then we can't initialize things statically, won't
we need functions at runtime to add to the list of reg_fields etc, this is what
I did in v1?

> 
>> +u32 has_feature;
>> +
>> +int num_mgrs;
>> +int num_ovls;
>> +enum omap_display_type supported_displays[MAX_DSS_MANAGERS];
>> +enum omap_color_mode supported_color_modes[MAX_DSS_OVERLAYS];
> 
> Perhaps same could be done here.
> 
>> +};
>> +
>> +/* This struct is assigned to one of the below during initialization
>> +*/ static struct omap_dss_features omap_current_dss_features; +
>> +/* OMAP2 DSS Features */
>> +static struct omap_dss_features omap2_dss_features = { +.reg_fields = {
>> +{FIRHINC, 11, 0},
>> +{FIRVINC, 27, 16},
>> +{FIFOLOWTHRESHOLD, 8, 0},
>> +{FIFOHIGHTHRESHOLD, 24, 16},
>> +{FIFOSIZE, 8, 0},
> 
> You should have space after { and before }.

I will correct this.

> 
>> +},
>> +
>> +.num_mgrs = 2,
>> +.num_ovls = 3,
>> +.supported_displays = {
>> +/* OMAP_DSS_CHANNEL_LCD */
>> +OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
>> +OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
>> +
>> +/* OMAP_DSS_CHANNEL_DIGIT */
>> +OMAP_DISPLAY_TYPE_VENC,
>> +},
>> +.supported_color_modes = {
>> +/* OMAP_DSS_GFX */
>> +OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
>> +OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
>> +OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
>> +OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P,
>> +
>> +/* OMAP_DSS_VIDEO1 */
>> +OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
>> +OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
>> +OMAP_DSS_COLOR_UYVY,
>> +
>> +/* OMAP_DSS_VIDEO2 */
>> +OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
>> +OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
>> +OMAP_DSS_COLOR_UYVY,
>> +},
>> +};
>> +
>> +/* OMAP3 DSS Features */
>> +static struct omap_dss_features omap3_dss_features = { +.reg_fields = {
>> +{FIRHINC, 12, 0},
>> +{FIRVINC, 28, 16},
>> +{FIFOLOWTHRESHOLD, 11, 0},
>> +{FIFOHIGHTHRESHOLD, 27, 16},
>> +{FIFOSIZE, 10, 0},
>> +},
>> +.has_feature= FEAT_GLOBAL_ALPHA,
>> +
>> +.num_mgrs = 2,
>> +.num_ovls = 3,
>> +.supported_displays = {
>> +/* OMAP_DSS_CHANNEL_LCD */
>> +OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
>> +OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
>> +
>> +/* OMAP_DSS_CHANNEL_DIGIT */
>> +OMAP_DISPLAY_TYPE_VENC,
>> +},
>> +.supported_color_modes = {
>> +/* OMAP_DSS_GFX */
>> +OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLO

RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig

[Premi, Sanjeev]

 

> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] 
> Sent: Thursday, September 09, 2010 11:52 AM
> To: Balbi, Felipe
> Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
> 
> On Thu, 9 Sep 2010 07:58:55 +0200
> ext Felipe Balbi  wrote:
> 
> > On Thu, Sep 09, 2010 at 12:04:45AM -0500, Hiroshi DOYU wrote:
> > >Hi Sanjeev,
> > >
> > >From: ext Sanjeev Premi 
> > >Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
> > >Date: Wed, 8 Sep 2010 16:51:21 +0200
> > >
> > >> The menu option to select CONFIG_OMAP_IOMMU
> > >> was not visible in the menuconfig due to missing
> > >> description.
> > >
> > >There's no point to make OMAP_IOMMU visible since this is a kind of
> > >feature used by other device implicitly. OMAP_IOMMU on 
> menu might confuse
> > >users at kernel menuconfig. Instead this should be automatically
> > >selected by its clients when it is selected. For exmaple, the case
> > >that DSP or Tesla is selected. There was a discussion about this
> > >before.
> > 
> > in that case...
> > 
> > >> @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE
> > >>module parameter).
> > >>
> > >>  config OMAP_IOMMU
> > >> -tristate
> > >> +tristate "OMAP IOMMU support"
> > 
> > it doesn't have to be tristate as select will always mark it 'y'
> 
> Right;p
> 
[sp] So, we will need to "select" this option with ARCH_OMAP3.
 And maybe for OMAP4...

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

Re: [PATCH v2 2/2] OMAP: DSS2: Use dss_features framework on DSS2 code

[Tomi Valkeinen]

On Wed, 2010-09-08 at 13:17 +0200, ext Archit Taneja wrote:
> calls init functions of dss_features during dss_probe, and the following
> features are made omap independent:
>   - number of managers, overlays
>   - supported color modes for each overlay
>   - supported displays for each manager
>   - global aplha, and restriction of global alpha for video1 pipeline
>   - The register field ranges : FIRHINC, FIRVINC, FIFOHIGHTHRESHOLD
> FIFOLOWTHRESHOLD and FIFOSIZE
> 
> Signed-off-by: Archit Taneja 


> diff --git a/drivers/video/omap2/dss/Makefile 
> b/drivers/video/omap2/dss/Makefile
> index d71b5d9..7db17b5
> --- a/drivers/video/omap2/dss/Makefile
> +++ b/drivers/video/omap2/dss/Makefile
> @@ -1,5 +1,5 @@
>  obj-$(CONFIG_OMAP2_DSS) += omapdss.o
> -omapdss-y := core.o dss.o dispc.o display.o manager.o overlay.o
> +omapdss-y := core.o dss.o dss_features.o dispc.o display.o manager.o 
> overlay.o

I think this change should be in the previous patch.

 Tomi


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

Re: [PATCH v2 1/2] OMAP: DSS2: Introduce dss_features files

[Tomi Valkeinen]

Hi,

On Wed, 2010-09-08 at 13:17 +0200, ext Archit Taneja wrote:
> Add dss_features.c and dss_features.h for the dss_features framework
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/video/omap2/dss/dss_features.c |  171 
> 
>  drivers/video/omap2/dss/dss_features.h |   51 ++
>  2 files changed, 222 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/video/omap2/dss/dss_features.c
>  create mode 100644 drivers/video/omap2/dss/dss_features.h
> 
> diff --git a/drivers/video/omap2/dss/dss_features.c 
> b/drivers/video/omap2/dss/dss_features.c
> new file mode 100644
> index 000..e87816f
> --- /dev/null
> +++ b/drivers/video/omap2/dss/dss_features.c
> @@ -0,0 +1,171 @@
> +/*
> + * linux/drivers/video/omap2/dss/dss_features.c
> + *
> + * Copyright (C) 2010 Texas Instruments
> + * Author: Archit Taneja 
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "dss_features.h"
> +
> +/* Defines a generic omap register field */
> +struct dss_reg_field {
> + enum dss_feat_reg_field id;
> + u8 start, end;
> +};
> +
> +struct omap_dss_features {
> + struct dss_reg_field reg_fields[MAX_DSS_REG_FIELDS];

Perhaps this should be a pointer to a list, and add a separate field for
num_reg_fields. That way you don't need a MAX_DSS_REG_FIELDS definition.

> + u32 has_feature;
> +
> + int num_mgrs;
> + int num_ovls;
> + enum omap_display_type supported_displays[MAX_DSS_MANAGERS];
> + enum omap_color_mode supported_color_modes[MAX_DSS_OVERLAYS];

Perhaps same could be done here.

> +};
> +
> +/* This struct is assigned to one of the below during initialization */
> +static struct omap_dss_features omap_current_dss_features;
> +
> +/* OMAP2 DSS Features */
> +static struct omap_dss_features omap2_dss_features = {
> + .reg_fields = {
> + {FIRHINC, 11, 0},
> + {FIRVINC, 27, 16},
> + {FIFOLOWTHRESHOLD, 8, 0},
> + {FIFOHIGHTHRESHOLD, 24, 16},
> + {FIFOSIZE, 8, 0},

You should have space after { and before }.

> + },
> +
> + .num_mgrs = 2,
> + .num_ovls = 3,
> + .supported_displays = {
> + /* OMAP_DSS_CHANNEL_LCD */
> + OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
> + OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
> +
> + /* OMAP_DSS_CHANNEL_DIGIT */
> + OMAP_DISPLAY_TYPE_VENC,
> + },
> + .supported_color_modes = {
> + /* OMAP_DSS_GFX */
> + OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
> + OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
> + OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
> + OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P,
> +
> + /* OMAP_DSS_VIDEO1 */
> + OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
> + OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
> + OMAP_DSS_COLOR_UYVY,
> +
> + /* OMAP_DSS_VIDEO2 */
> + OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
> + OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
> + OMAP_DSS_COLOR_UYVY,
> + },
> +};
> +
> +/* OMAP3 DSS Features */
> +static struct omap_dss_features omap3_dss_features = {
> + .reg_fields = {
> + {FIRHINC, 12, 0},
> + {FIRVINC, 28, 16},
> + {FIFOLOWTHRESHOLD, 11, 0},
> + {FIFOHIGHTHRESHOLD, 27, 16},
> + {FIFOSIZE, 10, 0},
> + },
> + .has_feature= FEAT_GLOBAL_ALPHA,
> +
> + .num_mgrs = 2,
> + .num_ovls = 3,
> + .supported_displays = {
> + /* OMAP_DSS_CHANNEL_LCD */
> + OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
> + OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
> +
> + /* OMAP_DSS_CHANNEL_DIGIT */
> + OMAP_DISPLAY_TYPE_VENC,
> + },
> + .supported_color_modes = {
> + /* OMAP_DSS_GFX */
> + OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
> + OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
> + OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16 |
> + OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
> + OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_ARGB32 |
> + OMAP_DSS_COLOR_RGBA32 | OMA

Re: [PATCH 1/5] ARM: omap/fb: move omap_init_fb to .init.text

[Tomi Valkeinen]

Hi,

On Thu, 2010-09-02 at 10:03 +0200, ext Uwe Kleine-König wrote:
> omap_init_fb() is only called as arch_initcall and so can live in
> .init.text.
> 
> Signed-off-by: Uwe Kleine-König 

I picked patches 1, 2 and 3 from this patch set to my tree. They look
fine, thanks!

Patch 4 should probably go through Tony, and 5 was marked
work-in-progress.

 Tomi


--
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 to fix swapping of front and back porches when reading from modedb.c

[Tomi Valkeinen]

On Wed, 2010-09-08 at 15:38 +0200, ext Russ Dill wrote:
> On Wed, Sep 8, 2010 at 6:39 AM, Tasslehoff Kjappfot  
> wrote:
> >
> >
> > Hi list :-)
> >
> > I had trouble getting a standard 800x...@60hz VGA signal to display
> > correctly on my monitors. Measuring the output showed that the front and
> > back porches were swapped both for hsync and vsync. After reading the source
> > I think I found the error in drivers/video/omap2/omapfb/omapfb-main.c. Patch
> > attached.
> >
> > http://www.xfree86.org/3.3.6/fbdev6.html shows the way it should be, but
> > todays code sets:
> >
> > hfp = left margin
> > hbp = right margin
> > vfp = upper margin
> > vbp = lower margin
> >
> > I tested a patched kernel with 800x...@60hz on two different monitors and a
> > vga grabber, and it solved my issues.
> 
> This looks good. Before this came up, I also thought that front porch
> meant left margin, and back porch meant margin, but margins are named
> in relation to pixel data, and porches are named in relation to sync
> pulses.

Ah, that's new to me too =). After a few minutes of googling, it's quite
clear that the patch is correct.

Thanks! I improved the patch description a bit, and added it to my tree.

 Tomi


--
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] tracing, perf: add more power related events

[Ingo Molnar]

* Jean Pihet  wrote:

> On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar  wrote:
> >
> > * Jean Pihet  wrote:
> >
> >> Hi,
> >>
> >> Here is a patch proposal for adding new trace events for power management.
> >> Note: thread restarted after the initial discussions on LKML.
> >
> > Also mind including the ACPI tracepoints we talked about? That way a lot
> > more people could test it, etc.
>
> I think the ACPI tracepoints can be added on top of the proposed 
> patch. Is that ok?

Yeah - and the OMAP thing can be split up too if the OMAP folks prefer 
it that way, but we still want to _see_ all the patches in this thread 
together so that we have a critical mass of people interested in all 
this ...

Thanks,

Ingo
--
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] tracing, perf: add more power related events

[Jean Pihet]

On Wed, Sep 8, 2010 at 8:53 AM, Ingo Molnar  wrote:
>
> * Jean Pihet  wrote:
>
>> Hi,
>>
>> Here is a patch proposal for adding new trace events for power management.
>> Note: thread restarted after the initial discussions on LKML.
>
> Also mind including the ACPI tracepoints we talked about? That way a lot
> more people could test it, etc.
I think the ACPI tracepoints can be added on top of the proposed
patch. Is that ok?

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