Re: [PATCH v4 0/6] Touchscreen performance related fixes

2014-12-16 Thread Richard Cochran
On Tue, Dec 16, 2014 at 10:31:47AM +0200, Catalin Crenguta wrote: It seems that because the ribbon cable has both the analog and digital signals, the analog signals are affected by the digital ones (hence the touchscreen was working OK when the display was disabled). Putting decoupling

Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2014-11-24 Thread Richard Cochran
On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote: On 11/21/2014 02:10 PM, Richard Cochran wrote: On the BB white using the LCD4 cape and the shipped debian kernel, the cursor *does* jump away, but not as often or as far as on the custom design I was working

Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2014-11-21 Thread Richard Cochran
On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote: Not sure how to reproduce the jumping on pen-up. Does the cursor stay in exactly the same spot when you lift up the stylus? Then you don't have the issue. On the BB white using the LCD4 cape and the shipped debian kernel, the cursor

Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2014-11-21 Thread Richard Cochran
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote: Before the patches were also jumps but I thought it is something Vignesh should know. Maybe there is some fix for that too? As Richard also noted, it would be nice if ti could let us know how to get the delay values right. By

Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2014-11-20 Thread Richard Cochran
Brad, What you wrote is just the kind of thing one would like to see in the cover letter or change log... On Thu, Nov 20, 2014 at 02:23:30PM +, Griffis, Brad wrote: In that thread the user was registering multiple press events for a single press. By increasing the udelay to 1.5ms they

Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

2014-11-20 Thread Richard Cochran
On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote: I tested this using lcd7 cape connected to beaglebone black. The latest kernel I could find on this board was a TI BSP based v3.14 kernel. So I had to port these patches to that kernel. Cc Robert Nelson to see if he knows about a

Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler

2014-11-17 Thread Richard Cochran
On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote: My patches are based on v3.18rc2. I tested my patches on am335x-evm using tslib. No beaglebone + cape testing? Please explain touch is broken? What is the behaviour of TSC? With plain v3.17 plus your series, the cursor is almost

Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler

2014-11-15 Thread Richard Cochran
On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote: From: Brad Griffis bgrif...@ti.com TSC interrupt handler had udelay to avoid reporting of false pen-up interrupt to user space. This patch implements workaround suggesting in Advisory 1.0.31 of silicon errata for am335x, thus

Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps

2014-11-07 Thread Richard Cochran
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote: Currently, there is too much noise in the TSC hardware that is being removed by delta filtering. The so called filter was only programmed because the fifo entries were being mixed up. Sebastian fixed that. I tested TSC unit by

Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps

2014-11-07 Thread Richard Cochran
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote: Currently, there is too much noise in the TSC hardware that is being removed by delta filtering. I tested TSC unit by removing filtering logic, the performance was not at all satisfactory. The cursor jumps wayward and smooth circles

Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps

2014-11-06 Thread Richard Cochran
On Mon, Oct 27, 2014 at 04:38:28PM +0530, Vignesh R wrote: ... @@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev, unsigned int read, diff; unsigned int i, channel; unsigned int creads = ts_dev-coordinate_readouts; + unsigned int first_step =

Re: [PATCH 0/4] Touchscreen performance related fixes

2014-11-03 Thread Richard Cochran
On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement

Re: [PATCH v2 0/6] Add CPTS support for AM437x

2014-05-04 Thread Richard Cochran
. v1 - v2 Patch 1 and 2 Re-ordering. Seperate TS_BITS define for Hw version V2 and V3 Acked-by: Richard Cochran richardcoch...@gmail.com -- 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

Re: [PATCH 1/6] drivers: net: cpts: Remove hardcoded clock name for CPTS

2014-04-28 Thread Richard Cochran
On Mon, Apr 28, 2014 at 09:40:20AM +0530, George Cherian wrote: CPTS refclk name is hardcoded, which makes it fail in case of DRA7x Remove the hardcoded clock name for CPTS refclk and get the same from DT. Patch ordering - doesn't this patch depend on patch #2? Thanks, Richard -- To

Re: [PATCH 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk

2014-04-28 Thread Richard Cochran
On Mon, Apr 28, 2014 at 09:40:24AM +0530, George Cherian wrote: cpsw_cpts_rft_clk has got the choice of 3 clocksources -dpll_core_m4_ck -dpll_core_m5_ck -dpll_disp_m2_ck By default dpll_core_m4_ck is selected, witn this as clock source the CPTS doesnot work properly. It gives clockcheck

Re: [PATCH 4/6] drivers: net: cpsw: Enable Annexe F Time sync

2014-04-28 Thread Richard Cochran
On Mon, Apr 28, 2014 at 09:40:23AM +0530, George Cherian wrote: Enable the Annex F Time Sync explicitly for DRA7x and AM4372. With this enabled the L2 PTP is working. L2 works fine without this bit. If this is needed for V3 hardware, then it should have its own code variant. while at that

Re: [PATCH 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk

2014-04-28 Thread Richard Cochran
On Mon, Apr 28, 2014 at 06:25:56PM +0530, George Cherian wrote: In beagle bone white (AM335x) CPTS has a choice of 2 clocksource -dpll_core_m5_ck -dpll_core_m4_ck and by default dpll_core_m5_ck is used. Where as in AM437x the default clocksource used is dpll_core_m4_ck . Is your patch

Re: [PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes

2013-10-25 Thread Richard Cochran
On Tue, Sep 17, 2013 at 03:30:23PM +0200, Benoit Cousson wrote: I've just applied it on top of Joel's one. Benoit, Can you tell me where to find your git tree so that I can follow these patches' progress? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 05:42:26PM +0530, Mugunthan V N wrote: The new IP version has a minor changes and the offsets are same as the previous version, so instead of adding CPSW version number in the driver, make the driver to fall through to the latest versions so that the new version of

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 06:28:27PM +0300, Felipe Balbi wrote: On Wed, Jul 31, 2013 at 04:49:59PM +0200, Richard Cochran wrote: On Wed, Jul 31, 2013 at 05:42:26PM +0530, Mugunthan V N wrote: The new IP version has a minor changes and the offsets are same as the previous version, so

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 09:45:25PM +0300, Felipe Balbi wrote: On Wed, Jul 31, 2013 at 06:38:46PM +0200, Richard Cochran wrote: On Wed, Jul 31, 2013 at 06:28:27PM +0300, Felipe Balbi wrote: On Wed, Jul 31, 2013 at 04:49:59PM +0200, Richard Cochran wrote: On Wed, Jul 31, 2013 at 05:42:26PM

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 10:45:23PM +0300, Felipe Balbi wrote: one more thing, why do you consider a new revision to be an error ? Okay, so why don't you go and remove the version checking code altogether? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 11:07:56PM +0300, Felipe Balbi wrote: what I'm saying is that we can give new IP revision a chance to work if they have no programming model differences (except for, perhaps, new features and different erratas). But it also has a chance to fail when there are

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 11:26:17PM +0300, Felipe Balbi wrote: oh well, we can go on and on with this. Unfortunately we (SW team) don't have control over the HW folks. We strongly suggest that they don't break SW compatibility, and that's starting to become true. You can very well expect

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Thu, Aug 01, 2013 at 12:11:00AM +0300, Felipe Balbi wrote: that's the point, there is no known V3. Once it has, surely we will add such macros, but until then, we let the driver assume the highest known revision if it finds a register with an unknown revision. I am confused. The patch

Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version

2013-07-31 Thread Richard Cochran
On Wed, Jul 31, 2013 at 10:43:32PM +0300, Felipe Balbi wrote: right, now go check on the archives what Linus (and many others, for that matter) have said about version checking. If it's not the version you expect, you assume the latest. If you are talking about his essay about user space

Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting

2013-03-08 Thread Richard Cochran
On Fri, Mar 08, 2013 at 08:37:00PM +0530, Mugunthan V N wrote: As Peter Korsgaard mentioned we need to have infrastructure to handle CPSW kind of hardware. This will be a big job, I think, but I agree that it is worth doing. I can think of one other switch-with-host-port device. Maybe we

Re: [PATCH] cpsw: Fix interrupt storm among other things

2013-01-28 Thread Richard Cochran
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote: Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. While at it, added a non-NAPI mode (which is easier to debug), plus some general fixes. I have a few issues with this patch: 1. This is a networking

Re: [PATCH] cpsw: Fix interrupt storm among other things

2013-01-28 Thread Richard Cochran
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote: Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. While at it, added a non-NAPI mode (which is easier to debug), plus some general fixes. This patch does not apply to net-next. When you do post to

Re: [PATCH] cpsw: Fix interrupt storm among other things

2013-01-28 Thread Richard Cochran
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote: Hi Richard, Yes, I guess this was more of a drive-by patch dump - but people need this to get PG2.0 silicon to work on am33xx. And what is PG2.0? And no, I don't think having a non-NAPI code path is backwards, especially

Re: [PATCH] cpsw: Fix interrupt storm among other things

2013-01-28 Thread Richard Cochran
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote: Speaking of which, I'm probably the original developer of the fec driver. BTW, as I mentioned, someone is converting fec to napi. Care to take a look to make sure it is done right? Thanks, Richard -- To unsubscribe from this

Re: [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN

2013-01-28 Thread Richard Cochran
On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote: @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = { #ifdef CONFIG_NET_POLL_CONTROLLER .ndo_poll_controller= cpsw_ndo_poll_controller, #endif +#ifdef VLAN_SUPPORT + .ndo_vlan_rx_add_vid

Re: OMAP baseline test results for v3.8-rc4

2013-01-21 Thread Richard Cochran
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Thanks, Richard -- To unsubscribe from this list: send the line

Re: OMAP baseline test results for v3.8-rc4

2013-01-21 Thread Richard Cochran
On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote: On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote: On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8

Re: [PATCH 0/6] Introducing Device Tree Overlays

2013-01-05 Thread Richard Cochran
On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote: The problem being addressed is discussed in this thread: http://permalink.gmane.org/gmane.linux.kernel/1389017 Thanks for the link. Since the motivation is already documented in that post, why not add it into

Re: [PATCH 0/6] Introducing Device Tree Overlays

2013-01-04 Thread Richard Cochran
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote: The following patchset introduces Device Tree overlays, a method of dynamically altering the kernel's live Device Tree. It would be nice to know the motivation for this code. What is the use case? What problem or issue is being

Re: [PATCH 2/2] cpts: fix a run time warn_on.

2012-12-23 Thread Richard Cochran
On Sun, Dec 23, 2012 at 06:07:22PM +0400, Sergei Shtylyov wrote: Hello. On 22-12-2012 23:41, Richard Cochran wrote: This patch fixes a warning in clk_enable by calling clk_prepare first. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpts.c |1

[PATCH v2 0/2] cpts fixes for v3.8-rc2

2012-12-23 Thread Richard Cochran
Changed in v2: Use clk_prepare_enable instead of clk_prepare + clk_enable. The new cpts driver has two small issues, but it otherwise seems to be working in -rc1. Thanks, Richard Richard Cochran (2): cpts: fix build error by removing useless code. cpts: fix a run time warn_on. drivers/net

[PATCH v2 1/2] cpts: fix build error by removing useless code.

2012-12-23 Thread Richard Cochran
altogether. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpts.c |1 - drivers/net/ethernet/ti/cpts.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c index 5e62c1a

[PATCH 0/2] cpts fixes for v3.8-rc2

2012-12-22 Thread Richard Cochran
The new cpts driver has two small issues, but it otherwise seems to be working in -rc1. Thanks, Richard Richard Cochran (2): cpts: fix build error by removing useless code. cpts: fix a run time warn_on. drivers/net/ethernet/ti/cpts.c |2 +- drivers/net/ethernet/ti/cpts.h |1 - 2

Re: cpts: Fix build error caused by include of plat/clock.h

2012-12-14 Thread Richard Cochran
On Fri, Dec 14, 2012 at 10:55:56AM +0100, Koen Kooi wrote: Op 14 dec. 2012, om 08:13 heeft Richard Cochran richardcoch...@gmail.com het volgende geschreven: On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP

Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

2012-12-13 Thread Richard Cochran
On Thu, Dec 13, 2012 at 01:07:37PM +0200, Tomi Valkeinen wrote: Hi, On 2012-11-27 12:27, Mugunthan V N wrote: CC drivers/net/ethernet/ti/cpts.o drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory compilation terminated. make[4]: ***

Re: cpts: Fix build error caused by include of plat/clock.h

2012-12-13 Thread Richard Cochran
On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed?

Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

2012-11-27 Thread Richard Cochran
]: *** [drivers/net/ethernet/ti] Error 2 make[2]: *** [drivers/net/ethernet] Error 2 make[1]: *** [drivers/net] Error 2 fix for build break as the header file is removed from plat-omap as part of the below patch Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send

Re: [PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected

2012-11-27 Thread Richard Cochran
is not selected in Kernel Build. Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv Signed-off-by: Mugunthan V N mugunthan...@ti.com Thanks for this fix. Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap

Re: OMAP baseline test results for v3.7-rc5

2012-11-15 Thread Richard Cochran
On Tue, Nov 13, 2012 at 08:05:26PM +0400, Igor Mazanov wrote: Paul Walmsley wrote: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite * May

Re: [PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver

2012-11-06 Thread Richard Cochran
-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH RFC net-next 0/1] Simplify the CPSW DT

2012-11-03 Thread Richard Cochran
. Thanks, Richard Richard Cochran (1): cpsw: simplify the setup of the register pointers Documentation/devicetree/bindings/net/cpsw.txt | 34 drivers/net/ethernet/ti/cpsw.c | 209 +-- include/linux/platform_data/cpsw.h | 19 -- 3 files

Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX

2012-11-02 Thread Richard Cochran
On Fri, Nov 02, 2012 at 08:46:46AM +, N, Mugunthan V wrote: Do you expect to have several instance of the same IP with different parameters here? Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE, SLIVER, CPTS and SLAVES where is IP integrator can locate it

Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX

2012-11-02 Thread Richard Cochran
On Fri, Nov 02, 2012 at 10:42:04AM +, N, Mugunthan V wrote: I saw those posts. The CPSW ip version changes tracks the internal IP changes and there is no possible way to track the offset changes. For example CPTS sub module offsets in DM814x and AM335x are different though the CPTS

Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX

2012-11-01 Thread Richard Cochran
On Wed, Oct 31, 2012 at 04:17:27PM +0100, Benoit Cousson wrote: + compatible = ti,cpsw; + ti,hwmods = cpgmac0; + cpdma_channels = 8; + host_port_no = 0; + cpdma_reg_ofs = 0x800; +

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-29 Thread Richard Cochran
On Mon, Oct 29, 2012 at 04:58:23AM +, Hiremath, Vaibhav wrote: Now the expectation has grown to the level where people expect everything in the Mainline kernel and not in some custom kernel release. You are right, except for the has grown part. I have always expected the official kernel

Re: [PATCH-V2 0/4] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver

2012-10-29 Thread Richard Cochran
driver. [4/4]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file Many Thanks! Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-23 Thread Richard Cochran
On Tue, Oct 23, 2012 at 10:12:29AM +, Hiremath, Vaibhav wrote: I understand, and as you mentioned we are not fully there at v3.7-rc1 with all the drivers/module support, due to all known reasons. Its good that with v3.7-rc2, Beaglebone boots up out of box from mainline. Can you say

Re: OMAP baseline test results for v3.7-rc1

2012-10-21 Thread Richard Cochran
On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: Here's the console log from the boot test here: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt And here's the kernel config and uImage+DTB from the boot test here:

Re: OMAP baseline test results for v3.7-rc1

2012-10-21 Thread Richard Cochran
On Sun, Oct 21, 2012 at 08:23:35AM +, Paul Walmsley wrote: On Sun, 21 Oct 2012, Richard Cochran wrote: When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Really? What section of the message provided that to you? It was the part

Re: OMAP baseline test results for v3.7-rc1

2012-10-21 Thread Richard Cochran
On Sun, Oct 21, 2012 at 12:29:26PM +, Mohammed, Afzal wrote: Hi Richard, * Richard Cochran, October 21, 2012 1:05 PM: People keep saying, the beaglebone works fine with v3.7-rc1, but it isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been fixed, and no one

Re: OMAP baseline test results for v3.7-rc1

2012-10-20 Thread Richard Cochran
On Thu, Oct 18, 2012 at 05:20:46AM +, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ Changes from previous tests --- Kernel configs have been

Re: OMAP baseline test results for v3.7-rc1

2012-10-20 Thread Richard Cochran
On Sat, Oct 20, 2012 at 04:27:19PM +, Paul Walmsley wrote: BeagleBone Rev. A6 does not boot v3.7-rc1, at least not for me. I recently posted the missing patches needed to make it work (but the patches are not by me). Those are the patches at:

Re: OMAP baseline test results for v3.7-rc1

2012-10-20 Thread Richard Cochran
On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote: Just tried omap2plus_defconfig here and the board didn't boot, confirming your result. Will add a section to the testlog README.txt about that. In terms of differences from your setup, looks like we have different X-Loader

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-19 Thread Richard Cochran
On Thu, Oct 18, 2012 at 07:27:22PM +, Paul Walmsley wrote: I wrote that we'll schedule the SoC integration patch for sending upstream for 3.8. This does not necessarily mean that our upstreams will take it, or that it will result in a working CPSW. Forgive me for barking up the wrong

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-19 Thread Richard Cochran
On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote: Another important point is, this driver is also required and used for Davinci family of devices (arch/mach/mach-davinci/). That is really beside the point. If the code isn't ready yet, then don't merge it. When I asked about

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-18 Thread Richard Cochran
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote: It doesn't necessarily mean that the driver is usable in that kernel release. Well, it should. We have staging for half-baked stuff. Either way, the patch is likely to make it into the mainline kernel. It's just that it will

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-18 Thread Richard Cochran
On Thu, Oct 18, 2012 at 03:46:15AM +, Paul Walmsley wrote: Probably the driver was submitted before any SoC integration support was available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x didn't have device enumeration support in the mainline kernel until 3.7, via

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-17 Thread Richard Cochran
Paul, Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html Thanks, Richard - Forwarded message from Richard Cochran

Fwd: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX

2012-10-17 Thread Richard Cochran
Benoit, Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html Thanks, Richard - Forwarded message from Richard Cochran

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-17 Thread Richard Cochran
On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [121017 16:39]: Hi Richard On Wed, 17 Oct 2012, Richard Cochran wrote: Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-01 Thread Richard Cochran
On Fri, Apr 01, 2011 at 04:19:31PM -0400, Nicolas Pitre wrote: In a perfect world the bootloader would be bug free and always up to date with the best DT data. In practice I'm very skeptical this will always be the case and painless. At least the above makes it very simple to have a