RE: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
Hi Mike,
On Sat, Jan 26, 2013 at 04:14:53, Mike Turquette wrote:
I think Paul W. or someone on the TI side should weigh in on your clkdev
entries. My main point is that the actual tree should be modeled and
clocks shouldn't be globbed together unnecessarily. As mentioned in the
other mail thread you might be better off making a divider for your LCDC
IP block and modeling each node individually.
It seems complexity of driver would increase by creating a new inherited
divider clock and having a total 3-4 clock nodes. The advantage going
with it would be higher configurable resolution for pixel clock.
Current use cases work without higher pixel clock resolution.
And drm driver posted for the same IP is without CCF modeling.
So I will presently not model clock nodes in LCDC IP, later if use cases
badly require, this can be done (and if it happens, hopefully by that
DaVinci would be CCF'ed and it would be more clean to implement it).
Thanks for sharing your ideas.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Hi Mike, On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote: Thank you for the information. In short, the way you program your clock depend on the configuration of your lcdc device. As such I am not sure the basic divider is the right choice for you. You might be better off creating a clock for your IP which takes into account these details. Luckily it is possible to inherit from the basic clock types and create a new type. An example of this is the MXS divider. It uses the basic divider as a parent class and adds a busy bit. This is a better approach than putting every feature into the basic divider type. You can see how it was done in drivers/clk/mxs/clk-div.c Let me know what you think. Yes, a derived divider is better. As mentioned in other thread, the modeling of clock nodes (derived plus gates) would bring in considerable (relative to complete driver) code, the advantage being higher pixel clock resolution. Current use cases work as per existing divider setting in driver. Hence now it seems a better decision now is to proceed with logic as in v2 (not using clock nodes). And later depending on the use case requirement, clock tree modeling can be implemented. Thanks for your input. Regards Afzal
[PATCH v5 00/12] video: da8xx-fb: am335x DT support
Hi, This series adds DT support to da8xx-fb driver (device found on DaVinci and AM335x SoC's). It does certain cleanup's in the process. This series as compared to previous version goes back to v2 way of configuring pixel clock rate. i.e. set divider if rate is within the range that is configurable with existing input clock rate, else change input clock rate as required instead of modeling CCF clock nodes in the driver (more details in 12/12) This makes use of Steffen Trumtrar's v17 of display timing DT support. Testing has been done on AM335x SoC based boards like AM335x EVM. It has also been verified that display on DA850 EVM (non-DT boot) works as earlier. This series is based on v3.8-rc3, and is dependent on, 1. Series v17 of: add display helper by, Steffen Trumtrar s.trumt...@pengutronix.de 2. Patch da8xx: Allow use by am33xx based devices by, Pantelis Antoniou pa...@antoniou-consulting.com 3. Series v3 video: da8xx-fb: runtime timing configuration by, me (Afzal Mohammed af...@ti.com) To test this series on AM335x based boards, 1. Series HWMOD fixes for AM33xx PWM submodules and device tree nodes by, Philip, Avinash avinashphi...@ti.com as well as following, 2. Series v2 ARM: dts: AM33XX: lcdc support, 3. Patch v2 ARM: OMAP2+: dpll: am335x - avoid freqsel, 4. Patch v2 ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper, 5. Patch v2 ARM: AM33XX: clock: SET_RATE_PARENT in lcd path by, me (Afzal Mohammed af...@ti.com) would be needed. All above dependencies along with those required for testing is available @ git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v5 Regards Afzal v5: use v2 method of configuring pixel clock rate instead of modeling CCF clock nodes in driver, i.e. set divider if rate is within the range that is configurable with existing input clock rate, else change input clock rate as required. v4: use new registration for clock divider having minimum divider requirement and have ifdef'ery in a better way v3: model CCF clock divider with parent propogation if CCF selected v2: 2 new patches - one to configure clock rate properly (12/12)and other to make io operations safe (1/12) Afzal Mohammed (11): video: da8xx-fb: make io operations safe video: da8xx-fb: enable sync lost intr for v2 ip video: da8xx-fb: use devres video: da8xx-fb: ensure non-null cfg in pdata video: da8xx-fb: reorganize panel detection video: da8xx-fb: minimal dt support video: da8xx-fb: invoke platform callback safely video: da8xx-fb: obtain fb_videomode info from dt video: da8xx-fb: ensure pdata only for non-dt video: da8xx-fb: setup struct lcd_ctrl_config for dt video: da8xx-fb: set upstream clock rate (if reqd) Manjunathappa, Prakash (1): video: da8xx-fb: fix 24bpp raster configuration .../devicetree/bindings/video/fb-da8xx.txt | 37 drivers/video/da8xx-fb.c | 226 ++--- 2 files changed, 194 insertions(+), 69 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/12] video: da8xx-fb: enable sync lost intr for v2 ip
interrupt handler is checking for sync lost interrupt, but it was not enabled, enable it. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/video/da8xx-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 7f92f37..ca69e01 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -318,7 +318,7 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par *par) reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) | LCD_V2_END_OF_FRAME0_INT_ENA | LCD_V2_END_OF_FRAME1_INT_ENA | - LCD_FRAME_DONE; + LCD_FRAME_DONE | LCD_SYNC_LOST; lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG); } reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE; -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/12] video: da8xx-fb: use devres
Replace existing resource handling in the driver with managed device
resource.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index ca69e01..7a32e83 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1036,12 +1036,9 @@ static int fb_remove(struct platform_device *dev)
par-p_palette_base);
dma_free_coherent(NULL, par-vram_size, par-vram_virt,
par-vram_phys);
- free_irq(par-irq, par);
pm_runtime_put_sync(dev-dev);
pm_runtime_disable(dev-dev);
framebuffer_release(info);
- iounmap(da8xx_fb_reg_base);
- release_mem_region(lcdc_regs-start, resource_size(lcdc_regs));
}
return 0;
@@ -1265,7 +1262,6 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- resource_size_t len;
int ret, i;
unsigned long ulcm;
@@ -1275,29 +1271,16 @@ static int fb_probe(struct platform_device *device)
}
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
- if (!lcdc_regs) {
- dev_err(device-dev,
- Can not get memory resource for LCD controller\n);
- return -ENOENT;
- }
-
- len = resource_size(lcdc_regs);
-
- lcdc_regs = request_mem_region(lcdc_regs-start, len, lcdc_regs-name);
- if (!lcdc_regs)
- return -EBUSY;
-
- da8xx_fb_reg_base = ioremap(lcdc_regs-start, len);
+ da8xx_fb_reg_base = devm_request_and_ioremap(device-dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
- ret = -EBUSY;
- goto err_request_mem;
+ dev_err(device-dev, memory resource setup failed\n);
+ return -EADDRNOTAVAIL;
}
- fb_clk = clk_get(device-dev, fck);
+ fb_clk = devm_clk_get(device-dev, fck);
if (IS_ERR(fb_clk)) {
dev_err(device-dev, Can not get device clock\n);
- ret = -ENODEV;
- goto err_ioremap;
+ return -ENODEV;
}
pm_runtime_enable(device-dev);
@@ -1458,7 +1441,7 @@ static int fb_probe(struct platform_device *device)
lcdc_irq_handler = lcdc_irq_handler_rev02;
}
- ret = request_irq(par-irq, lcdc_irq_handler, 0,
+ ret = devm_request_irq(device-dev, par-irq, lcdc_irq_handler, 0,
DRIVER_NAME, par);
if (ret)
goto irq_freq;
@@ -1488,12 +1471,6 @@ err_pm_runtime_disable:
pm_runtime_put_sync(device-dev);
pm_runtime_disable(device-dev);
-err_ioremap:
- iounmap(da8xx_fb_reg_base);
-
-err_request_mem:
- release_mem_region(lcdc_regs-start, len);
-
return ret;
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/12] video: da8xx-fb: ensure non-null cfg in pdata
Ensure that platform data contains pointer for lcd_ctrl_config.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7a32e83..3b146bc 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1320,6 +1320,11 @@ static int fb_probe(struct platform_device *device)
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
+ if (!lcd_cfg) {
+ ret = -EINVAL;
+ goto err_pm_runtime_disable;
+ }
+
da8xx_fb_info = framebuffer_alloc(sizeof(struct da8xx_fb_par),
device-dev);
if (!da8xx_fb_info) {
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/12] video: da8xx-fb: obtain fb_videomode info from dt
Obtain fb_videomode details for the connected lcd panel using the
display timing details present in DT.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../devicetree/bindings/video/fb-da8xx.txt | 21 +
drivers/video/da8xx-fb.c| 17 +
2 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
index 581e014..0741f78 100644
--- a/Documentation/devicetree/bindings/video/fb-da8xx.txt
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -6,6 +6,12 @@ Required properties:
AM335x SoC's - ti,am3352-lcdc, ti,da830-lcdc
- reg: Address range of lcdc register set
- interrupts: lcdc interrupt
+- display-timings: typical videomode of lcd panel, represented as child.
+ Refer Documentation/devicetree/bindings/video/display-timing.txt for
+ display timing binding details. If multiple videomodes are mentioned
+ in display timings node, typical videomode has to be mentioned as the
+ native mode or it has to be first child (driver cares only for native
+ videomode).
Example:
@@ -13,4 +19,19 @@ lcdc@4830e000 {
compatible = ti,am3352-lcdc, ti,da830-lcdc;
reg = 0x4830e000 0x1000;
interrupts = 36;
+ display-timings {
+ 800x480p62 {
+ clock-frequency = 3000;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 39;
+ hback-porch = 39;
+ hsync-len = 47;
+ vback-porch = 29;
+ vfront-porch = 13;
+ vsync-len = 2;
+ hsync-active = 1;
+ vsync-active = 1;
+ };
+ };
};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0beed20..0c68712 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,6 +36,7 @@
#include linux/slab.h
#include linux/delay.h
#include linux/lcm.h
+#include video/of_display_timing.h
#include video/da8xx-fb.h
#include asm/div64.h
@@ -1257,8 +1258,24 @@ static struct fb_videomode
*da8xx_fb_get_videomode(struct platform_device *dev)
{
struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
struct fb_videomode *lcdc_info;
+ struct device_node *np = dev-dev.of_node;
int i;
+ if (np) {
+ lcdc_info = devm_kzalloc(dev-dev,
+sizeof(struct fb_videomode),
+GFP_KERNEL);
+ if (!lcdc_info) {
+ dev_err(dev-dev, memory allocation failed\n);
+ return NULL;
+ }
+ if (of_get_fb_videomode(np, lcdc_info, OF_USE_NATIVE_MODE)) {
+ dev_err(dev-dev, timings not available in DT\n);
+ return NULL;
+ }
+ return lcdc_info;
+ }
+
for (i = 0, lcdc_info = known_lcd_panels;
i ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 10/12] video: da8xx-fb: ensure pdata only for non-dt
This driver is DT probe-able, hence ensure presence of platform data
only for non-DT boot.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0c68712..1c1a616 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1303,7 +1303,7 @@ static int fb_probe(struct platform_device *device)
int ret;
unsigned long ulcm;
- if (fb_pdata == NULL) {
+ if (fb_pdata == NULL !device-dev.of_node) {
dev_err(device-dev, Can not get platform data\n);
return -ENOENT;
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/12] video: da8xx-fb: reorganize panel detection
Move panel detection to a separate function, this helps in readability
as well as makes DT support cleaner.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 3b146bc..b6ea5e9 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1253,6 +1253,27 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
+{
+ struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
+ struct fb_videomode *lcdc_info;
+ int i;
+
+ for (i = 0, lcdc_info = known_lcd_panels;
+ i ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
+ if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
+ break;
+ }
+
+ if (i == ARRAY_SIZE(known_lcd_panels)) {
+ dev_err(dev-dev, no panel found\n);
+ return NULL;
+ }
+ dev_info(dev-dev, found %s panel\n, lcdc_info-name);
+
+ return lcdc_info;
+}
+
static int fb_probe(struct platform_device *device)
{
struct da8xx_lcdc_platform_data *fb_pdata =
@@ -1262,7 +1283,7 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- int ret, i;
+ int ret;
unsigned long ulcm;
if (fb_pdata == NULL) {
@@ -1270,6 +1291,10 @@ static int fb_probe(struct platform_device *device)
return -ENOENT;
}
+ lcdc_info = da8xx_fb_get_videomode(device);
+ if (lcdc_info == NULL)
+ return -ENODEV;
+
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
da8xx_fb_reg_base = devm_request_and_ioremap(device-dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
@@ -1303,21 +1328,6 @@ static int fb_probe(struct platform_device *device)
break;
}
- for (i = 0, lcdc_info = known_lcd_panels;
- i ARRAY_SIZE(known_lcd_panels);
- i++, lcdc_info++) {
- if (strcmp(fb_pdata-type, lcdc_info-name) == 0)
- break;
- }
-
- if (i == ARRAY_SIZE(known_lcd_panels)) {
- dev_err(device-dev, GLCD: No valid panel found\n);
- ret = -ENODEV;
- goto err_pm_runtime_disable;
- } else
- dev_info(device-dev, GLCD: Found %s panel\n,
- fb_pdata-type);
-
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
if (!lcd_cfg) {
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/12] video: da8xx-fb: minimal dt support
Driver is provided a means to have the probe triggered by DT.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/video/fb-da8xx.txt | 16
drivers/video/da8xx-fb.c | 7 +++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
new file mode 100644
index 000..581e014
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -0,0 +1,16 @@
+TI LCD Controller on DA830/DA850/AM335x SoC's
+
+Required properties:
+- compatible:
+ DA830 - ti,da830-lcdc
+ AM335x SoC's - ti,am3352-lcdc, ti,da830-lcdc
+- reg: Address range of lcdc register set
+- interrupts: lcdc interrupt
+
+Example:
+
+lcdc@4830e000 {
+ compatible = ti,am3352-lcdc, ti,da830-lcdc;
+ reg = 0x4830e000 0x1000;
+ interrupts = 36;
+};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index b6ea5e9..08ee8eb 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1595,6 +1595,12 @@ static int fb_resume(struct platform_device *dev)
#define fb_resume NULL
#endif
+static const struct of_device_id da8xx_fb_of_match[] = {
+ {.compatible = ti,da830-lcdc, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_fb_of_match);
+
static struct platform_driver da8xx_fb_driver = {
.probe = fb_probe,
.remove = fb_remove,
@@ -1603,6 +1609,7 @@ static struct platform_driver da8xx_fb_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(da8xx_fb_of_match),
},
};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/12] video: da8xx-fb: invoke platform callback safely
Ensure that platform data is present before checking whether platform
callback is present (the one used to control backlight). So far this
was not an issue as driver was purely non-DT triggered, but now DT
support has been added.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 08ee8eb..0beed20 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1347,7 +1347,7 @@ static int fb_probe(struct platform_device *device)
par-dev = device-dev;
par-lcdc_clk = fb_clk;
par-lcd_fck_rate = clk_get_rate(fb_clk);
- if (fb_pdata-panel_power_ctrl) {
+ if (fb_pdata fb_pdata-panel_power_ctrl) {
par-panel_power_ctrl = fb_pdata-panel_power_ctrl;
par-panel_power_ctrl(1);
}
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/12] video: da8xx-fb: setup struct lcd_ctrl_config for dt
strcut lcd_ctrl_config information required for driver is currently
obtained via platform data. To handle DT probing, create
lcd_ctrl_config and populate it with default values, these values are
sufficient for the panels so far used with this controller to work.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/video/da8xx-fb.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 1c1a616..5455682 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1254,6 +1254,35 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
};
+static struct lcd_ctrl_config *da8xx_fb_create_cfg(struct platform_device *dev)
+{
+ struct lcd_ctrl_config *cfg;
+
+ cfg = devm_kzalloc(dev-dev, sizeof(struct fb_videomode), GFP_KERNEL);
+ if (!cfg) {
+ dev_err(dev-dev, memory allocation failed\n);
+ return NULL;
+ }
+
+ /* default values */
+
+ if (lcd_revision == LCD_VERSION_1)
+ cfg-bpp = 16;
+ else
+ cfg-bpp = 32;
+
+ /*
+* For panels so far used with this LCDC, below statement is sufficient.
+* For new panels, if required, struct lcd_ctrl_cfg fields to be updated
+* with additional/modified values. Those values would have to be then
+* obtained from dt(requiring new dt bindings).
+*/
+
+ cfg-panel_shade = COLOR_ACTIVE;
+
+ return cfg;
+}
+
static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
{
struct da8xx_lcdc_platform_data *fb_pdata = dev-dev.platform_data;
@@ -1345,7 +1374,10 @@ static int fb_probe(struct platform_device *device)
break;
}
- lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
+ if (device-dev.of_node)
+ lcd_cfg = da8xx_fb_create_cfg(device);
+ else
+ lcd_cfg = (struct lcd_ctrl_config *)fb_pdata-controller_data;
if (!lcd_cfg) {
ret = -EINVAL;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
Another solution would be to model an inherited basic clock divider of
CCF, an advantage would be a better possible resolution for pixel clk.
And trying to instantiate a CCF clock would mean that to be consistent,
3 bits being turned on to enable clocks of LCDC IP would have to be
modeled as gate clocks. Now that would bring in a total of 4 clocks,
including necessity to create a new inherited divider clock, and that
mean a branch of clock tree would be present in LCDC driver. This
would add complexity to LCDC driver bringing in considerable amount
of clock handling code, and this would not bring in much advantage
for existing use cases other than providing a higher resolution of
pixel clock. And existing use cases work without relying on clock
modeling. Another fact is that out of the two platform's using this
driver DaVinci is not yet converted to CCF. In future if higher
resolution of pixel clock is required, and probably after DaVinci is
CCF'ed, modeling clock nodes inside driver may be considered.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v5: use v2 method of configuring pixel clock rate instead of modeling
CCF clock nodes in driver, i.e. set divider if rate is within
the range that is configurable with existing input clock rate,
else change input clock rate as required.
v4: use new registration for clock divider having minimum divider
requirement and have ifdef'ery in a better way
v3: model CCF clock divider with parent propogation if CCF selected
v2: new patch
drivers/video/da8xx-fb.c | 76
1 file changed, 58 insertions(+), 18 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 5455682..09dfa12 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -133,6 +133,9 @@
#define WSI_TIMEOUT50
#define PALETTE_SIZE 256
+#defineCLK_MIN_DIV 2
+#defineCLK_MAX_DIV 255
+
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
@@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)
}
}
-static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
-unsigned pixclock)
-{
- return par-lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
-}
-
-static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
- unsigned pixclock)
+static int da8xx_fb_config_clk_divider(struct da8xx_fb_par *par,
+ unsigned div, unsigned rate)
{
- unsigned div;
+ int ret;
- div = da8xx_fb_calc_clk_divider(par, pixclock);
- return KHZ2PICOS(par-lcd_fck_rate / (1000 * div));
-}
+ if (par-lcd_fck_rate != rate) {
+ ret = clk_set_rate(par-lcdc_clk, rate);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(par-dev,
+ unable to set clock rate at %u\n, rate);
+ return ret;
+ }
+ par-lcd_fck_rate = clk_get_rate(par-lcdc_clk);
+ }
-static inline void da8xx_fb_config_clk_divider(unsigned div)
-{
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE 0x1), LCD_CTRL_REG);
@@ -707,14 +708,49 @@ static inline void da8xx_fb_config_clk_divider(unsigned
div)
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+
+ return 0;
+}
+
+static unsigned int da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
+ unsigned pixclock,
+ unsigned *rate)
+{
+ unsigned div;
+
+ pixclock = PICOS2KHZ(pixclock) * 1000;
+
+ *rate = par-lcd_fck_rate;
+
+ if (pixclock (*rate / CLK_MAX_DIV)) {
+ *rate = clk_round_rate(par-lcdc_clk, pixclock * CLK_MAX_DIV);
+ div = CLK_MAX_DIV;
+ } else if (pixclock (*rate / CLK_MIN_DIV)) {
+ *rate = clk_round_rate(par-lcdc_clk, pixclock * CLK_MIN_DIV);
+ div = CLK_MIN_DIV;
+ } else {
+ div = *rate / pixclock;
+ }
+
+ return div;
}
-static inline void
[PATCH v5 01/12] video: da8xx-fb: make io operations safe
Replace __raw_readl/__raw_writel with readl/writel; this driver is
reused on ARMv7 (AM335x SoC).
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: new patch
drivers/video/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 720604c..35a33ca 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -141,12 +141,12 @@ static int frame_done_flag;
static inline unsigned int lcdc_read(unsigned int addr)
{
- return (unsigned int)__raw_readl(da8xx_fb_reg_base + (addr));
+ return (unsigned int)readl(da8xx_fb_reg_base + (addr));
}
static inline void lcdc_write(unsigned int val, unsigned int addr)
{
- __raw_writel(val, da8xx_fb_reg_base + (addr));
+ writel(val, da8xx_fb_reg_base + (addr));
}
struct da8xx_fb_par {
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/12] video: da8xx-fb: fix 24bpp raster configuration
From: Manjunathappa, Prakash prakash...@ti.com Set only LCD_V2_TFT_24BPP_MODE bit for 24bpp and LCD_V2_TFT_24BPP_UNPACK bit along with LCD_V2_TFT_24BPP_MODE for 32bpp configuration. Patch is tested on am335x-evm for 24bpp and da850-evm for 16bpp configurations. Signed-off-by: Manjunathappa, Prakash prakash...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/video/da8xx-fb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 35a33ca..7f92f37 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -550,10 +550,10 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, u32 width, u32 height, case 4: case 16: break; - case 24: - reg |= LCD_V2_TFT_24BPP_MODE; case 32: reg |= LCD_V2_TFT_24BPP_UNPACK; + case 24: + reg |= LCD_V2_TFT_24BPP_MODE; break; case 8: -- 1.7.12 -- 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: RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Hi Mike, On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote: Is MULT_ROUND_UP doing the right thing for you in the clk_divider code? What is the clock rate requested of the parent PLL? I just want to make sure that we're doing the right thing in the basic divider code. Actually MULT_ROUND_UP made my life difficult earlier, and finally came up with this solution instead of removing it. It was something like 6000 requested of PLL, for i = 1, but for other values, it was something like 6001, 6002 etc. Even if round rate rounds, I thought removing MULT_ROUND_UP would be ok, couldn't spend time to understand fully rational behind it, and as it was in generic code, kept away from doing it. Regards Afzal
RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
Hi Rob,
On Fri, Jan 25, 2013 at 20:22:55, Rob Clark wrote:
On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal af...@ti.com wrote:
It's not about being simple, but not doing the wrong way, here you are
relying on a platform specific clock in a driver, think about the case
where same IP is used on another platform. Either way it is not a good
thing to handle platform specific details (about disp_clk) in driver.
Right, but I was trying to understand what was the benefit that the
added complexity is. I didn't realize on davinci that you are limited
Here I am referring to usage of disp_clk,
Driver is not supposed to do platform hacks - here you are trying to
configure something (PLL) in your driver which is not part of LCDC IP.
And LCDC IP is not aware of PLL which is a platform specific matter
(existent only in AM335x), it is only aware of functional clock.
You can set the rate on fck (functional clock) in AM335x using my patch,
ARM: AM33XX: clock: SET_RATE_PARENT in lcd path, and there
would not be any need for driver to be aware of platform specific PLL.
+ priv-clk = clk_get(dev-dev, fck);
+ priv-disp_clk = clk_get(dev-dev, dpll_disp_ck);
at the moment all this discussion is a bit moot. I'd propose leaving
the driver as it is for now, because that at least makes it useful on
am33xx. And when CCF and davinci have the needed support in place,
Let's forget about leveraging CCF in driver, but sane solution w.r.t PLL
configuration would be to do as mentioned above.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 1/3] usb: otg: nop: add dt support
Hi Michael,
On Mon, Jan 28, 2013 at 03:10:05, Michael Grzeschik wrote:
On Thu, Sep 27, 2012 at 11:15:05AM +0530, Afzal Mohammed wrote:
From: B, Ravi ravib...@ti.com
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
What happend to that patch? It did not show up in any new series. Is it
queued anywhere?
This patch was not required to get the single instance usb supported
on am335x.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [BUG] panda board locks up on boot
From: Nishanth Menon [mailto:menon.nisha...@gmail.com] Sent: den 27 januari 2013 15:34 To: Paolo Pisati Cc: Mats Liljegren; Tony Lindgren; LKML; Steven Rostedt; Igor Grinberg; Russell King; Venkatraman S; linux-arm-kernel; linux-omap Subject: Re: [BUG] panda board locks up on boot On 01/27/2013 08:12 AM, Paolo Pisati wrote: On Fri, Jan 25, 2013 at 08:43:15AM +, Mats Liljegren wrote: Hi Steven, Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in linux- kernel forum (Failed booting PandaBoard ES with Linux 3.8 RC4 two days ago) my PandaBoard ES hangs while booting with this option enabled. It works fine without it. I have not bisected it down to a single commit though. glad i'm not the only one who hit this problem: 3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc http://www.mail-archive.com/linux- o...@vger.kernel.org/msg83693.html Support for TPS is not yet in mainline kernel. you may want to do: you could try running 'mw.w 0x4A31E05A 0x1' before bootm in u-boot - This will hack the pad of panda ES pin mean for controlling TPS voltage register (again a kernel bug where the GPIO block setup by bootloader got reset). CPUfreq needs both voltage and frequency scaling to work and without support of the TPS voltage scaling on vdd_MPU, you are stuck at boot voltage, and just scaling frequency. with the not-enough boot voltage, moving to higher frequencies can/will result in unpredictable behavior. --- Regards, NM Thanks for the suggestion. Unfortunately it didn't make any difference for me, neither did an upgrade to 3.8-rc5. I guess I have to wait for the TPS support to hit mainline kernel. Regards Mats -- 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-rc5
Hi,
On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
* am335xbone: hangs after Starting kernel
- Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
- http://marc.info/?l=linux-omapm=135903184512238w=2
FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
to help my bone, no matter if I had appended DTB or not.
Following patch with low level debug may help to find where the issue is,
(my observation is that it boots with mainline u-boot)
Regards
Afzal
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..178a411 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -117,6 +117,10 @@ config SOC_AM33XX
select CPU_V7
select MULTI_IRQ_HANDLER
select COMMON_CLK
+ select MACH_AM335XEVM
+
+config MACH_AM335XEVM
+ bool
config OMAP_PACKAGE_ZAF
bool
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: OMAP baseline test results for v3.8-rc5
Hi, On Mon, Jan 28, 2013 at 11:34:15AM +0100, Mohammed, Afzal wrote: Hi, On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote: On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote: * am335xbone: hangs after Starting kernel - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y? - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html - http://marc.info/?l=linux-omapm=135903184512238w=2 FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and without it, also removed CONFIG_DEBUG_LL completely and nothing seemed to help my bone, no matter if I had appended DTB or not. Following patch with low level debug may help to find where the issue is, (my observation is that it boots with mainline u-boot) will try your patch, but are you using Beagle Bone white or black ? I should've made it clear I'm using beagle bone black. -- balbi signature.asc Description: Digital signature
RE: OMAP baseline test results for v3.8-rc5
Hi Felipe,
On Mon, Jan 28, 2013 at 16:17:52, Balbi, Felipe wrote:
will try your patch, but are you using Beagle Bone white or black ? I
should've made it clear I'm using beagle bone black.
Hmm.., I am using white, have never tried on black.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: OMAP baseline test results for v3.8-rc5
Hi, On Mon, Jan 28, 2013 at 11:55:20AM +0100, Mohammed, Afzal wrote: Hi Felipe, On Mon, Jan 28, 2013 at 16:17:52, Balbi, Felipe wrote: will try your patch, but are you using Beagle Bone white or black ? I should've made it clear I'm using beagle bone black. Hmm.., I am using white, have never tried on black. ok, maybe there's something missing to get Black booting up :-s -- balbi signature.asc Description: Digital signature
RE: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, January 25, 2013 2:21 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; Valentin, Eduardo; mturque...@linaro.org Subject: Re: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430 Hi, On Fri, 18 Jan 2013, J Keerthy wrote: The previous logic to detect the clocks for OMAP4460 was to combine the clocks marked as CK_443X and CK_446X. This would be fine as long as OMAP4460 was a super set of OMAP4430 clock set. This is not the case as there are clocks which are specific to OMAP4430 (for example bandgap_fclk) and some which are specific to OMAP4460(for example bandgap_ts_fclk). The clock bandgap_fclk is specific for OMAP4430 and this was added as part of OMAP4460 clock set which should not be done. Hence changing the convention. CK_446X Clocks specific to OMAP4460 CK_443X Clocks specific to OMAP4430 CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430 Boot Tested on both Panda and Panda-es. Signed-off-by: J Keerthy j-keer...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Eduardo Valentin eduardo.valen...@ti.com While I agree with this patch, my understanding is that Tony wishes to shift to list-based initialization for clocks, similar to how the hwmod initialization is done for OMAP3. This will result in moving away from the CK_* flags. There are some previous public mailing list messages on this topic that you can probably find by searching for CK_446X. Now that we've switched to the common clock framework, it should be more practical to do this conversion, since we can refer to parent clocks by name rather than by pointer. Could you please update your patch to take that approach instead? Thanks for your feedback. I am in the process of removing all the CK_* flags and making separate lists instead. I am not Able to figure out where/how exactly the flag CK_TI816X Is getting used. Which family of processors are chosen Using this flag? Which clock nodes are selected using This flag? - Paul Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: omap5-evm: Add I2c pinctrl data
Booting 3.8-rc4 om omap 5430evm results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap5 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap5430 evm with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 62 +++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 8722c15..a96acc0 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -80,6 +80,41 @@
0x15a 0x100 /* abemcbsp2_clkx.abemcbsp2_clkx INPUT
| MODE0 */
;
};
+
+i2c1_pins: pinmux_i2c1_pins {
+pinctrl-single,pins =
+0x1b2 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+0x1b4 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+;
+};
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 0x100/* i2c2_scl INPUTENABLE | MODE0 */
+ 0x17a 0x100/* i2c2_sda INPUTENABLE | MODE0 */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0x13a 0x100/* i2c3_scl INPUTENABLE | MODE0 */
+ 0x13c 0x100 /* i2c3_sda INPUTENABLE | MODE0 */
+ ;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins =
+ 0xb8 0x100/* i2c4_scl INPUTENABLE | MODE0 */
+ 0xba 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ ;
+ };
+
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x184 0x100/* i2c4_scl INPUTENABLE | MODE0 */
+ 0x186 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ ;
+ };
};
mmc1 {
@@ -106,7 +141,17 @@
status = disabled;
};
+i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+
+ clock-frequency = 40;
+};
+
i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
clock-frequency = 40;
/* Pressure Sensor */
@@ -116,7 +161,17 @@
};
};
+i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_pins;
+
+ clock-frequency = 40;
+};
+
i2c4 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c4_pins;
+
clock-frequency = 40;
/* Temperature Sensor */
@@ -126,6 +181,13 @@
};
};
+i2c5 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+
+ clock-frequency = 40;
+};
+
keypad {
keypad,num-rows = 8;
keypad,num-columns = 8;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
Booting 3.8-rc4 om omap 4430sdp results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap4 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4430 sdp with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 40 +++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..40a04c9 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -212,9 +212,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118 /* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ ;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ ;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins =
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ ;
+ };
};
i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+
clock-frequency = 40;
twl: twl@48 {
@@ -253,10 +284,16 @@
/include/ twl6030.dtsi
i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
clock-frequency = 40;
};
i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_pins;
+
clock-frequency = 40;
/*
@@ -279,6 +316,9 @@
};
i2c4 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c4_pins;
+
clock-frequency = 40;
/*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] usb: dwc3/xhci: Enable runtime power management
This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on samsung-usb3 type PHY. This allows usb 3.0 host ports to be power managed at runtime. We also turn off the PHY ref_clk PLL, which supplies reference clock to USB3 type phy, when ports are not in use. This patch-series is based on 'usb-next' with follwing patches: usb: phy: samsung: Introducing usb phy driver for hsotg usb: phy: s3c-hsotg: adding phy driver support usb: phy: samsung: Add support to set pmu isolation ARM: EXYNOS: Update move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support usb: phy: samsung: Remove __devinit, __devexit_p and __exit annotations [PATCH v4 1/2] usb: phy: samsung: Common out the generic stuff [PATCH v4 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller Vivek Gautam (4): usb: xhci: Enable runtime pm in xhci-plat USB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend usb: dwc3: exynos: Enable runtime power management usb: phy: samsung: Enable runtime power management on samsung-usb3 drivers/usb/dwc3/core.c |4 +- drivers/usb/dwc3/dwc3-exynos.c | 47 + drivers/usb/host/xhci-plat.c |9 +++ drivers/usb/phy/samsung-usb3.c | 107 +++-- drivers/usb/phy/samsung-usbphy.c | 26 + drivers/usb/phy/samsung-usbphy.h |1 + 6 files changed, 187 insertions(+), 7 deletions(-) -- 1.7.6.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 1/4] usb: xhci: Enable runtime pm in xhci-plat
By enabling runtime pm in this driver is allows users of xhci-plat to enter into runtime pm. This is not full runtime pm support (AKA xhci-plat doesn't actually power anything off when in runtime suspend mode) but just basic enablement. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/usb/host/xhci-plat.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index df90fe5..6ad7cfb 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -139,6 +139,10 @@ static int xhci_plat_probe(struct platform_device *pdev) goto dealloc_usb2_hcd; } + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + pm_runtime_forbid(pdev-dev); + /* * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset) * is called by usb_add_hcd(). @@ -149,10 +153,13 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + pm_runtime_allow(pdev-dev); + return 0; put_usb3_hcd: usb_put_hcd(xhci-shared_hcd); + pm_runtime_disable(pdev-dev); dealloc_usb2_hcd: usb_remove_hcd(hcd); @@ -174,6 +181,8 @@ static int xhci_plat_remove(struct platform_device *dev) struct usb_hcd *hcd = platform_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + pm_runtime_disable(dev-dev); + usb_remove_hcd(xhci-shared_hcd); usb_put_hcd(xhci-shared_hcd); -- 1.7.6.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 2/4] USB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend
The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Note that this doesn't enable full runtime pm on the DWC3 device in that the port isn't put into a lower power mode when not used. However it does allow users of dwc3 (like dwc3-exynos) to do some amount of runtime power management. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3a4004a..59c2494 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -453,6 +453,7 @@ static int dwc3_probe(struct platform_device *pdev) if (of_get_property(node, tx-fifo-resize, NULL)) dwc-needs_fifo_resize = true; + pm_runtime_set_active(dev); pm_runtime_enable(dev); pm_runtime_get_sync(dev); pm_runtime_forbid(dev); @@ -517,6 +518,7 @@ static int dwc3_probe(struct platform_device *pdev) goto err2; } + pm_runtime_put(dev); pm_runtime_allow(dev); return 0; @@ -543,6 +545,7 @@ err1: err0: dwc3_free_event_buffers(dwc); + pm_runtime_disable(pdev-dev); return ret; } @@ -554,7 +557,6 @@ static int dwc3_remove(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); dwc3_debugfs_exit(dwc); -- 1.7.6.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: OMAP baseline test results for v3.8-rc5
Hi,
On Mon, Jan 28, 2013 at 11:34:15AM +0100, Mohammed, Afzal wrote:
Hi,
On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote:
* am335xbone: hangs after Starting kernel
- Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
- http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html
- http://marc.info/?l=linux-omapm=135903184512238w=2
FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
to help my bone, no matter if I had appended DTB or not.
Following patch with low level debug may help to find where the issue is,
(my observation is that it boots with mainline u-boot)
Regards
Afzal
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..178a411 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -117,6 +117,10 @@ config SOC_AM33XX
select CPU_V7
select MULTI_IRQ_HANDLER
select COMMON_CLK
+ select MACH_AM335XEVM
+
+config MACH_AM335XEVM
+ bool
config OMAP_PACKAGE_ZAF
bool
seems to be a bug with __unflatten_device_tree()...
U-Boot SPL 2013.01-9-g54b08ef (Jan 25 2013 - 10:26:10)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.01-9-g54b08ef (Jan 25 2013 - 10:26:10)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO
Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO
Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: cpsw, usb_ether
Hit any key to stop autoboot: 1 0
U-Boot#
U-Boot# ext2load mmc ${mmcdev}:2 0x80f8 /boot/am335x-bone.dtb
7967 bytes read in 17 ms (457 KiB/s)
U-Boot# setenv bootargs console=${console} ${optargs} root=${mmcroot}
rootfstype=${mmcrootfstype} debug earlyprintk mem=256M
U-Boot# ext2load mmc ${mmcdev}:2 ${loadaddr} ${bootfile}
4265360 bytes read in 502 ms (8.1 MiB/s)
U-Boot# bootm 0x8020 - 0x80f8
## Booting kernel from Legacy Image at 8020 ...
Image Name: Linux-3.8.0-rc5-02311-g1308c2b-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4265296 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
OK
Loading Device Tree to 9fe3e000, end 9fe42f1e ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-rc5-02311-g1308c2b-dirty (balbi@arwen) (gcc
version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #37 SMP Mon Jan 28
13:32:47 EET 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
AM335x BeagleBone
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c08331c0, node_mem_map
c0d91000
[0.00] Normal zone: 512 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 64768 pages, LIFO batch:15
[0.00] Unable to handle kernel paging request at virtual address
dfe3e000
[0.00] pgd = c0004000
[0.00] [dfe3e000] *pgd=
[0.00] Internal error: Oops: 5 [#1] SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0Not tainted (3.8.0-rc5-02311-g1308c2b-dirty #37)
[0.00] PC is at __unflatten_device_tree+0x1c/0x12c
[0.00] LR is at unflatten_device_tree+0x1c/0x34
[0.00] pc : [c0457d2c]lr : [c077a370]psr: a193
[0.00] sp : c07a5f80 ip : fp :
[0.00] r10: r9 : 413fc082 r8 : 80004059
[0.00] r7 : c0755dd0 r6 : c0783ac0 r5 : dfe3e000 r4 : c0755dd0
[0.00] r3 : d00dfeed r2 : c0755dd0 r1 : c0d8a8d4 r0 : dfe3e000
[0.00] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
kernel
[0.00] Control: 10c5387d Table: 80004019 DAC: 0017
[0.00] Process swapper (pid: 0, stack limit = 0xc07a4240)
[
[PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
Enabling runtime power management on dwc3-exynos to save
power and allow its PHY's power to be managed at runtime.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index aae5328..c51e8c1 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -157,11 +157,15 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err4;
}
+ pm_runtime_set_active(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+
return 0;
err4:
clk_disable(clk);
clk_put(clk);
+ pm_runtime_disable(pdev-dev);
err3:
platform_device_put(dwc3);
err1:
@@ -174,6 +178,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ pm_runtime_disable(pdev-dev);
+
platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
@@ -186,6 +192,46 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
return 0;
}
+static int dwc3_exynos_runtime_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_put_sync(dwc-usb3_phy-dev);
+
+ clk_disable(exynos-clk);
+
+ return 0;
+}
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+ SET_RUNTIME_PM_OPS(dwc3_exynos_runtime_suspend,
+ dwc3_exynos_runtime_resume, NULL)
+};
+
#ifdef CONFIG_OF
static const struct of_device_id exynos_dwc3_match[] = {
{ .compatible = samsung,exynos-dwc3 },
@@ -200,6 +246,7 @@ static struct platform_driver dwc3_exynos_driver = {
.driver = {
.name = exynos-dwc3,
.of_match_table = of_match_ptr(exynos_dwc3_match),
+ .pm = dwc3_exynos_pm_ops,
},
};
--
1.7.6.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 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb3
Enabling runtime power management support on samsung-usb3 phy
and further adding support to turn off the PHY ref_clk PLL.
It thereby requires PHY ref_clk to be switched between internal
core clock and external PLL clock.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/phy/samsung-usb3.c | 107 +++--
drivers/usb/phy/samsung-usbphy.c | 26 +
drivers/usb/phy/samsung-usbphy.h |1 +
3 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/samsung-usb3.c b/drivers/usb/phy/samsung-usb3.c
index 29e1321..4dbef15 100644
--- a/drivers/usb/phy/samsung-usb3.c
+++ b/drivers/usb/phy/samsung-usb3.c
@@ -22,8 +22,10 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/gpio.h
#include linux/io.h
#include linux/of.h
+#include linux/pm_runtime.h
#include linux/usb/samsung_usb_phy.h
#include linux/platform_data/samsung-usbphy.h
@@ -32,7 +34,7 @@
/*
* Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
core.
*/
-static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy *sphy)
+static u32 samsung_usb3_phy_set_refclk_int(struct samsung_usbphy *sphy)
{
u32 reg;
u32 refclk;
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy
*sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from external PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
+
+static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy,
+ bool use_ext_clk)
{
void __iomem *regs = sphy-regs;
u32 phyparam0;
@@ -80,7 +97,11 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
/* Select PHY CLK source */
- phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+ if (use_ext_clk)
+ phyparam0 |= PHYPARAM0_REF_USE_PAD;
+ else
+ phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+
/* Set Loss-of-Signal Detector sensitivity */
phyparam0 = ~PHYPARAM0_REF_LOSLEVEL_MASK;
phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
@@ -115,7 +136,10 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
/* UTMI Power Control */
writel(PHYUTMI_OTGDISABLE, regs + EXYNOS5_DRD_PHYUTMI);
- phyclkrst = samsung_usb3_phy_set_refclk(sphy);
+ if (use_ext_clk)
+ phyclkrst = samsung_usb3_phy_set_refclk_ext();
+ else
+ phyclkrst = samsung_usb3_phy_set_refclk_int(sphy);
phyclkrst |= PHYCLKRST_PORTRESET |
/* Digital power supply in normal operating mode */
@@ -163,7 +187,7 @@ static void samsung_exynos5_usb3_phy_disable(struct
samsung_usbphy *sphy)
writel(phytest, regs + EXYNOS5_DRD_PHYTEST);
}
-static int samsung_usb3_phy_init(struct usb_phy *phy)
+static int samsung_exynos5_usb3_phy_init(struct usb_phy *phy, bool use_ext_clk)
{
struct samsung_usbphy *sphy;
unsigned long flags;
@@ -187,7 +211,7 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
samsung_usbphy_set_isolation(sphy, false);
/* Initialize usb phy registers */
- samsung_exynos5_usb3_phy_enable(sphy);
+ samsung_exynos5_usb3_phy_enable(sphy, use_ext_clk);
spin_unlock_irqrestore(sphy-lock, flags);
@@ -198,6 +222,34 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
}
/*
+ * Switch between internal core clock and external oscillator clock
+ * for PHY reference clock
+ */
+static int samsung_exynos5_usb3phy_clk_switch(struct usb_phy *phy,
+ bool use_ext_clk)
+{
+ /*
+* This will switch PHY refclk from internal core clock
+* to external PLL clock when device is in use and vice versa
+* when device plunge into runtime suspend mode.
+*/
+ return samsung_exynos5_usb3_phy_init(phy, use_ext_clk);
+}
+
+/*
+ * The function passed to the usb driver for phy initialization
+ */
+static int samsung_usb3_phy_init(struct usb_phy *phy)
+{
+ /*
+* We start with using PHY refclk from external PLL,
+* once runtime suspend for the device is called this
+* will change to internal core clock
+*/
+ return samsung_exynos5_usb3_phy_init(phy, true);
+}
+
+/*
* The function passed to the usb driver for phy shutdown
*/
static void samsung_usb3_phy_shutdown(struct usb_phy *phy)
@@ -287,6 +339,9 @@ static int samsung_usb3_phy_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, sphy);
+
Re: OMAP baseline test results for v3.8-rc5
On 28/01/13 10:34, Mohammed, Afzal wrote: Hi, On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote: On Sat, Jan 26, 2013 at 08:40:07AM +, Paul Walmsley wrote: * am335xbone: hangs after Starting kernel - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y? - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html - http://marc.info/?l=linux-omapm=135903184512238w=2 FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and without it, also removed CONFIG_DEBUG_LL completely and nothing seemed to help my bone, no matter if I had appended DTB or not. Following patch with low level debug may help to find where the issue is, (my observation is that it boots with mainline u-boot) Regards Afzal diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 41b581f..178a411 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -117,6 +117,10 @@ config SOC_AM33XX select CPU_V7 select MULTI_IRQ_HANDLER select COMMON_CLK + select MACH_AM335XEVM + +config MACH_AM335XEVM + bool config OMAP_PACKAGE_ZAF bool I can confirm that this patch works with EARLY_PRINTK and DEBUG_LL enabled (current mainline kernel and u-boot), and the following .config changes:- $ diff .config.omap2plus_defconfig .config 505c505,508 # CONFIG_ARM_APPENDED_DTB is not set --- CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set 2659c2662,2665 # CONFIG_DEBUG_LL is not set --- CONFIG_DEBUG_LL=y CONFIG_DEBUG_LL_UART_NONE=y # CONFIG_DEBUG_ICEDCC is not set # CONFIG_DEBUG_SEMIHOSTING is not set 2660a2667 CONFIG_EARLY_PRINTK=y Boot log Filename '/nanobone/uImage-dtb'. Load address: 0x8000 Loading: # # # # # 627 KiB/s done Bytes transferred = 3946799 (3c392f hex) ## Booting kernel from Legacy Image at 8000 ... Image Name: Linux 3.8.0-rc5-dirty Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3946735 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc5-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #9 SMP Mon Jan 28 11:34:19 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c07c7040, node_mem_map c0d27000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 64768 pages, LIFO batch:15 [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f3 s12992 r8192 d15680 u36864 [0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait snip [1.702800] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720 [1.713088] Random MACID = 56:e9:38:ee:af:e4 [1.723695] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [1.735470] Waiting for root device /dev/mmcblk0p2... Still no support for rootfs on MMC, but hopefully that won't be long ?? Regards Mark J. -- 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-rc5
Hi Felipe, On Mon, Jan 28, 2013 at 17:08:19, Balbi, Felipe wrote: seems to be a bug with __unflatten_device_tree()... U-Boot# bootm 0x8020 - 0x80f8 Try loading dtb at a different address, I do, bootm 8100 - 8200 Regards Afzal
Re: [PATCH 2/4] USB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend
On Mon, Jan 28, 2013 at 05:12:26PM +0530, Vivek Gautam wrote: The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Note that this doesn't enable full runtime pm on the DWC3 device in that the port isn't put into a lower power mode when not used. However it does allow users of dwc3 (like dwc3-exynos) to do some amount of runtime power management. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3a4004a..59c2494 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -453,6 +453,7 @@ static int dwc3_probe(struct platform_device *pdev) if (of_get_property(node, tx-fifo-resize, NULL)) dwc-needs_fifo_resize = true; + pm_runtime_set_active(dev); this usage of pm_runtime_set_active() actually makes me a bit scared. At least OMAP starts with the device switched off, so this will probably break OMAP at least. OTOH, calling -runtime_resume() during probe() might not make that much sense after all, but the way OMAP is implemented, we won't get clocks turned on if this -runtime_resume() method isn't called. /me starts to wonder whether OMAP implementation is flakey and what should be done here... -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
On Mon, Jan 28, 2013 at 05:12:27PM +0530, Vivek Gautam wrote:
Enabling runtime power management on dwc3-exynos to save
power and allow its PHY's power to be managed at runtime.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index aae5328..c51e8c1 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -157,11 +157,15 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
goto err4;
}
+ pm_runtime_set_active(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+
return 0;
err4:
clk_disable(clk);
clk_put(clk);
+ pm_runtime_disable(pdev-dev);
err3:
platform_device_put(dwc3);
err1:
@@ -174,6 +178,8 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ pm_runtime_disable(pdev-dev);
+
platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
@@ -186,6 +192,46 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
return 0;
}
+static int dwc3_exynos_runtime_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_put_sync(dwc-usb3_phy-dev);
+
+ clk_disable(exynos-clk);
+
+ return 0;
+}
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
dude, this is wrong :-)
look at this:
pm_runtime_get() - dwc3_exynos_runtime_resume() -
pm_runtime_get_sync() - dwc3_exynos_runtime_resume() - ...
only your clock enalbe should do
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
On Fri, Jan 25, 2013 at 06:11:28PM +, Ezequiel Garcia wrote:
Hi Mark,
First of all: thanks for reviewing.
On Fri, Jan 25, 2013 at 12:56 PM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
I have a couple more comments after looking though this a bit more
thoroughly.
On Fri, Jan 25, 2013 at 12:23:11PM +, Ezequiel Garcia wrote:
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v2:
* Remove unneeded of_node_put() as reported by Mark Rutland
Changes from v1:
* Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
.../devicetree/bindings/mtd/gpmc-onenand.txt | 43
+++
arch/arm/mach-omap2/gpmc.c | 45
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..deec9da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child
nodes of
+the GPMC controller with a name of onenand.
+
+All timing relevant properties as well as generic gpmc child properties
are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
Which tree can I find this in?
GPMC binding was posted by Daniel Mack a while ago.
Tony has recently pushed it to his master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
Aha. Thanks, it's far easier to understand with the gpmc doc!
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel: DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ onenand@0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ /* partitions go here */
+ };
+ };
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c6255f7..0636d0a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
I don't understand the format of the reg property, but it seems odd that you
only need to read one cell from it. Are the remaining address cell and size
cell used anywhere?
Okey, I'll give a shot and try to explain this myself:
As you can see by Daniel's first patch [1]
the reg property originally contained the chip select only, and
after some discussion in that same thread, and in this one [2]
It was decided to use a reg property that would also describe
the base address and size of the gpmc sub-device,
and use ranges for the address translation.
This was reflected in Daniel's changelog when he submitted
the v2 patch series [3].
[1] http://www.spinics.net/lists/arm-kernel/msg202169.html
[2] http://web.archiveorange.com/archive/v/vEQ2yFI0tmpQJdigvAog
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129426.html
So if I've understood correctly, the first address cell is the CS, and the
second the offset within this (as the comment in the onenand@0 node hints)?
If so, the code now makes sense to me :)
I was having difficulty seeing where the base address of the child got
translated via ranges, but I see in [3] that
Re: [PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
Hi Balbi,
On Mon, Jan 28, 2013 at 5:17 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Jan 28, 2013 at 05:12:27PM +0530, Vivek Gautam wrote:
Enabling runtime power management on dwc3-exynos to save
power and allow its PHY's power to be managed at runtime.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index aae5328..c51e8c1 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -157,11 +157,15 @@ static int dwc3_exynos_probe(struct platform_device
*pdev)
goto err4;
}
+ pm_runtime_set_active(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+
return 0;
err4:
clk_disable(clk);
clk_put(clk);
+ pm_runtime_disable(pdev-dev);
err3:
platform_device_put(dwc3);
err1:
@@ -174,6 +178,8 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ pm_runtime_disable(pdev-dev);
+
platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
@@ -186,6 +192,46 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
return 0;
}
+static int dwc3_exynos_runtime_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_put_sync(dwc-usb3_phy-dev);
+
+ clk_disable(exynos-clk);
+
+ return 0;
+}
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
dude, this is wrong :-)
look at this:
pm_runtime_get() - dwc3_exynos_runtime_resume() -
pm_runtime_get_sync() - dwc3_exynos_runtime_resume() - ...
only your clock enalbe should do
We want to wake up dwc-usb3_phy so tried to call pm_runtime_get_sync()
with dwc-usb3_phy-dev.
Missing something ? :-(
--
Thanks Regards
Vivek
--
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] usb: phy: samsung: Enable runtime power management on samsung-usb3
Hi,
On Mon, Jan 28, 2013 at 05:12:28PM +0530, Vivek Gautam wrote:
Enabling runtime power management support on samsung-usb3 phy
and further adding support to turn off the PHY ref_clk PLL.
It thereby requires PHY ref_clk to be switched between internal
core clock and external PLL clock.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
this needs to be broken down a bit. I can see three patches at least:
add support for external clock, add support for phy gpio powerdown and
add runtime pm ;-)
---
drivers/usb/phy/samsung-usb3.c | 107 +++--
drivers/usb/phy/samsung-usbphy.c | 26 +
drivers/usb/phy/samsung-usbphy.h |1 +
3 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/samsung-usb3.c b/drivers/usb/phy/samsung-usb3.c
index 29e1321..4dbef15 100644
--- a/drivers/usb/phy/samsung-usb3.c
+++ b/drivers/usb/phy/samsung-usb3.c
@@ -22,8 +22,10 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/gpio.h
#include linux/io.h
#include linux/of.h
+#include linux/pm_runtime.h
#include linux/usb/samsung_usb_phy.h
#include linux/platform_data/samsung-usbphy.h
@@ -32,7 +34,7 @@
/*
* Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
core.
*/
-static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy *sphy)
+static u32 samsung_usb3_phy_set_refclk_int(struct samsung_usbphy *sphy)
{
u32 reg;
u32 refclk;
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
samsung_usbphy *sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from external
PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
I wonder if you really need this small function (likewise for
set_refclk_int()). They don't do much, so you could just inline them on
the only caller.
@@ -80,7 +97,11 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
/* Select PHY CLK source */
- phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+ if (use_ext_clk)
+ phyparam0 |= PHYPARAM0_REF_USE_PAD;
+ else
+ phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+
/* Set Loss-of-Signal Detector sensitivity */
phyparam0 = ~PHYPARAM0_REF_LOSLEVEL_MASK;
phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
@@ -115,7 +136,10 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
/* UTMI Power Control */
writel(PHYUTMI_OTGDISABLE, regs + EXYNOS5_DRD_PHYUTMI);
- phyclkrst = samsung_usb3_phy_set_refclk(sphy);
+ if (use_ext_clk)
+ phyclkrst = samsung_usb3_phy_set_refclk_ext();
+ else
+ phyclkrst = samsung_usb3_phy_set_refclk_int(sphy);
phyclkrst |= PHYCLKRST_PORTRESET |
/* Digital power supply in normal operating mode */
@@ -163,7 +187,7 @@ static void samsung_exynos5_usb3_phy_disable(struct
samsung_usbphy *sphy)
writel(phytest, regs + EXYNOS5_DRD_PHYTEST);
}
-static int samsung_usb3_phy_init(struct usb_phy *phy)
+static int samsung_exynos5_usb3_phy_init(struct usb_phy *phy, bool
use_ext_clk)
{
struct samsung_usbphy *sphy;
unsigned long flags;
@@ -187,7 +211,7 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
samsung_usbphy_set_isolation(sphy, false);
/* Initialize usb phy registers */
- samsung_exynos5_usb3_phy_enable(sphy);
+ samsung_exynos5_usb3_phy_enable(sphy, use_ext_clk);
spin_unlock_irqrestore(sphy-lock, flags);
@@ -198,6 +222,34 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
}
/*
+ * Switch between internal core clock and external oscillator clock
+ * for PHY reference clock
+ */
+static int samsung_exynos5_usb3phy_clk_switch(struct usb_phy *phy,
+ bool use_ext_clk)
+{
+ /*
+ * This will switch PHY refclk from internal core clock
+ * to external PLL clock when device is in use and vice versa
+ * when device plunge into runtime suspend mode.
+ */
+ return samsung_exynos5_usb3_phy_init(phy, use_ext_clk);
+}
+
+/*
+ * The function passed to the usb driver for phy initialization
+ */
+static int samsung_usb3_phy_init(struct usb_phy *phy)
+{
+ /*
+ * We start with using PHY refclk from external PLL,
+ * once runtime suspend for the device is called this
+ * will change to internal core clock
+ */
+ return samsung_exynos5_usb3_phy_init(phy, true);
+}
+
+/*
* The function passed to the usb driver for phy shutdown
Re: [PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
Hi,
On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
dude, this is wrong :-)
look at this:
pm_runtime_get() - dwc3_exynos_runtime_resume() -
pm_runtime_get_sync() - dwc3_exynos_runtime_resume() - ...
only your clock enalbe should do
We want to wake up dwc-usb3_phy so tried to call pm_runtime_get_sync()
with dwc-usb3_phy-dev.
Missing something ? :-(
oh, my bad. That's the PHY... But we can't really do that for samsung
only. It needs to be done generically for the entire dwc3 core driver,
and for that we need to introduce usb_phy_autopm_get(),
usb_phy_autopm_get_sync() and friends.
Then, from dwc_probe() we call:
phy = usb_get_phy();
usb_phy_autopm_enable(phy);
usb_phy_autopm_get_sync(phy);
or something similar ;-) Bottom line, you shouldn't fiddle with phy-dev
directly.
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.8-rc5
Hi, On Mon, Jan 28, 2013 at 12:46:21PM +0100, Mohammed, Afzal wrote: Hi Felipe, On Mon, Jan 28, 2013 at 17:08:19, Balbi, Felipe wrote: seems to be a bug with __unflatten_device_tree()... U-Boot# bootm 0x8020 - 0x80f8 Try loading dtb at a different address, I do, bootm 8100 - 8200 didn't help :-s U-Boot# bootm 0x8100 - 0x8200 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.8.0-rc5-02311-g1308c2b-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4265296 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8200 Booting using the fdt blob at 0x8200 Loading Kernel Image ... OK OK Loading Device Tree to 9fe3e000, end 9fe42f1e ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc5-02311-g1308c2b-dirty (balbi@arwen) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #37 SMP Mon Jan 28 13:32:47 EET 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c08331c0, node_mem_map c0d91000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 64768 pages, LIFO batch:15 [0.00] Unable to handle kernel paging request at virtual address dfe3e000 [0.00] pgd = c0004000 [0.00] [dfe3e000] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.8.0-rc5-02311-g1308c2b-dirty #37) [0.00] PC is at __unflatten_device_tree+0x1c/0x12c [0.00] LR is at unflatten_device_tree+0x1c/0x34 [0.00] pc : [c0457d2c]lr : [c077a370]psr: a193 [0.00] sp : c07a5f80 ip : fp : [0.00] r10: r9 : 413fc082 r8 : 80004059 [0.00] r7 : c0755dd0 r6 : c0783ac0 r5 : dfe3e000 r4 : c0755dd0 [0.00] r3 : d00dfeed r2 : c0755dd0 r1 : c0d8a8d4 r0 : dfe3e000 [0.00] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 80004019 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc07a4240) [0.00] Stack: (0xc07a5f80 to 0xc07a6000) [0.00] 5f80: c07b13d0 c00503b4 8fef c0d8a8d4 c0755dd0 c083607c c0783ac0 c07a5fe4 [0.00] 5fa0: 80004059 c077a370 c0781dd8 c0755028 c07a5fc4 c0783abc 0001 [0.00] 5fc0: c0783abc c07b11c4 c0751618 [0.00] 5fe0: c0783ac0 10c53c7d c07ac98c 80008078 [0.00] [c0457d2c] (__unflatten_device_tree+0x1c/0x12c) from [c077a370] (unflatten_device_tree+0x1c/0x34) [0.00] [c077a370] (unflatten_device_tree+0x1c/0x34) from [c0755028] (setup_arch+0xf8/0x190) [0.00] [c0755028] (setup_arch+0xf8/0x190) from [c0751618] (start_kernel+0x80/0x2a8) [0.00] [c0751618] (start_kernel+0x80/0x2a8) from [80008078] (0x80008078) [0.00] Code: e1a07002 e58d100c 0a33 e59f30f4 (e5951000) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! -- balbi signature.asc Description: Digital signature
RE: OMAP baseline test results for v3.8-rc5
Hi Felipe, On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote: didn't help :-s Hands up :( Regards Afzal
On MIPI-CSI2 YUV420 formats and V4L2 Media Bus formats
Hi, looking at the MIPI Alliance Specification for Camera Serial Interface 2 (I'll call it MIPI-CSI2 from now on, the document I am referring to is mentioned at [1] and available at [2]), I see there is an YUV420 8 bit format (MIPI Data Type 0x18) specified with interleaved components in the form of: ... (odd lines) UYVYUYVY... (even lines) With even lines twice the size of odd lines. Such format is also supported by some sensors, for instance ov5640, and by MIPI-CSI2 receivers like OMAP4 ISS. The doubt I have is: how should I represent those formats as media bus formats? I've seen that some drivers (sensors and SoC, for instance[3]) tend to identify the MIPI-CSI2 format above (0x18) with media bus formats like V4L2_MBUS_FMT_UYVY8_1_5X8 (actually the code above uses V4L2_MBUS_FMT_YUYV8_1_5X8 is this OK?), but from the v4l2 documentation [4] I understand that this format is supposed to have data in this configuration: ... ... ... ... ... ... That is with interleaved lines, but NOT interleaved components. Should new media bus formats be added for .../UYVYUYVY...? Another doubt I have is: how is the .../UYVYUYVY... data supposed to be processed in userspace? Is the MIPI Receiver (i.e, the SoC) expected to be able to convert it to a more usable format like YUV420P or NV12/NV21? Or are there applications capable of handling this data directly, or efficiently convert them to planar or semi-planar YUV420 formats? In particular I am curios if the OMAP4 ISS can do the conversion to NV12, I understand that the formats with interleaved _lines_ can be produced by the resizer and handled by the OMAP ISP DMA-Engine by setting buffers offsets to Y and UV in order to send NV12 data to userspace, but I couldn't find info about how to handle the YUV420 MIPI-CSI2 formats (interleaved components) without the resizer in the Developer Manual [5]; having NV12 data directly from the hardware without using the OMAP4 ISS/ISP Resizer can be valuable in some use cases (e.g. dual camera setups). Thanks, Antonio [1] http://www.mipi.org/specifications/camera-interface#CSI2 [2] http://ishare.sina.cn/dintro.php?id=20498632 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/platform/soc_camera/sh_mobile_csi2.c;h=a17aba9a0104c41cbc4e5e5d277010ecac577600;hb=HEAD#l108 [4] http://kernel.org/doc/htmldocs/media/subdev.html#v4l2-mbus-pixelcode-yuv8 [5] http://www.ti.com/lit/ug/swpu235w/swpu235w.pdf -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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 Fri, Jan 25, 2013 at 22:29:43, Tony Lindgren wrote: * Bedia, Vaibhav vaibhav.be...@ti.com [130123 06:35]: Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. Yes you should check with current linux next and select the DEBUG_LL port manually. Verified on linux-next that selecting the right UART port gives a functional early_console. (One of the rare cases where forcing a kernel panic early in the boot process makes sense ;) Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
On Mon, Jan 28, 2013 at 5:42 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
dude, this is wrong :-)
look at this:
pm_runtime_get() - dwc3_exynos_runtime_resume() -
pm_runtime_get_sync() - dwc3_exynos_runtime_resume() - ...
only your clock enalbe should do
We want to wake up dwc-usb3_phy so tried to call pm_runtime_get_sync()
with dwc-usb3_phy-dev.
Missing something ? :-(
oh, my bad. That's the PHY... But we can't really do that for samsung
only. It needs to be done generically for the entire dwc3 core driver,
and for that we need to introduce usb_phy_autopm_get(),
usb_phy_autopm_get_sync() and friends.
aah!! Ok. I definitely missed that part. :-(
Then, from dwc_probe() we call:
phy = usb_get_phy();
usb_phy_autopm_enable(phy);
usb_phy_autopm_get_sync(phy);
or something similar ;-) Bottom line, you shouldn't fiddle with phy-dev
directly.
Ok, the core should actually be handling the 'phy' not the glue layers.
Right ?
Will try putting these helper functions in place and come up with a
solution. :-)
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] usb: dwc3: exynos: Enable runtime power management
On Mon, Jan 28, 2013 at 05:57:04PM +0530, Vivek Gautam wrote:
On Mon, Jan 28, 2013 at 5:42 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ struct platform_device *pdev_dwc = exynos-dwc3;
+ struct dwc3 *dwc = NULL;
+
+ dwc = platform_get_drvdata(pdev_dwc);
+
+ clk_enable(exynos-clk);
+
+ if (!dwc)
+ return 0;
+
+ pm_runtime_get_sync(dwc-usb3_phy-dev);
dude, this is wrong :-)
look at this:
pm_runtime_get() - dwc3_exynos_runtime_resume() -
pm_runtime_get_sync() - dwc3_exynos_runtime_resume() - ...
only your clock enalbe should do
We want to wake up dwc-usb3_phy so tried to call pm_runtime_get_sync()
with dwc-usb3_phy-dev.
Missing something ? :-(
oh, my bad. That's the PHY... But we can't really do that for samsung
only. It needs to be done generically for the entire dwc3 core driver,
and for that we need to introduce usb_phy_autopm_get(),
usb_phy_autopm_get_sync() and friends.
aah!! Ok. I definitely missed that part. :-(
Then, from dwc_probe() we call:
phy = usb_get_phy();
usb_phy_autopm_enable(phy);
usb_phy_autopm_get_sync(phy);
or something similar ;-) Bottom line, you shouldn't fiddle with phy-dev
directly.
Ok, the core should actually be handling the 'phy' not the glue layers.
Right ?
that's right, thanks for doing this ;-)
Will try putting these helper functions in place and come up with a
solution. :-)
awesome ;-)
cheers
--
balbi
signature.asc
Description: Digital signature
[PATCH] ARM: OMAP: hwmod_reset: Include errno.h to fix compilation error
Without the errno.h: CC arch/arm/mach-omap2/omap_hwmod_reset.o arch/arm/mach-omap2/omap_hwmod_reset.c: In function ‘omap_hwmod_aess_preprogram’: arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: error: ‘EINVAL’ undeclared (first use in this function) arch/arm/mach-omap2/omap_hwmod_reset.c:47:11: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [arch/arm/mach-omap2/omap_hwmod_reset.o] Error 1 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Paul, I could not find the patches from Sebastien's series: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82971.html But AFAIK you have taken them for 3.9. This patch is on top of it to fix compilation error. Regards, Peter arch/arm/mach-omap2/omap_hwmod_reset.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c index bba43fa..65e186c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_reset.c +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c @@ -24,6 +24,7 @@ * 02110-1301 USA */ #include linux/kernel.h +#include linux/errno.h #include sound/aess.h -- 1.8.1.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 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb3
Hi Felipe,
On Mon, Jan 28, 2013 at 5:39 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jan 28, 2013 at 05:12:28PM +0530, Vivek Gautam wrote:
Enabling runtime power management support on samsung-usb3 phy
and further adding support to turn off the PHY ref_clk PLL.
It thereby requires PHY ref_clk to be switched between internal
core clock and external PLL clock.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
this needs to be broken down a bit. I can see three patches at least:
add support for external clock, add support for phy gpio powerdown and
add runtime pm ;-)
Alright, will break this into required number of patches.
---
drivers/usb/phy/samsung-usb3.c | 107
+++--
drivers/usb/phy/samsung-usbphy.c | 26 +
drivers/usb/phy/samsung-usbphy.h |1 +
3 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/samsung-usb3.c b/drivers/usb/phy/samsung-usb3.c
index 29e1321..4dbef15 100644
--- a/drivers/usb/phy/samsung-usb3.c
+++ b/drivers/usb/phy/samsung-usb3.c
@@ -22,8 +22,10 @@
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
+#include linux/gpio.h
#include linux/io.h
#include linux/of.h
+#include linux/pm_runtime.h
#include linux/usb/samsung_usb_phy.h
#include linux/platform_data/samsung-usbphy.h
@@ -32,7 +34,7 @@
/*
* Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
core.
*/
-static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy *sphy)
+static u32 samsung_usb3_phy_set_refclk_int(struct samsung_usbphy *sphy)
{
u32 reg;
u32 refclk;
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
samsung_usbphy *sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from external
PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
I wonder if you really need this small function (likewise for
set_refclk_int()). They don't do much, so you could just inline them on
the only caller.
Created this just to keep symmetry, ;-)
will move this in the caller only.
@@ -80,7 +97,11 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
/* Select PHY CLK source */
- phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+ if (use_ext_clk)
+ phyparam0 |= PHYPARAM0_REF_USE_PAD;
+ else
+ phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+
/* Set Loss-of-Signal Detector sensitivity */
phyparam0 = ~PHYPARAM0_REF_LOSLEVEL_MASK;
phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
@@ -115,7 +136,10 @@ static int samsung_exynos5_usb3_phy_enable(struct
samsung_usbphy *sphy)
/* UTMI Power Control */
writel(PHYUTMI_OTGDISABLE, regs + EXYNOS5_DRD_PHYUTMI);
- phyclkrst = samsung_usb3_phy_set_refclk(sphy);
+ if (use_ext_clk)
+ phyclkrst = samsung_usb3_phy_set_refclk_ext();
+ else
+ phyclkrst = samsung_usb3_phy_set_refclk_int(sphy);
phyclkrst |= PHYCLKRST_PORTRESET |
/* Digital power supply in normal operating mode */
@@ -163,7 +187,7 @@ static void samsung_exynos5_usb3_phy_disable(struct
samsung_usbphy *sphy)
writel(phytest, regs + EXYNOS5_DRD_PHYTEST);
}
-static int samsung_usb3_phy_init(struct usb_phy *phy)
+static int samsung_exynos5_usb3_phy_init(struct usb_phy *phy, bool
use_ext_clk)
{
struct samsung_usbphy *sphy;
unsigned long flags;
@@ -187,7 +211,7 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
samsung_usbphy_set_isolation(sphy, false);
/* Initialize usb phy registers */
- samsung_exynos5_usb3_phy_enable(sphy);
+ samsung_exynos5_usb3_phy_enable(sphy, use_ext_clk);
spin_unlock_irqrestore(sphy-lock, flags);
@@ -198,6 +222,34 @@ static int samsung_usb3_phy_init(struct usb_phy *phy)
}
/*
+ * Switch between internal core clock and external oscillator clock
+ * for PHY reference clock
+ */
+static int samsung_exynos5_usb3phy_clk_switch(struct usb_phy *phy,
+ bool use_ext_clk)
+{
+ /*
+ * This will switch PHY refclk from internal core clock
+ * to external PLL clock when device is in use and vice versa
+ * when device plunge into runtime suspend mode.
+ */
+ return samsung_exynos5_usb3_phy_init(phy, use_ext_clk);
+}
+
+/*
+ * The function passed to the usb driver for phy initialization
+ */
+static int samsung_usb3_phy_init(struct usb_phy *phy)
+{
+ /*
+ * We start with using PHY refclk from external PLL,
+ * once runtime suspend for the device
Re: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb3
Hi,
On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
samsung_usbphy *sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from external
PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
I wonder if you really need this small function (likewise for
set_refclk_int()). They don't do much, so you could just inline them on
the only caller.
Created this just to keep symmetry, ;-)
will move this in the caller only.
you can have a patch before this series moving the refclk_int() to the
caller, then you will have symmetry ;-)
--
balbi
signature.asc
Description: Digital signature
[PATCH] cpsw: Fix interrupt storm among other things
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.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 1 +
drivers/net/ethernet/ti/cpsw.c | 222 +
drivers/net/ethernet/ti/davinci_cpdma.c| 4 +-
drivers/net/ethernet/ti/davinci_cpdma.h| 2 +-
include/linux/platform_data/cpsw.h | 1 +
5 files changed, 194 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..d46b293 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -20,6 +20,7 @@ Required properties:
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
+- disable-napi : Disables driver NAPI
Optional properties:
- ti,hwmods: Must be cpgmac0
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;
+ u32 c1_rx_thresh_en;
+ u32 c1_rx_en;
+ u32 c1_tx_en;
+ u32 c1_misc_en;
+ u32 c2_rx_thresh_en;
+ u32 c2_rx_en;
+ u32 c2_tx_en;
+ u32 c2_misc_en;
+ u32 c0_rx_thresh_stat;
+ u32 c0_rx_stat;
+ u32 c0_tx_stat;
+ u32 c0_misc_stat;
+ u32 c1_rx_thresh_stat;
+ u32 c1_rx_stat;
+ u32 c1_tx_stat;
+ u32 c1_misc_stat;
+ u32 c2_rx_thresh_stat;
+ u32 c2_rx_stat;
+ u32 c2_tx_stat;
+ u32 c2_misc_stat;
+ u32 c0_rx_imax;
+ u32 c0_tx_imax;
+ u32 c1_rx_imax;
+ u32 c1_tx_imax;
+ u32 c2_rx_imax;
+ u32 c2_tx_imax;
+ u32 rgmii_ctl;
};
struct cpsw_ss_regs {
@@ -352,8 +379,8 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
static void cpsw_intr_enable(struct cpsw_priv *priv)
{
- __raw_writel(0xFF, priv-wr_regs-tx_en);
- __raw_writel(0xFF, priv-wr_regs-rx_en);
+ __raw_writel(0xFF, priv-wr_regs-c0_tx_en);
+ __raw_writel(0xFF, priv-wr_regs-c0_rx_en);
cpdma_ctlr_int_ctrl(priv-dma, true);
return;
@@ -361,8 +388,8 @@ static void cpsw_intr_enable(struct cpsw_priv *priv)
static void cpsw_intr_disable(struct cpsw_priv *priv)
{
- __raw_writel(0, priv-wr_regs-tx_en);
- __raw_writel(0, priv-wr_regs-rx_en);
+ __raw_writel(0, priv-wr_regs-c0_tx_en);
+ __raw_writel(0, priv-wr_regs-c0_rx_en);
cpdma_ctlr_int_ctrl(priv-dma, false);
return;
@@ -399,7 +426,10 @@ void cpsw_rx_handler(void *token, int len, int status)
skb_put(skb, len);
cpts_rx_timestamp(priv-cpts, skb);
skb-protocol = eth_type_trans(skb, ndev);
- netif_receive_skb(skb);
+ if (priv-data.disable_napi)
+ netif_rx(skb);
+ else
+ netif_receive_skb(skb);
priv-stats.rx_bytes += len;
priv-stats.rx_packets++;
skb = NULL;
@@ -431,6 +461,7 @@ static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
cpsw_disable_irq(priv);
napi_schedule(priv-napi);
}
+
return IRQ_HANDLED;
}
@@ -445,23 +476,104 @@ static inline int cpsw_get_slave_port(struct cpsw_priv
*priv, u32 slave_num)
static int cpsw_poll(struct napi_struct *napi, int budget)
{
struct cpsw_priv*priv = napi_to_priv(napi);
- int num_tx, num_rx;
+ int num_tx, num_rx, num_total_tx, num_total_rx;
+ int budget_left;
+
+ budget_left = budget;
- num_tx = cpdma_chan_process(priv-txch, 128);
- num_rx = cpdma_chan_process(priv-rxch, budget);
+ /* read status and throw away */
+ (void)__raw_readl(priv-wr_regs-c0_tx_stat);
+
+ /* handle all transmits */
+ num_total_tx = 0;
+ while (budget_left 0
+ (num_tx = cpdma_chan_process(priv-txch, 128)) 0) {
+ budget_left -= num_tx;
+ num_total_tx += num_tx;
+ }
- if (num_rx || num_tx)
- cpsw_dbg(priv, intr, poll %d rx, %d tx pkts\n,
-
Re: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb3
Hi Felipe,
On Mon, Jan 28, 2013 at 6:37 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
samsung_usbphy *sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from
external PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
I wonder if you really need this small function (likewise for
set_refclk_int()). They don't do much, so you could just inline them on
the only caller.
Created this just to keep symmetry, ;-)
will move this in the caller only.
you can have a patch before this series moving the refclk_int() to the
caller, then you will have symmetry ;-)
refclk_int() was rather slightly a big chunk :-(
as available in below patch as samsung_usb3_phy_set_refclk() :
[PATCH v4 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg13796.html
Will try to figure best possible way and amend.
--
Thanks Regards
Vivek
--
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] usb: phy: samsung: Enable runtime power management on samsung-usb3
On Mon, Jan 28, 2013 at 06:54:42PM +0530, Vivek Gautam wrote:
Hi Felipe,
On Mon, Jan 28, 2013 at 6:37 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
@@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
samsung_usbphy *sphy)
return reg;
}
-static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from
external PLL.
+ */
+static u32 samsung_usb3_phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
I wonder if you really need this small function (likewise for
set_refclk_int()). They don't do much, so you could just inline them on
the only caller.
Created this just to keep symmetry, ;-)
will move this in the caller only.
you can have a patch before this series moving the refclk_int() to the
caller, then you will have symmetry ;-)
refclk_int() was rather slightly a big chunk :-(
as available in below patch as samsung_usb3_phy_set_refclk() :
[PATCH v4 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg13796.html
Will try to figure best possible way and amend.
oh, right... In that case, keep the way it is. Ignore my comment ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] USB: dwc3: Adjust runtime pm the dwc3 driver to allow runtime suspend
Hi Felipe, On Mon, Jan 28, 2013 at 5:15 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Jan 28, 2013 at 05:12:26PM +0530, Vivek Gautam wrote: The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Note that this doesn't enable full runtime pm on the DWC3 device in that the port isn't put into a lower power mode when not used. However it does allow users of dwc3 (like dwc3-exynos) to do some amount of runtime power management. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3a4004a..59c2494 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -453,6 +453,7 @@ static int dwc3_probe(struct platform_device *pdev) if (of_get_property(node, tx-fifo-resize, NULL)) dwc-needs_fifo_resize = true; + pm_runtime_set_active(dev); this usage of pm_runtime_set_active() actually makes me a bit scared. At least OMAP starts with the device switched off, so this will probably break OMAP at least. I am fine with dropping pm_runtime_set_active(), actually thought to put device in active state so that as and when system finds it idle, force into suspend state. I fact should i drop pm_runtime_set_active() calls from other places too (xhci-plat, dwc3-exynos, and samsung-usb3 phy) and call get_sync() alongwith enable() ? OTOH, calling -runtime_resume() during probe() might not make that much sense after all, but the way OMAP is implemented, we won't get clocks turned on if this -runtime_resume() method isn't called. /me starts to wonder whether OMAP implementation is flakey and what should be done here... -- Thanks Regards Vivek -- 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-rc5
On Mon, Jan 28, 2013 at 17:48:49, Mohammed, Afzal wrote:
Hi Felipe,
On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote:
didn't help :-s
Hands up :(
Hi Felipe,
Could you please try with any of these options?
1. Change/add mem=512M (should be same value as u-boot printed RAM size) in your
bootargs?
Or
2. set fdt_high 0x (at u-boot prompt).
Thanks
AnilKumar
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v5] watchdog: introduce retu_wdt driver
Hi,
On Thu, Dec 27, 2012 at 10:58:29PM +0200, Aaro Koskinen wrote:
Introduce Retu watchdog driver.
Wim, any comments about this driver? Do you think it could be queued
for 3.9?
Thanks,
A.
Cc: linux-watch...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
v5: Deleted __dev* annotations.
Fixed a typo in Kconfig help text (Nokia 700 - 770).
For earlier history, see:
http://marc.info/?l=linux-kernelm=135325660302114w=2
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 178
+++
3 files changed, 191 insertions(+)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7f809fd..75afc76 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -364,6 +364,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate Retu watchdog
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (770, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 97bbdb3a..157bc61 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..f53615d
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,178 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(wdev-ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(wdev-ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
On Mon, Jan 28, 2013 at 3:56 AM, Mohammed, Afzal af...@ti.com wrote: Hi Rob, On Fri, Jan 25, 2013 at 20:22:55, Rob Clark wrote: On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal af...@ti.com wrote: It's not about being simple, but not doing the wrong way, here you are relying on a platform specific clock in a driver, think about the case where same IP is used on another platform. Either way it is not a good thing to handle platform specific details (about disp_clk) in driver. Right, but I was trying to understand what was the benefit that the added complexity is. I didn't realize on davinci that you are limited Here I am referring to usage of disp_clk, Driver is not supposed to do platform hacks - here you are trying to configure something (PLL) in your driver which is not part of LCDC IP. And LCDC IP is not aware of PLL which is a platform specific matter (existent only in AM335x), it is only aware of functional clock. You can set the rate on fck (functional clock) in AM335x using my patch, ARM: AM33XX: clock: SET_RATE_PARENT in lcd path, and there would not be any need for driver to be aware of platform specific PLL. right, but I think it would be better to just make another patch that changes tilcdc to just set rate on fck after that patch is merged. I mean, I'd rather have the driver at least usable on AM33xx until then, rather than broken for everyone. BR, -R + priv-clk = clk_get(dev-dev, fck); + priv-disp_clk = clk_get(dev-dev, dpll_disp_ck); at the moment all this discussion is a bit moot. I'd propose leaving the driver as it is for now, because that at least makes it useful on am33xx. And when CCF and davinci have the needed support in place, Let's forget about leveraging CCF in driver, but sane solution w.r.t PLL configuration would be to do as mentioned above. Regards Afzal -- 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-rc5
Hi, On Mon, Jan 28, 2013 at 03:40:09PM +0100, AnilKumar, Chimata wrote: On Mon, Jan 28, 2013 at 17:48:49, Mohammed, Afzal wrote: Hi Felipe, On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote: didn't help :-s Hands up :( Hi Felipe, Could you please try with any of these options? 1. Change/add mem=512M (should be same value as u-boot printed RAM size) in your bootargs? Or 2. set fdt_high 0x (at u-boot prompt). that helped, thank you :-) -- balbi signature.asc Description: Digital signature
[PATCH 0/2] ARM: dts: OMAP3: Add GPMC controller and NAND memory to Overo
Hello, This is more an RFC serie, as an issue is still unclear to me. Building on the work of Daniel Mack for the GPMC controller (staged in Tony's tree [1]), it was easy to add the GPMC controller to OMAP3. The issue comes from the Overo on-board NAND, as the amount of flash depends on the revision. Currently, partitions are handled in the board file using MTDPART_SIZ_FULL, but looking at the ofpart parser, the size given to the parser must be fixed. So how should we handle such case? Having several dtsi depending on the Overo's revision would be a mess to my sense, considering the non-conditional include inside the expansion boards' dts. Or would it make sense to extend the DT binding for partitions? This serie was tested on an Overo with 512MB of NAND. Best regards, Florian [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.9/gpmc Florian Vaussard (2): ARM: dts: OMAP3: Add GPMC controller ARM: dts: OMAP3: Add NAND memory for Overo products arch/arm/boot/dts/omap3-overo.dtsi | 49 arch/arm/boot/dts/omap3.dtsi | 11 2 files changed, 60 insertions(+), 0 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Add device-tree support for the GPMC controller on the OMAP3.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6c63118..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -403,5 +403,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: OMAP3: Add NAND memory for Overo products
Add device-tree support for the on-board NAND memory,
with corresponding partitions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo.dtsi | 49
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 81341fa..0efd6f3 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -33,6 +33,55 @@
};
};
+gpmc {
+ ranges = 0 0 0x3000 0x0004; /* CS0: NAND */
+
+ nand@0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = sw;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,we-off = 30;
+ gpmc,oe-off = 48;
+ gpmc,access = 54;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,wr-access = 30;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ xloader@0 {
+ reg = 0x 0x0008;
+ };
+
+ uboot@8 {
+ reg = 0x0008 0x001c;
+ };
+
+ ubootenv@24 {
+ reg = 0x0024 0x0004;
+ };
+
+ linux@28 {
+ reg = 0x0028 0x0040;
+ };
+
+ rootfs@68 {
+ reg = 0x0068 0x1f98; /* 500 MB */
+ };
+ };
+};
+
i2c1 {
clock-frequency = 260;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 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
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.
On Jan 28, 2013, at 8:24 PM, Richard Cochran wrote:
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.
PG2.0 fixed a number of silicon bugs. The old driver hard locked, since
it didn't follow the TRM described interrupt handling.
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).
Speaking of which, I'm probably the original developer of the fec driver.
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.
Not every device can be conveniently be made to shut up so that NAPI processing
can take place at a later time.
The NAPI case is still broken in this driver, which OOPs under load.
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.)
Those are the real register names in the updated TRM.
+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.
dido.
Thanks,
Richard
Regards
-- Pantelis
--
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 00/15] OMAP SHAM AES Crypto Updates
On Thu, Jan 17, 2013 at 03:27:28PM -0700, Mark A. Greer wrote: On Thu, Jan 17, 2013 at 07:13:36PM +, Paul Walmsley wrote: Hi Mark, Hi Paul. Hi again, Paul. Sorry for the delay, I've been under the weather. I regret the delay, On Tue, 8 Jan 2013, Mark A. Greer wrote: On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote: What do you think about adding an am35xx_es11plus_hwmod_ocp_ifs[] array to omap_hwmod_3xxx_data.c for these secure hwmods? That carries the implicit and possibly wrong assumption that it's likely to be ES1.0 devices that are missing the SHAM/AES, but it seems unlikely that TI would have multiple silicon revs running around claiming to be ES1.1? Or maybe I'm just being naïve. Something like that makes sense to me. I'll re-read my email, etc. and see if I can find something to help us figure it out. I couldn't find any information that helped with this so AFAIK there is no good way to tell if a particular am35xx has the crypto hardware available or not. At this point, I vote for moving 'omap3xxx_l4_core__sham' and 'omap3xxx_l4_core__aes' from omap3xxx_gp_hwmod_ocp_ifs[] and putting them in omap34xx_hwmod_ocp_ifs[] and omap36xx_hwmod_ocp_ifs[]. That should be safe in general and if someone with an am35xx wants to use those modules, they can edit am35xx_hwmod_ocp_ifs[] locally. What do you think? -- 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 v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter mpor...@ti.com wrote:
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 314
++--
include/linux/platform_data/edma.h |1 +
2 files changed, 306 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2dce245..beeb1d2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot = 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
I'm sorry I didn't get why you couldn't use of_property_read_u8_array() ?
The similar comment to u16 and so on.
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop-value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) prop-length)
+ return -EOVERFLOW;
+
+ val = prop-value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16
*out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop-value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) prop-length)
+ return -EOVERFLOW;
+
+ val = prop-value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ ti,edma-xbar-event-map,
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] 2;
+ offset = 2;
+ mux = readl((void *)((u32)xbar + offset));
+ mux = ~(0xff shift);
+ mux |= xbar_chans[i][0] shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata-xbar_chans = xbar_chans;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ const s8
Re: [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter mpor...@ti.com wrote:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Does it mean the introduced function is kinda temporary?
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
--
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 v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Monday 28 January 2013, Andy Shevchenko wrote: On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter mpor...@ti.com wrote: Adds a dma_request_slave_channel_compat() wrapper which accepts both the arguments from dma_request_channel() and dma_request_slave_channel(). Based on whether the driver is instantiated via DT, the appropriate channel request call will be made. This allows for a much cleaner migration of drivers to the dmaengine DT API as platforms continue to be mixed between those that boot using DT and those that do not. Does it mean the introduced function is kinda temporary? Some drivers can very likely get converted to use only dma_request_slave_channel() in the long run, when all the platforms using those drivers have been converted to provide the channels using device tree. However, for drivers that are used on legacy platforms without DT support, we may still need something like this function in the long run. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 108 +++-
include/linux/platform_data/cpsw.h |1 +
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods: Must be cpgmac0
- no_bd_ram: Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..dee6951 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include linux/of.h
#include linux/of_net.h
#include linux/of_device.h
+#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
@@ -72,6 +73,11 @@ do {
\
dev_notice(priv-dev, format, ## __VA_ARGS__); \
} while (0)
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
+#define VLAN_SUPPORT
+#define CPSW_VLAN_AWARE_MODE
+#endif
+
#define ALE_ALL_PORTS 0x7
#define CPSW_MAJOR_VERSION(reg)(reg 8 0x7)
@@ -118,6 +124,14 @@ do {
\
#define TX_PRIORITY_MAPPING0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#ifdef CPSW_VLAN_AWARE_MODE
+#define CPSW_VLAN_AWAREBIT(1)
+#define CPSW_ALE_VLAN_AWARE1
+#else
+#define CPSW_VLAN_AWARE0x0
+#define CPSW_ALE_VLAN_AWARE0
+#endif
+
#define cpsw_enable_irq(priv) \
do {\
u32 i; \
@@ -607,14 +621,44 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
}
}
+#ifdef VLAN_SUPPORT
+static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
+{
+ writel(priv-data.default_vlan, priv-host_port_regs-port_vlan);
+ if (priv-version == CPSW_VERSION_1) {
+ slave_write(priv-slaves[0], priv-data.default_vlan,
+ CPSW1_PORT_VLAN);
+ slave_write(priv-slaves[1], priv-data.default_vlan,
+ CPSW1_PORT_VLAN);
+ } else {
+ slave_write(priv-slaves[0], priv-data.default_vlan,
+ CPSW2_PORT_VLAN);
+ slave_write(priv-slaves[1], priv-data.default_vlan,
+ CPSW2_PORT_VLAN);
+ }
+ cpsw_ale_add_vlan(priv-ale, priv-data.default_vlan,
+ ALE_ALL_PORTS priv-host_port,
+ ALE_ALL_PORTS priv-host_port,
+ ALE_ALL_PORTS priv-host_port, 0);
+}
+#else
+#define cpsw_add_default_vlan(priv)
+#endif
+
static void cpsw_init_host_port(struct cpsw_priv *priv)
{
+ u32 control_reg;
+
/* soft reset the controller and initialize ale */
soft_reset(cpsw, priv-regs-soft_reset);
cpsw_ale_start(priv-ale);
/* switch to vlan unaware mode */
- cpsw_ale_control_set(priv-ale, 0, ALE_VLAN_AWARE, 0);
+ cpsw_ale_control_set(priv-ale, priv-host_port, ALE_VLAN_AWARE,
+CPSW_ALE_VLAN_AWARE);
+ control_reg = readl(priv-regs-control);
+ control_reg |= CPSW_VLAN_AWARE;
+ writel(control_reg, priv-regs-control);
/* setup host port priority mapping */
__raw_writel(CPDMA_TX_PRIORITY_MAP,
@@ -650,6 +694,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpsw_init_host_port(priv);
for_each_slave(priv, cpsw_slave_open, priv);
+ /* Add default VLAN */
+ cpsw_add_default_vlan(priv);
+
/* setup tx dma to fixed prio and zero offset */
cpdma_control_set(priv-dma, CPDMA_TX_PRIO_FIXED, 1);
cpdma_control_set(priv-dma, CPDMA_RX_BUFFER_OFFSET, 0);
@@ -933,6 +980,54 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
}
#endif
+#ifdef VLAN_SUPPORT
+
+static inline void cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
+ unsigned short vid)
+{
+ cpsw_ale_add_vlan(priv-ale, vid, ALE_ALL_PORTS priv-host_port,
+ 0, ALE_ALL_PORTS priv-host_port,
+ (BIT(1) | BIT(2)) priv-host_port);
+ cpsw_ale_vlan_add_ucast(priv-ale, priv-mac_addr,
+ priv-host_port, 0, vid);
+
[PATCH 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
Add helper functions for VLAN ALE implementations for Add, Delete
Dump VLAN related ALE entries
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw_ale.c | 172 ++--
drivers/net/ethernet/ti/cpsw_ale.h | 11 +++
2 files changed, 178 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
b/drivers/net/ethernet/ti/cpsw_ale.c
index 0e9ccc2..0d7a60a 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -148,7 +148,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx,
u32 *ale_entry)
return idx;
}
-static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
+int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
@@ -160,6 +160,8 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
type = cpsw_ale_get_entry_type(ale_entry);
if (type != ALE_TYPE_ADDR type != ALE_TYPE_VLAN_ADDR)
continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) != vid)
+ continue;
cpsw_ale_get_addr(ale_entry, entry_addr);
if (memcmp(entry_addr, addr, 6) == 0)
return idx;
@@ -167,6 +169,22 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
return -ENOENT;
}
+int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS];
+ int type, idx;
+
+ for (idx = 0; idx ale-params.ale_entries; idx++) {
+ cpsw_ale_read(ale, idx, ale_entry);
+ type = cpsw_ale_get_entry_type(ale_entry);
+ if (type != ALE_TYPE_VLAN)
+ continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) == vid)
+ return idx;
+ }
+ return -ENOENT;
+}
+
static int cpsw_ale_match_free(struct cpsw_ale *ale)
{
u32 ale_entry[ALE_ENTRY_WORDS];
@@ -286,7 +304,7 @@ int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int
port, int flags)
cpsw_ale_set_blocked(ale_entry, (flags ALE_BLOCKED) ? 1 : 0);
cpsw_ale_set_port_num(ale_entry, port);
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, 0);
if (idx 0)
idx = cpsw_ale_match_free(ale);
if (idx 0)
@@ -303,7 +321,7 @@ int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int
port)
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, 0);
if (idx 0)
return -ENOENT;
@@ -318,7 +336,7 @@ int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int
port_mask,
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx, mask;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, 0);
if (idx = 0)
cpsw_ale_read(ale, idx, ale_entry);
@@ -347,7 +365,151 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr,
int port_mask)
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, 0);
+ if (idx 0)
+ return -EINVAL;
+
+ cpsw_ale_read(ale, idx, ale_entry);
+
+ if (port_mask)
+ cpsw_ale_set_port_mask(ale_entry, port_mask);
+ else
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_FREE);
+
+ cpsw_ale_write(ale, idx, ale_entry);
+ return 0;
+}
+
+int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
+ int reg_mcast, int unreg_mcast)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
+ int idx;
+
+ idx = cpsw_ale_match_vlan(ale, vid);
+ if (idx = 0)
+ cpsw_ale_read(ale, idx, ale_entry);
+
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+
+ cpsw_ale_set_vlan_untag_force(ale_entry, untag);
+ cpsw_ale_set_vlan_reg_mcast(ale_entry, reg_mcast);
+ cpsw_ale_set_vlan_unreg_mcast(ale_entry, unreg_mcast);
+ cpsw_ale_set_vlan_member_list(ale_entry, port);
+
+ if (idx 0)
+ idx = cpsw_ale_match_free(ale);
+ if (idx 0)
+ idx = cpsw_ale_find_ageable(ale);
+ if (idx 0)
+ return -ENOMEM;
+
+ cpsw_ale_write(ale, idx, ale_entry);
+ return 0;
+}
+
+int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
+ int idx, mask;
+
+ idx = cpsw_ale_match_vlan(ale, vid);
+ if (idx 0)
+ return -ENOENT;
+
+ cpsw_ale_read(ale, idx, ale_entry);
+
+ mask = cpsw_ale_get_vlan_member_list(ale_entry);
+ mask = ~port;
+ if
[PATCH 0/2] Add CPSW VLAN Support
CPSW is capable of filtering VLAN packets in hardware. This patch series implements VLAN support to CPSW driver. This patch series is tested on net-next with AM335x EVM with ping test. Mugunthan V N (2): drivers: net: cpsw: Add helper functions for VLAN ALE implementation drivers: net:ethernet: cpsw: add support for VLAN Documentation/devicetree/bindings/net/cpsw.txt |2 + drivers/net/ethernet/ti/cpsw.c | 108 ++- drivers/net/ethernet/ti/cpsw_ale.c | 172 +++- drivers/net/ethernet/ti/cpsw_ale.h | 11 ++ include/linux/platform_data/cpsw.h |1 + 5 files changed, 288 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 29/32] usb: gadget: pxa27x_udc: let udc-core manage gadget-dev
Felipe Balbi ba...@ti.com writes: By simply setting a flag, we can drop some boilerplate code. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/gadget/pxa27x_udc.c | 9 + Acked-by: Robert Jarzmik robert.jarz...@free.fr And I tested also your patch and it works in my environment. For next patches I'd like to be CCed for pxa27x_udc stuff as I'm maintaining that one since its beginning (and yes, I know, I didn't put that in MAINTAINERS ...). Cheers. -- Robert -- 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:
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 108
+++-
include/linux/platform_data/cpsw.h |1 +
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be cpgmac0
- no_bd_ram : Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..dee6951 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include linux/of.h
#include linux/of_net.h
#include linux/of_device.h
+#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
@@ -72,6 +73,11 @@ do {
\
dev_notice(priv-dev, format, ## __VA_ARGS__); \
} while (0)
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
use IS_ENABLED() instead.
+#define VLAN_SUPPORT
+#define CPSW_VLAN_AWARE_MODE
+#endif
+
#define ALE_ALL_PORTS0x7
#define CPSW_MAJOR_VERSION(reg) (reg 8 0x7)
@@ -118,6 +124,14 @@ do {
\
#define TX_PRIORITY_MAPPING 0x33221100
#define CPDMA_TX_PRIORITY_MAP0x76543210
+#ifdef CPSW_VLAN_AWARE_MODE
+#define CPSW_VLAN_AWARE BIT(1)
+#define CPSW_ALE_VLAN_AWARE 1
+#else
+#define CPSW_VLAN_AWARE 0x0
+#define CPSW_ALE_VLAN_AWARE 0
+#endif
you should really figure out a way of doing runtime detection for this.
Depending on driver recompilation just to enable/disable VLAN support
will be quite boring.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] cpsw: Fix interrupt storm among other things
Pantelis == Pantelis Antoniou pa...@antoniou-consulting.com writes: 'among other things' is not a very descriptive commit message. Pantelis Fix interrupt storm on bone A4 cause by non-by-the-book Pantelis interrupt handling. While at it, added a non-NAPI mode Pantelis (which is easier to debug), plus some general fixes. 'bone A4' is also not very descriptive. There also was an A4 revision of the old beaglebone. I guess you're instead referring to a new die revision? What is the impact of this change on earlier devices? Pantelis +++ b/Documentation/devicetree/bindings/net/cpsw.txt Pantelis @@ -20,6 +20,7 @@ Required properties: Pantelis - cpts_clock_shift : Denominator to convert input clock ticks into nanoseconds Pantelis - phy_id: Specifies slave phy id Pantelis - mac-address : Specifies slave MAC address Pantelis +- disable-napi : Disables driver NAPI napi is not a hardware feature, so it doesn't belong here (if anything, it should be linux,disable-napi). -- Bye, Peter Korsgaard -- 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] mmc: omap_hsmmc: MAINTAINERS: change omap_hsmmc maintenance to orphan
Hi, On Wed, Jan 16 2013, Venkatraman S wrote: The specified email id is no longer in service. Update the OMAP HSMMC entry from the MAINTAINERS file as I will no longer be able to maintain this driver. Signed-off-by: Venkatraman S svenk...@gmail.com --- MAINTAINERS |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index cd5b31f..95778e1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5499,10 +5499,8 @@ S: Maintained F: drivers/mmc/host/omap.c OMAP HS MMC SUPPORT -M: Venkatraman S svenk...@ti.com -L: linux-...@vger.kernel.org L: linux-omap@vger.kernel.org -S: Maintained +S: Orphan F: drivers/mmc/host/omap_hsmmc.c OMAP RANDOM NUMBER GENERATOR SUPPORT Thanks for your work on omap_hsmmc, Venkat! Is anyone else interested in taking up maintenance of omap_hsmmc? - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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 1/29/2013 2:14 AM, Felipe Balbi wrote:
On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 108 +++-
include/linux/platform_data/cpsw.h |1 +
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be cpgmac0
- no_bd_ram : Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..dee6951 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include linux/of.h
#include linux/of_net.h
#include linux/of_device.h
+#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
@@ -72,6 +73,11 @@ do {\
dev_notice(priv-dev, format, ## __VA_ARGS__); \
} while (0)
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
use IS_ENABLED() instead.
Will change this in next patch version.
+#define VLAN_SUPPORT
+#define CPSW_VLAN_AWARE_MODE
+#endif
+
#define ALE_ALL_PORTS 0x7
#define CPSW_MAJOR_VERSION(reg) (reg 8 0x7)
@@ -118,6 +124,14 @@ do {
\
#define TX_PRIORITY_MAPPING 0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#ifdef CPSW_VLAN_AWARE_MODE
+#define CPSW_VLAN_AWAREBIT(1)
+#define CPSW_ALE_VLAN_AWARE1
+#else
+#define CPSW_VLAN_AWARE0x0
+#define CPSW_ALE_VLAN_AWARE0
+#endif
you should really figure out a way of doing runtime detection for this.
Depending on driver recompilation just to enable/disable VLAN support
will be quite boring.
I am not able to find a way to know whether stack is compiled with VLAN
support or not
without using VLAN_SUPPORT compiler option. Only way is to hack
cpsw_ndo_vlan_rx_add_vid
and know whether stack has VLAN capability or not which is not advisable.
Regards
Mugunthan V N
--
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 6/9] ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the WKUP-M3 hwmod data to reflect the same.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 40bfde3..9e34d4c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -269,6 +269,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_WKUP_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_WKUP_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
This is necessary to ensure that macros declared here can be reused from assembly files. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- v2: No change arch/arm/mach-omap2/cm33xx.h | 2 ++ arch/arm/mach-omap2/prm33xx.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 8009e13..64f4baf 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -376,6 +376,7 @@ #define AM33XX_CM_CEFUSE_CEFUSE_CLKCTRL AM33XX_CM_REGADDR(AM33XX_CM_CEFUSE_MOD, 0x0020) +#ifndef __ASSEMBLER__ extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs); @@ -412,4 +413,5 @@ static inline int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, } #endif +#endif /* ASSEMBLER */ #endif diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h index 3f25c56..1c40373 100644 --- a/arch/arm/mach-omap2/prm33xx.h +++ b/arch/arm/mach-omap2/prm33xx.h @@ -117,6 +117,7 @@ #define AM33XX_PM_CEFUSE_PWRSTST_OFFSET0x0004 #define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) +#ifndef __ASSEMBLER__ extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); @@ -126,4 +127,5 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs, u16 rstst_offs); +#endif /* ASSEMBLER */ #endif -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
Hi, The following patches were earlier posted as part the AM33XX suspend-resume support series [1]. Based on the suggestion from Santosh Shilimkar santosh.shilim...@ti.com i have split out the changes which update the various data files related to AM33XX support. This version addresses the comments received from Sergei Shtylyov and Peter Korsgaard on the earlier patchset [2]. These patches apply on top of v3.8-rc5 Regards, Vaibhav [1] http://marc.info/?l=linux-arm-kernelm=135698501821074w=2 [2] http://marc.info/?l=linux-omapm=135849360005657w=2 Vaibhav Bedia (9): ARM: OMAP2+: AM33XX: CM: Get rid of unnecessary header inclusions ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit ARM: OMAP2+: AM33XX: Update the hardreset API ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3 ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs arch/arm/boot/dts/am33xx.dtsi | 14 + arch/arm/mach-omap2/cm33xx.h | 9 ++ arch/arm/mach-omap2/control.c | 20 arch/arm/mach-omap2/control.h | 41 arch/arm/mach-omap2/omap_hwmod.c | 5 +-- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 50 +- arch/arm/mach-omap2/prm33xx.c | 11 --- arch/arm/mach-omap2/prm33xx.h | 4 ++- 8 files changed, 118 insertions(+), 36 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/9] ARM: OMAP2+: AM33XX: CM: Get rid of unnecessary header inclusions
cm33xx.h unnecessarily includes a lot of header files. Get rid of these and directly include iomap.h which is needed to keep things compiling. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- v2: Reword the changelog arch/arm/mach-omap2/cm33xx.h | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 5fa0b62..8009e13 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -17,16 +17,11 @@ #ifndef __ARCH_ARM_MACH_OMAP2_CM_33XX_H #define __ARCH_ARM_MACH_OMAP2_CM_33XX_H -#include linux/delay.h -#include linux/errno.h -#include linux/err.h -#include linux/io.h - #include common.h #include cm.h #include cm-regbits-33xx.h -#include cm33xx.h +#include iomap.h /* CM base address */ #define AM33XX_CM_BASE 0x44e0 -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/9] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v2: Drop unnecessary parens
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 8280f11..94254e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1823,6 +1823,7 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
.class = am33xx_tptc_hwmod_class,
.clkdm_name = l3_clkdm,
.mpu_irqs = am33xx_tptc0_irqs,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
Since AM33XX supports only DT-boot, this is needed
for the appropriate device nodes to be created.
Note: OCMC RAM is part of the PER power domain and supports
retention. The assembly code for low power entry/exit will
run from OCMC RAM. To ensure that the OMAP PM code does not
attempt to disable the clock to OCMC RAM as part of the
suspend process add the no_idle_on_suspend flag.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v2: Add reg property
arch/arm/boot/dts/am33xx.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..423f898 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,19 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ ocmcram: ocmcram@4030 {
+ compatible = ti,ocmcram;
+ reg = 0x4030 0x1;
+ ti,hwmods = ocmcram;
+ ti,no_idle_on_suspend;
+ };
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = ti,wkup_m3;
+ reg = 0x44d0 0x4000/* M3 UMEM */
+ 0x44d8 0x2000; /* M3 DMEM */
+ ti,hwmods = wkup_m3;
+ };
};
};
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/9] ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.
CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
accessing the wrong memory address for idle and standby
operations. Fix this by removing the ADDR_TYPE_RT flag from
the 1st memory region in CPGMAC0 hwmod entry.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 94254e8..40bfde3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2496,7 +2496,6 @@ static struct omap_hwmod_addr_space
am33xx_cpgmac0_addr_space[] = {
{
.pa_start = 0x4a10,
.pa_end = 0x4a10 + SZ_2K - 1,
- .flags = ADDR_TYPE_RT,
},
/* cpsw wr */
{
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/9] ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
OCMC RAM lies in the PER power domain and this memory
support retention.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 47 +-
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..8280f11 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -414,7 +414,6 @@ static struct omap_hwmod am33xx_adc_tsc_hwmod = {
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
- *- ocmc ram
*- ocp watch point
*- aes0
*- sha0
@@ -481,25 +480,6 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
},
};
-/* ocmcram */
-static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
- .name = ocmcram,
-};
-
-static struct omap_hwmod am33xx_ocmcram_hwmod = {
- .name = ocmcram,
- .class = am33xx_ocmcram_hwmod_class,
- .clkdm_name = l3_clkdm,
- .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
- .main_clk = l3_gclk,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocpwp */
static struct omap_hwmod_class am33xx_ocpwp_hwmod_class = {
.name = ocpwp,
@@ -570,6 +550,25 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/* ocmcram */
+static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
+ .name = ocmcram,
+};
+
+static struct omap_hwmod am33xx_ocmcram_hwmod = {
+ .name = ocmcram,
+ .class = am33xx_ocmcram_hwmod_class,
+ .clkdm_name = l3_clkdm,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .main_clk = l3_gclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* 'smartreflex' class */
static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
.name = smartreflex,
@@ -3328,6 +3327,13 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
.flags = OCPIF_SWSUP_IDLE,
};
+/* l3 main - ocmc */
+static struct omap_hwmod_ocp_if am33xx_l3_main__ocmc = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am33xx_ocmcram_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_fw__emif_fw,
am33xx_l3_main__emif,
@@ -3398,6 +3404,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l3_main__tptc0,
am33xx_l3_main__tptc1,
am33xx_l3_main__tptc2,
+ am33xx_l3_main__ocmc,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
am33xx_cpgmac0__mdio,
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] ARM: OMAP2+: AM33XX: Update the hardreset API
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the hardreset API to ensure that the reset line properly
deasserted.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v2: No change
arch/arm/mach-omap2/omap_hwmod.c | 5 +
arch/arm/mach-omap2/prm33xx.c| 11 +++
arch/arm/mach-omap2/prm33xx.h| 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..6549439 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3041,11 +3041,8 @@ static int _am33xx_assert_hardreset(struct omap_hwmod
*oh,
static int _am33xx_deassert_hardreset(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri)
{
- if (ohri-st_shift)
- pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4 does not
support st_shift\n,
- oh-name, ohri-name);
-
return am33xx_prm_deassert_hardreset(ohri-rst_shift,
+ ohri-st_shift,
oh-clkdm-pwrdm.ptr-prcm_offs,
oh-prcm.omap4.rstctrl_offs,
oh-prcm.omap4.rstst_offs);
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 1ac7388..44c0d72 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -110,11 +110,11 @@ int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16
rstctrl_offs)
* -EINVAL upon an argument error, -EEXIST if the submodule was already out
* of reset, or -EBUSY if the submodule did not exit reset promptly.
*/
-int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs)
{
int c;
- u32 mask = 1 shift;
+ u32 mask = 1 st_shift;
/* Check the current status to avoid de-asserting the line twice */
if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
@@ -122,11 +122,14 @@ int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
/* Clear the reset status by writing 1 to the status bit */
am33xx_prm_rmw_reg_bits(0x, mask, inst, rstst_offs);
+
/* de-assert the reset control line */
+ mask = 1 shift;
+
am33xx_prm_rmw_reg_bits(mask, 0, inst, rstctrl_offs);
- /* wait the status to be set */
- omap_test_timeout(am33xx_prm_is_hardreset_asserted(shift, inst,
+ /* wait the status to be set */
+ omap_test_timeout(am33xx_prm_is_hardreset_asserted(st_shift, inst,
rstst_offs),
MAX_MODULE_HARDRESET_WAIT, c);
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 1c40373..9b9918d 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -125,7 +125,7 @@ extern void am33xx_prm_global_warm_sw_reset(void);
extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst,
u16 rstctrl_offs);
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
-extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+extern int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
#endif /* ASSEMBLER */
#endif
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 9/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
Add minimal APIs for writing to the IPC and the M3_TXEV registers
in the Control module. These will be used in a subsequent patch which
adds suspend-resume support for AM33XX.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v2: No change
arch/arm/mach-omap2/control.c | 20
arch/arm/mach-omap2/control.h | 41 +
2 files changed, 61 insertions(+)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 2adb268..c5d54ae 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -604,3 +604,23 @@ int omap3_ctrl_save_padconf(void)
}
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
+
+#if defined(CONFIG_SOC_AM33XX) defined(CONFIG_PM)
+void am33xx_txev_eoi(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ACK, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_txev_enable(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ENABLE, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data)
+{
+ omap_ctrl_writel(data-resume_addr, AM33XX_CONTROL_IPC_MSG_REG0);
+ omap_ctrl_writel(data-sleep_mode, AM33XX_CONTROL_IPC_MSG_REG1);
+ omap_ctrl_writel(data-param1, AM33XX_CONTROL_IPC_MSG_REG2);
+ omap_ctrl_writel(data-param2, AM33XX_CONTROL_IPC_MSG_REG3);
+}
+#endif /* CONFIG_SOC_AM33XX CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..cb85f0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,37 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22)
+#define AM33XX_DDR_IO_CTRL 0x0E04
+#define AM33XX_VTP0_CTRL_REG 0x0E0C
+
+/* AM33XX VTP0_CTRL_REG bits */
+#define AM33XX_VTP_CTRL_START_EN (1 0)
+#define AM33XX_VTP_CTRL_LOCK_EN(1 4)
+#define AM33XX_VTP_CTRL_READY (1 5)
+#define AM33XX_VTP_CTRL_ENABLE (1 6)
+
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI 0x1324
+
+#define AM33XX_M3_TXEV_ACK (0x1 0)
+#define AM33XX_M3_TXEV_ENABLE (0x0 0)
+
+/* AM33XX IPC message registers */
+#define AM33XX_CONTROL_IPC_MSG_REG00x1328
+#define AM33XX_CONTROL_IPC_MSG_REG10x132C
+#define AM33XX_CONTROL_IPC_MSG_REG20x1330
+#define AM33XX_CONTROL_IPC_MSG_REG30x1334
+#define AM33XX_CONTROL_IPC_MSG_REG40x1338
+#define AM33XX_CONTROL_IPC_MSG_REG50x133C
+#define AM33XX_CONTROL_IPC_MSG_REG60x1340
+#define AM33XX_CONTROL_IPC_MSG_REG70x1344
+
+#define AM33XX_DDR_CMD0_IOCTRL 0x1404
+#define AM33XX_DDR_CMD1_IOCTRL 0x1408
+#define AM33XX_DDR_CMD2_IOCTRL 0x140C
+#define AM33XX_DDR_DATA0_IOCTRL0x1440
+#define AM33XX_DDR_DATA1_IOCTRL0x1444
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
@@ -417,6 +448,16 @@ extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
extern void omap2_set_globals_control(void __iomem *ctrl,
void __iomem *ctrl_pad);
+struct am33xx_ipc_data {
+ u32 resume_addr;
+ u32 param1;
+ u32 param2;
+ u32 sleep_mode;
+};
+extern void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data);
+extern void am33xx_txev_eoi(void);
+extern void am33xx_txev_enable(void);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
--
1.8.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 2/2] drivers: net:ethernet: cpsw: add support for VLAN
Hi,
On Tue, Jan 29, 2013 at 10:35:05AM +0530, Mugunthan V N wrote:
On 1/29/2013 2:14 AM, Felipe Balbi wrote:
On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 108
+++-
include/linux/platform_data/cpsw.h |1 +
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be cpgmac0
- no_bd_ram : Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..dee6951 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include linux/of.h
#include linux/of_net.h
#include linux/of_device.h
+#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
@@ -72,6 +73,11 @@ do {
\
dev_notice(priv-dev, format, ## __VA_ARGS__); \
} while (0)
+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
use IS_ENABLED() instead.
Will change this in next patch version.
+#define VLAN_SUPPORT
+#define CPSW_VLAN_AWARE_MODE
+#endif
+
#define ALE_ALL_PORTS 0x7
#define CPSW_MAJOR_VERSION(reg) (reg 8 0x7)
@@ -118,6 +124,14 @@ do {
\
#define TX_PRIORITY_MAPPING 0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#ifdef CPSW_VLAN_AWARE_MODE
+#define CPSW_VLAN_AWAREBIT(1)
+#define CPSW_ALE_VLAN_AWARE1
+#else
+#define CPSW_VLAN_AWARE0x0
+#define CPSW_ALE_VLAN_AWARE0
+#endif
you should really figure out a way of doing runtime detection for this.
Depending on driver recompilation just to enable/disable VLAN support
will be quite boring.
I am not able to find a way to know whether stack is compiled with
VLAN support or not
without using VLAN_SUPPORT compiler option. Only way is to hack
cpsw_ndo_vlan_rx_add_vid
and know whether stack has VLAN capability or not which is not advisable.
you could use a module parameter or pass data to the driver. In any
case, relying completely on compile-time choices isn't very nice.
--
balbi
signature.asc
Description: Digital signature
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
