Re: [PATCH v4 0/6] Touchscreen performance related fixes
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 capacitors on X+, X-, Y+, Y- reduces the noise and the false events disappear. IOW, the root cause is a design flaw in the BB-View 4.3 Cape? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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 with. This sounds like the ADC is still sampling while the input data becomes invalid. Usually there is a resistor on the wiper line and the touchscreen manual says how much it should be at least. Could you please check if this is properly installed? Wiper line? This is a four wire device. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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 *does* jump away, but not as often or as far as on the custom design I was working with. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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 trial and error is IMHO not the best way. That is not only an opinion, it is a matter of fact. TI really dropped the ball on this one. I thought the patch series was a sign they finally were going to properly address this issue. Wrong again. The data sheet for the TI part used to have a reference to an app-note for the touch controller. spruh73f page 1154 The Pen IRQ can only occur if the correct Pen Ctrl bits are high (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if the correct ground transistor biasing is set in the StepConfig [N] Register. Refer to the application notes for the correct settings. I searched high and low for this application note. Then, the data sheet got revised. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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 were able to solve the problem. Of course, having a 1.5ms delay in your ISR is a really bad thing to do... I fully support removing the aweful ISR delay, as long as the result works! I have another customer that was experiencing the same issue of registering multiple press events, and sure enough the 1.5ms delay fixed their problem too. The patches allowed them to remove that gigantic delay from the ISR because that software delay has now become a hardware delay via CHARGECONFIG. That customer is the one that needed 0xB000 which is MUCH larger than the value of 0x400 that was working fine for me on the EVM. It would be really nice for TI to explain to board designers how to calculate the proper value. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
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 more recent kernel supporting that cape. What is missing from mainline for the black? (I thought it was fully supported by now.) I did not see any breakage with these patches applied although I did not see any noticeable performance improvement as well. So, the jumping on pen-up persists, right? That means the patch series does not provide a general fix for that issue. I also tested this series on AM335x EVM using the v3.18-rc5 kernel. Again, no breakage but no improvement as well. You still have jumps on a pen up event? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
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 never near the
pen. Mostly it jitters around the right hand edge.
My customer had already changed the step delay (I think by trial and
error, not sure) in order to get the cursor near the pen. I ported
this change onto your series (see patch, below), but still the pen up
event causes a huge cursor jump.
(Again, I did solve the pen up issue, but in a totally different
way. I never posted the fix, because I could not be sure that it would
work on a wide variety of boards.)
Which ADC channels are being used for TSC?
tscadc {
status = okay;
tsc {
ti,wires = 4;
ti,x-plate-resistance = 300;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x23 0x32;
};
adc {
ti,adc-channels = 5 6 7;
};
};
So for this particular design, your series really does not help, not
even a little. You did not test the series on many boards. I am
concerned that this series only works on the one board you did test,
and that it may break functionality on other people's boards.
Thanks,
Richard
---
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b84493f..77a4883 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -148,7 +148,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + tsc_steps;
for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
config = 0;
@@ -172,7 +172,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + ts_dev-coordinate_readouts;
for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY |
STEPDELAY_SAMPLE(20));
}
/* Make CHARGECONFIG same as IDLECONFIG */
@@ -188,13 +188,13 @@ static void titsc_step_config(struct titsc *ts_dev)
STEPCONFIG_INP(ts_dev-inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
end_step++;
config |= STEPCONFIG_INP(ts_dev-inp_yn);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
/* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
stepenable = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
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 eliminating udelay and touchscreen lag. This also improves performance of touchscreen and eliminates sudden jump of cursor at touch release. I back ported this series onto v3.15.1 in order to try this out on a custom, beaglebone-like board. With this series, the touch is really broken. (I had fixed the pen up problem in a totally different way for a customer, and so I wanted to try out your solution.) I will try to port the board code to a more recent kernel to try your series again. With which kernel version did you test your patches? And which board? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
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 removing filtering logic, the performance was not at all satisfactory. The cursor jumps wayward and smooth circles cannot be drawn. Looks like delta filtering cannot be removed as of now. May be I will try and address it in future. The filter code is nonsensical. It picks the two values in seqeunce that are closest to one and another. How is that supposed to work? Did you look at the noise? What kind of properties did you see? A median filter makes more sense. Or sort, remove outliers, and average. But choosing the two closest in series is silly. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
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 cannot be drawn. Looks like delta filtering cannot be removed as of now. May be I will try and address it in future. FWIW, on the boards that I tested, I printed the measured values out, and I found that with 5 repetitions, I got the same value 5 times, plus or minus a very small delta. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
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 = TOTAL_STEPS - (creads * 2 + 2);
*z1 = *z2 = 0;
if (fifocount % (creads * 2 + 2))
@@ -226,7 +232,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
channel = (read 0xf) 16;
read = 0xfff;
- if (channel creads) {
+ if (channel first_step + creads + 2) {
diff = abs(read - prev_val_x);
if (diff prev_diff_x) {
prev_diff_x = diff;
@@ -234,19 +240,19 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
}
prev_val_x = read;
- } else if (channel creads * 2) {
+ } else if (channel == first_step + creads + 1) {
+ *z1 = read;
+
+ } else if (channel == first_step + creads + 2) {
+ *z2 = read;
+
+ } else if (channel first_step) {
diff = abs(read - prev_val_y);
if (diff prev_diff_y) {
prev_diff_y = diff;
*y = read;
While you are at it, please get rid of the this delta filter
nonsense.
Thanks,
Richard
}
prev_val_y = read;
-
- } else if (channel creads * 2 + 1) {
- *z1 = read;
-
- } else if (channel creads * 2 + 2) {
- *z2 = read;
}
}
}
--
1.9.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/4] Touchscreen performance related fixes
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 Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Thanks, Richard -- 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 0/6] Add CPTS support for AM437x
On Fri, May 02, 2014 at 12:01:58PM +0530, George Cherian wrote: The series adds CPTS support for AM4372. Patch 1 - DT changes w.r.t clock changes for AM33xx. Patch 2 - CPTS clock name harcoding in the driver is removed. Easier to pass the clock name from dt rather than hardcoding in driver. Also in prepration for DRA7x CPTS support. Patch 3 - Enable the CPTS support for both DRA7x and AM4372 in the driver. Patch 4 - Enable the Annexe F for L2 PTP for AM437x and DRA7x. Patch 5 - Change the default clocksource to dpll_core_m5 Patch 6 - DT changes for AM4372. 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 at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] drivers: net: cpts: Remove hardcoded clock name for CPTS
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 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 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk
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 errors while running PTP. clockcheck: clock jumped backward or running slower than expected! It is strange that I have never seen this error, since I have often tested linuxptp on a beagle bone white. Can you please explain why this clock doesn't work correctly? By selecting dpll_core_m5_ck as the clocksource fixes this issue. In AM335x dpll_core_m5_ck is the default clocksource. The choice of clock source in the CPTS driver originally came from TI. It would be nice to know why that was the wrong choice. Thanks, Richard -- 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 4/6] drivers: net: cpsw: Enable Annexe F Time sync
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 rename TS_BIT8 to TS_TTL_NONZERO Is this bit finally documented for am335x? Thanks, Richard -- 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 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk
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 changing the default clock for am335x? If yes, it shouldn't. If no, then the patch description should say so. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes
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 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 CPSW which has the same register offsets will work directly without patching the driver. This doesn't make any sense to me. Why not just add the new version number? None of the hunks in your patch are on performance sensitive paths, so I really can't see any point in removing the error checking. Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 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 CPSW which has the same register offsets will work directly without patching the driver. This doesn't make any sense to me. Why not just add the new version number? None of the hunks in your patch are on performance sensitive paths, so I really can't see any point in removing the error checking. well, if a new revision of the IP comes, the driver at least has some chance to work without having to be modified. If it turns out that there are really different features, then we patch a new version, otherwise we should just assume highest known version and try it out. And if the driver reads junk from some random address due to bootloader/DT/multikernel madness, it will happily peek and poke around instead of rejecting the wrong version number. Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 +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 CPSW which has the same register offsets will work directly without patching the driver. This doesn't make any sense to me. Why not just add the new version number? None of the hunks in your patch are on performance sensitive paths, so I really can't see any point in removing the error checking. well, if a new revision of the IP comes, the driver at least has some chance to work without having to be modified. If it turns out that there are really different features, then we patch a new version, otherwise we should just assume highest known version and try it out. And if the driver reads junk from some random address due to bootloader/DT/multikernel madness, it will happily peek and poke around instead of rejecting the wrong version number. that'd be a bug in the DT anyway, why should the driver have to cope with broken data ? Um, it is called error checking? Besides, by not checking the version number, you are pre-programming a disaster that will occur when an older kernel is booted on the first new IP version with important changes. Can you really be sure that all users will have the new, patched kernel? Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 differences. Comparing CPSW V1 with V2, it appears that TI likes to move the registers around between versions. To me, this is reason enough to make the driver defensive. Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 next version of CPSW to be SW compatible. If it isn't, then TI will send patches to add a new revision check and treat it well. We are the first ones to have access to new versions of all our IPs anyway. Okay, so starting with V3 the registers probably won't be moving around any more. But at the very least your patch should include macros for the known V3 along with the default case. Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 description says The new IP version has a minor changes and the offsets are same as the previous version, but you are saying there is no new version? Thanks, Richard -- 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: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version
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 checking the kernel version, then that is another kettle of fish. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
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 should start off by making a list of actual products and their capabilities, in order to get an overall idea of what we would need to develop. Thanks, Richard -- 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] cpsw: Fix interrupt storm among other things
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 patch. It should be addressed to netdev, it it
needs to have davem on CC.
2. The description is poor. You need to tell us more about this
storm. How can one trigger it? What is the effect? Does the
system lock up, or is the throughput poor? Tell us exactly what the
problem is. Tell us what is wrong in the interrupt handling, and
how the patch improves the situation.
3. Don't just say general fixes, but do say exactly what you fixed.
4. Adding non-NAPI code is going backwards. Don't do that (and see the
recent discussion on netdev on just this very topic: Frank Li and
the fec driver).
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 40aff68..b6ca4af 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -148,10 +148,37 @@ struct cpsw_wr_regs {
u32 soft_reset;
u32 control;
u32 int_control;
- u32 rx_thresh_en;
- u32 rx_en;
- u32 tx_en;
- u32 misc_en;
+ u32 c0_rx_thresh_en;
+ u32 c0_rx_en;
+ u32 c0_tx_en;
+ u32 c0_misc_en;
How does renaming these help?
(If you really think that new names are needed, then put the cosmetic
renaming changes into its a separate patch.)
+ u32 c1_rx_thresh_en;
+ u32 c1_rx_en;
+ u32 c1_tx_en;
+ u32 c1_misc_en;
You added a bunch of new fields, but you don't use any of them.
Thanks,
Richard
--
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] cpsw: Fix interrupt storm among other things
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 netdev, please also put net or net-next into the subject line. Thanks, Richard -- 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] cpsw: Fix interrupt storm among other things
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 when trying to debug hardware problems; the non-NAPI driver is much easier to understand and follow, especially when there is a convoluted method you have to follow to have the h/w acknowledge the interrupt. Special debug modes are fine to have, but not in mainline code. I suggest taking a look at the recent netdev discussion on this. Someone wanted to make napi/non-napi a DT option, and it got nixed. Not every device can be conveniently be made to shut up so that NAPI processing can take place at a later time. So, are you saying that the cpsw cannot work as a napi device? The NAPI case is still broken in this driver, which OOPs under load. And does your patch fix it, or not? It would be nice to know what the problem is, and how to reproduce it. I haven't seen any OOPs on the beaglebone, but maybe I am not trying hard enough. Thanks, Richard -- 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] cpsw: Fix interrupt storm among other things
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 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/2] drivers: net:ethernet: cpsw: add support for VLAN
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= cpsw_ndo_vlan_rx_add_vid,
+ .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
+#endif
These are not compile time conditionals in net_device_ops, so I wonder
(after reading Felipe's comments) whether you can simply keep the VLAN
code always present.
As long as the driver still compiles and loads, when VLAN is missing
from the stack, then I don't see why you can't just leave it in,
without all the ifdefs.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
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 unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
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-rc4 tag
Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Do you use appended dtb? The only different that jumped out at me first
Paul's reported hang is he uses appended dtb and I boot my boards with a
single uImage and multiple dtbs the traditional DT way.
No, not appended. I have a u-boot that supports dtb:
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
and using the omap2plus_defconfig, with a minicom script like the one
below, and it works just fine.
HTH,
Richard
verbose on
send setenv ipaddr 192.168.1.77
send setenv serverip 192.168.1.12
send setenv netmask 255.255.255.0
send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw
initrd=0x8200,16MB ramdisk_size=16384 earlyprintk=serial
send tftp 8100 uImage
expect {
U-Boot#
}
send tftp 8200 beaglebone-initrd.gz
expect {
U-Boot#
}
send tftp 8000 am335x-bone.dtb
expect {
U-Boot#
}
send bootm 8100 - 8000
--
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/6] Introducing Device Tree Overlays
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 Documentation/devicetree/overlay-notes.txt as well? Thanks, Richard -- 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/6] Introducing Device Tree Overlays
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 addressed? Thanks, Richard -- 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/2] cpts: fix a run time warn_on.
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 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c index 5ab8fb4..3e32a31 100644 --- a/drivers/net/ethernet/ti/cpts.c +++ b/drivers/net/ethernet/ti/cpts.c @@ -247,6 +247,7 @@ static void cpts_clk_init(struct cpts *cpts) cpts-refclk = NULL; return; } +clk_prepare(cpts-refclk); clk_enable(cpts-refclk); Maybe just call clk_prepare_enable() instead? Okay, will fix in v2. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] cpts fixes for v3.8-rc2
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/ethernet/ti/cpts.c |3 +-- drivers/net/ethernet/ti/cpts.h |1 - 2 files changed, 1 insertions(+), 3 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] cpts: fix build error by removing useless code.
The cpts driver tries to obtain the input clock frequency by calling the
clock's internal 'recalc' method. Since plat/clock.h has been removed,
this code can no longer compile.
However, the driver never makes use of the frequency value, so this patch
fixes the issue by removing the offending code 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..5ab8fb4 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -248,7 +248,6 @@ static void cpts_clk_init(struct cpts *cpts)
return;
}
clk_enable(cpts-refclk);
- cpts-freq = cpts-refclk-recalc(cpts-refclk);
}
static void cpts_clk_release(struct cpts *cpts)
diff --git a/drivers/net/ethernet/ti/cpts.h b/drivers/net/ethernet/ti/cpts.h
index e1bba3a..fe993cd 100644
--- a/drivers/net/ethernet/ti/cpts.h
+++ b/drivers/net/ethernet/ti/cpts.h
@@ -120,7 +120,6 @@ struct cpts {
struct delayed_work overflow_work;
int phc_index;
struct clk *refclk;
- unsigned long freq;
struct list_head events;
struct list_head pool;
struct cpts_event pool_data[CPTS_MAX_EVENTS];
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] cpts fixes for v3.8-rc2
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 files changed, 1 insertions(+), 2 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpts: Fix build error caused by include of plat/clock.h
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 hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html That patch didn't get applied, so it's still broken in Linus' tree :( In netdev's patchwork, this was marked Not Applicable. Dave, can you possibly take this patch? If not, who should I ask next? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
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]: *** [drivers/net/ethernet/ti/cpts.o] Error 1 make[3]: *** [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 linux-next still has this build problem, I guess this patch is lingering somewhere. Somewhat annoying, as the driver is enabled by default. (btw, why is it default y?) Um, in Linus' master, net, and net-next, neither TI_CPSW nor TI_CPTS are default y, so I don't know where you are coming from on that. Sorry, Richard -- 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: cpts: Fix build error caused by include of plat/clock.h
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? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
On Tue, Nov 27, 2012 at 03:57:14PM +0530, 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]: *** [drivers/net/ethernet/ti/cpts.o] Error 1 make[3]: *** [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 the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected
On Tue, Nov 27, 2012 at 11:23:40PM +0530, Mugunthan V N wrote: CC drivers/net/ethernet/ti/cpsw.o drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl': drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv' The build warning is generated when CPTS 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 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc5
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 be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test I have the same result with omap2plus_defconfig and kernel 3.7.0-rc5. I dumped the kernel log buffer via JTAG and can send this log if it could be useful. I just got my BeagleBone replaced via RMA, and so I could try a fresh build of 3.7.0-rc5 with omap2plus_defconfig. It works just fine for me. A few details: U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) setenv ipaddr 192.168.0.77 setenv serverip 192.168.0.12 setenv netmask 255.255.255.0 setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=16384 earlyprintk=serial tftp 8100 uImage tftp 8200 beaglebone-initrd.gz tftp 8000 am335x-bone.dtb bootm 8100 - 8000 So I guess just using a recent u-boot will fix whatever issues you are seeing. Thanks, Richard -- 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] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
On Tue, Nov 06, 2012 at 01:42:18PM +0530, Mugunthan V N wrote: This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. [4/7]: cpsw: simplify the setup of the register pointers [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: cpsw: Kernel warn fix during suspend 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 at http://vger.kernel.org/majordomo-info.html
[PATCH RFC net-next 0/1] Simplify the CPSW DT
This patch is a follow up to show how to remove all the various register offsets from the DT for the CPSW driver. This applies on top of the bug fix I posted earlier for IO mapping leak. Since I am currently awaiting a replacement for my defective BeagleBone, this patch is compile tested only. 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 changed, 82 insertions(+), 180 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
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 at different offsets. For example comparing the CPSW ip in TI814X and AM335X all the above offsets are changed. So I have kept all these offsets in DT as driver should not hold any SoC related informations Did you see the two messages on this point from yesterday? Thanks, Richard -- 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 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
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 version is same in both IP versions. So keeping these offset in DT will make the same driver works directly with DT changes for future SoC. But the CPSW versions are different, and the offsets could be determined that way, couldn't they? The TRM for the DM814x does not even make the distinction among CPSW_SS, CPSW_PORT, CPSW_CPDMA, and so on. Instead, it places all of the registers into one space called CPSW_3G. So I agree with Benoit. Placing all of the offsets into DT seems like over-engineering to me, unless you know of TI's plans to release a new SoC with the same CPSW version but different register offsets. Thanks, Richard -- 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 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
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; + cpdma_sram_ofs = 0xa00; + ale_reg_ofs = 0xd00; + ale_entries = 1024; + host_port_reg_ofs = 0x108; + hw_stats_reg_ofs = 0x900; + bd_ram_ofs = 0x2000; + bd_ram_size = 0x2000; + no_bd_ram = 0; + rx_descs = 64; + mac_control = 0x20; Do you have to store all these data in the DTS? Cannot it be in the driver? Do you expect to have several instance of the same IP with different parameters here? As I understand it, there are only two different layouts for the CPSW, the one in the dm814x and the one in the am335x. So I think it would work to put only the version register offet in the DT, and the let the driver figure out the rest from there. But if TI is planning on reordering the registers with each new silicon revision, again and again, then it might make sense to keep the offsets in the DT. [ I really wonder why the hardware people think that reshuffling the register layout constitutes an improvement. ] Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 releases to be working and complete, without the kind of half baked stumps that the embedded vendors are pushing. In my experience with Freescale (and now TI also), the vendor supports Linux on their platform by providing a heavily patched, quick and dirty, customized kernel that is kinda, sorta working, somehow. This provides a way for their customers to get started with the development kits right away, and as such I have no problem with it. What I do have a problem with is the fact the vendors then drop the ball and don't follow through by getting their changes into mainline. This makes a huge problem for the vendor's customers later on, when the choice becomes either stay with the dead end vendor kernel, or try to get mainline working all by themselves. And so I am pleased to hear that the Ethernet ports on the am335x will be working in v3.8. Better late than never. Thanks, Richard -- 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 0/4] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
On Mon, Oct 29, 2012 at 01:51:17PM +0530, Vaibhav Hiremath wrote: This patch-series adds support for, [1/4]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/4]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/4]: Add hwmod entry for MDIO module, required for MDIO 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 to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 whether we have working Ethernet on the beaglebone in v3.7? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. Paul, You are using an obsolete u-boot and the legacy appended dtb method. It was my understanding that that way is just a temporary hack in case the boot loader does not support dtb. Now that u-boot has the proper support, using the dtb method is the offical boot method, AFAICT. At least, that is what people are saying on the arm list. So I think that if you want to test whether a particular board is booting correctly, it is more useful to try the offical method. 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 is doing anything about it either. When I read your report, it gave me a much rosier picture than is actually the case WRT the beaglebone. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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 that said, Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone It sounded to me like you were saying that the current kernel release boots just fine on the beaglebone, with no issues. It surprised me, because in fact I have had one heck of a time getting the beaglebone to boot. It is a bit of a cop-out to say that you are not interested in the boot loader. Way back when the whole dt is so cool, arm should use it too argument appeared, I wrote that, in my experience with Freescale powerpc chips, the whole kernel/dt/u-boot is a kind of Bermuda Triangle of misfortune. Looks like that dt is turning out to be just as successful for arm as it was for powerpc. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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 is doing anything about it either. A fix to resolve the gpmc issue has been merged recently, so I am expecting beagle bone to boot on -rc2 (I don't have hardware to test, on vacation now), can you please try with -rc2. I am happy to report that v3.7-rc2 boots via the modern DT method, using Paul's am33xx_only config and U-Boot 2012.10-rc1-00148-g4668a08. Thanks, and have a nice vacation, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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 reorganized and updated. AM335x Beaglebone and OMAP4460 Pandaboard-ES boards have been added to the testbed. Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) 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). Below I include the console log. Thanks, Richard U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 3 0 U-Boot# tftp 8100 uImage link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'uImage'. Load address: 0x8100 Loading: # # # # # # # # # # # done Bytes transferred = 3822248 (3a52a8 hex) U-Boot#tftp 8200 beaglebone-initrd.gz link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'beaglebone-initrd.gz'. Load address: 0x8200 Loading: # # # # # # # done Bytes transferred = 2059309 (1f6c2d hex) U-Boot#tftp 8000 am335x-bone.dtb link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.0.12; our IP address is 192.168.0.77 Filename 'am335x-bone.dtb'. Load address: 0x8000 Loading: # done Bytes transferred = 4391 (1127 hex) U-Boot#bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3822184 Bytes = 3.6 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe66000, end 8fe6a126 ... OK Starting kernel ... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html ? Yes, that is right. Only the first patch is absoutely required for booting. Thanks for the report. Are you using the stock v3.7-rc1 DTS file in arch/arm/boot/dts/am335x-bone.dts ? Yes. Also are you using omap2plus_defconfig? Yes, but I de-selected a few items. I will try it again without changing anything. 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: http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/ Okay, so there are a number of differences between your am33xx_only and the omap2plus_defconfig. I will try it with your config as well. In terms of differences from your setup, looks like we have different X-Loader and u-boot; it wouldn't surprise me if we have different kernel configs too. What is X-Loader? Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
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 and u-boot; it wouldn't surprise me if we have different kernel configs too. I tried both omap2plus_defconfig and your am33xx_only config, and neither one work with my (recent) u-boot version. Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 tree at you, Paul. This is directed toward the omap people: Please, PLEASE, make sure that the mainline code is working. It is easy to verify. Just compile the code and boot it. Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 the beaglebone, I was given the impression that it will be ready for v3.7-rc1. But, as I know realize, at the current rate, it might not even be ready for v3.8. I don't mind waiting, but please make sure that whatever lands into a release is really, truly working. Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 probably take a few weeks longer than you might like. I don't mind waiting for a driver that is held off because of missing background support. I *do* mind if y'all go merging all kinds of code that has never been tested. Those who submit and their reviewers should ensure that the code is actually working. Before buying hardware or starting projects, I often check what is in mainline. I expect that mainline has been at least minimally tested. Maybe that is just me, or maybe people working on the ARM tree have different expectations. Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 (ARM: OMAP3+: hwmod: Add AM33XX HWMOD data). So I don't see how it could have worked with mainline. ... But it seems that the CPSW has never worked in the mainline kernel. So this particular patch is not fixing a regression. Therefore we shouldn't send it upstream during the -rc time period. Instead we'll schedule it to be sent a few weeks later, during the 3.8 merge window. Let's think about this some more: The driver's commit is from March and is included in v3.4-rc1. You say it will be working in 3.8, after 3.7 comes out, in about December. So how long does it take between merging code and actually getting it working? Sorry to harp on this so much, but I try out my patches with the tip of the appropriate tree before sending them, or when I cannot, at least I put into the log compile tested only or something like that. Thanks, Richard -- 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
Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 richardcoch...@gmail.com -
Date: Mon, 15 Oct 2012 21:16:32 +0200
From: Richard Cochran richardcoch...@gmail.com
To: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de,
David Miller da...@davemloft.net,
Russell King li...@arm.linux.org.uk,
Mugunthan V N mugunthan...@ti.com
Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
X-Mailer: git-send-email 1.7.2.5
From: Mugunthan V N mugunthan...@ti.com
This patch adds minimal hwmod support for davinci mdio driver. This patch
requires rework on parent child relation between cpsw and davinci mdio
hwmod data to support runtime PM.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 34 ++-
1 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..f96bbc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc
= {
.rev_offs = 0x0,
.sysc_offs = 0x8,
.syss_offs = 0x4,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
- SYSS_HAS_RESET_STATUS),
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
MSTANDBY_NO),
.sysc_fields= omap_hwmod_sysc_type3,
@@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
};
/*
@@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space
am33xx_elm_addr_space[] = {
{ }
};
+/* mdio class */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
+ },
+ { }
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = am33xx_mdio_hwmod_class,
+ .clkdm_name = cpsw_125mhz_clkdm,
+ .main_clk = cpsw_125mhz_gclk,
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
.master = am33xx_l4_ls_hwmod,
.slave = am33xx_elm_hwmod,
@@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l3_main__tptc2,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
+ am33xx_cpgmac0__mdio,
NULL,
};
--
1.7.2.5
- End forwarded message -
--
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
Fwd: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
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 richardcoch...@gmail.com -
Date: Mon, 15 Oct 2012 21:16:35 +0200
From: Richard Cochran richardcoch...@gmail.com
To: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de,
David Miller da...@davemloft.net,
Russell King li...@arm.linux.org.uk,
Mugunthan V N mugunthan...@ti.com,
Vaibhav Hiremath hvaib...@ti.com
Subject: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
X-Mailer: git-send-email 1.7.2.5
From: Mugunthan V N mugunthan...@ti.com
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 ++
arch/arm/boot/dts/am335x-evm.dts |8 ++
arch/arm/boot/dts/am33xx.dtsi | 50 +
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..f6bea04 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,55 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ host_port_no = 0;
+ cpdma_reg_ofs = 0x800;
+ cpdma_sram_ofs = 0xa00;
+ ale_reg_ofs = 0xd00;
+ ale_entries = 1024;
+ host_port_reg_ofs = 0x108;
+ hw_stats_reg_ofs = 0x900;
+ bd_ram_ofs = 0x2000;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
+ interrupts = 40 41 42 43;
+ ranges;
+ cpsw_emac0: slave@0 {
+ slave_reg_ofs = 0x208;
+ sliver_reg_ofs = 0xd80;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave@1 {
+ slave_reg_ofs = 0x308;
+ sliver_reg_ofs = 0xdc0;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x4a101000 0x100;
+ };
+
+ };
};
};
--
1.7.2.5
- End forwarded message -
--
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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
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 it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html This patch appears to add a new feature, correct? I don't think the CPSW could have worked in the past without this data present. So it looks to me like this is 3.8 material, unless Tony would like it to go in sooner? Yeah unless it fixes something, we should just queue it for v3.8 merge window. So there has been this cpsw driver since v3.4-rc1~177^2~5 df82859 netdev: driver: ethernet: Add TI CPSW driver and four people signed off on it, so it must have been working at one point. Since the device tree make-over, the driver is a derelict, and thus the present patch is fixing a regression. I just want the already merged driver to work with the vanilla kernel. Is that too much to ask? Thanks, Richard -- 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: [GIT PULL] omap changes for v2.6.39 merge window
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 self contained kernel when (not if) need be. Yes, my experience with DT on powerpc teaches me that, although DT sounds wonderful in theory, in practice kernel/dtb/uboot form a love triangle (or perhaps a hate triangle) where all three points must be exactly up to date with each other. If one part is even just a month or two too old/new, then your kernel might not boot. Richard -- 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
