Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On Fri, Dec 13, 2013 at 4:45 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
That's great, and I fully support that. This also calls for refactoring
the V4L2 DT bindings and support code to share them with display devices.
A bikeshedding question is where to put the common code.
Thanks very much for review!
I know drivers/video is in practice fbdev, but drivers/video (the
words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev and
generic video in a single directory. We could use a subdirectory of
drivers/video.
Or reshuffle the various graphics/video/fb/console directories (more
bikeshedding). With git it's not that painful.
Frame buffer devices ended up in drivers/video because at that time, graphics
cards were called video cards. Moving video only entered the picture later.
drivers/fb/ (currently most of drivers/video/)
drivers/console/ (currently drivers/video/console/)
...
Or should fb be under gpu?
What about drivers/media? Video and audio are multi-media, too...
Baah, bad idea... too much bikeshedding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 05/26] ARM: OMAP2+: add omapdss_init_of()
On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote: On 2013-12-12 01:10, Laurent Pinchart wrote: Hi Tomi, On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: omapdss driver uses a omapdss platform device to pass platform specific function pointers and DSS hardware version from the arch code to the driver. This device is needed also when booting with DT. This patch adds omapdss_init_of() function, called from board-generic at init time, which creates the omapdss device. Is this a temporary solution that you plan to later replace with DT-only device instantiation ? It's a long term task to remove the virtual omapdss device. Removing the platform data that we pass has been very difficult. Even if we remove the platform data, what would be the right place to register the drm, fb and vout devices? We need to make sure their drivers are probed only after omapdss is initialised. For example, we need to get the OMAP revision to know which OMAP DSS hardware we have. We can't get that information from the DSS hardware (thank you, HW designers! ;). Another is DSI pin muxing. I think we need a new pinmuxing driver for that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is very simple, but the register fields are varying lengths and at varying positions, so pinmux-single doesn't work for it. I have seen other OMAP drivers passing control module register info to their DT node. Instead of having a pinmux driver for a single register, we might want to consider just passing the control module register, and take care of the reg fields and masks in the OMAP DSI driver itself. The parsing of the DSI pins from DT, however, can be kept generic. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
On 2013-12-13 10:32, Archit Taneja wrote: On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote: On 2013-12-12 01:10, Laurent Pinchart wrote: Hi Tomi, On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: omapdss driver uses a omapdss platform device to pass platform specific function pointers and DSS hardware version from the arch code to the driver. This device is needed also when booting with DT. This patch adds omapdss_init_of() function, called from board-generic at init time, which creates the omapdss device. Is this a temporary solution that you plan to later replace with DT-only device instantiation ? It's a long term task to remove the virtual omapdss device. Removing the platform data that we pass has been very difficult. Even if we remove the platform data, what would be the right place to register the drm, fb and vout devices? We need to make sure their drivers are probed only after omapdss is initialised. That's the same issue as we have already, so removing omapdss doesn't affect that. I don't think we have any good way to ensure those devices are not probed before omapdss. We just have to manage the case that omapdss has not been probed yet, by checking if omapdss is there and if not, return EPROBE_DEFER. For example, we need to get the OMAP revision to know which OMAP DSS hardware we have. We can't get that information from the DSS hardware (thank you, HW designers! ;). Another is DSI pin muxing. I think we need a new pinmuxing driver for that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is very simple, but the register fields are varying lengths and at varying positions, so pinmux-single doesn't work for it. I have seen other OMAP drivers passing control module register info to their DT node. Instead of having a pinmux driver for a single register, we might want to consider just passing the control module register, and take care of the reg fields and masks in the OMAP DSI driver itself. Yes, that's also one option. Quite ugly, though =). Tomi signature.asc Description: OpenPGP digital signature
[net PATCH v2 1/1] drivers: net : cpsw: pass proper device name while requesting irq
From: George Cherian george.cher...@ti.com
During checking the interrupts with cat /proc/interrupts, it is showing
device name as (null), this change was done with commit id aa1a15e2d where
request_irq is changed to devm_request_irq also changing the irq name from
platform device name to net device name, but the net device is not
registered at this point with the network frame work, so devm_request_irq
is called with device name as NULL, by which it is showed as (null) in
cat /proc/interrupts. So this patch moved the devm_request_irq after
the net device register so that the device name shows as eth*.
Previous to this patch
root@am335x-evm:~# cat /proc/interrupts
CPU0
28: 2265 INTC 12 edma
30: 80 INTC 14 edma_error
44:345 INTC 28 mmc1
56: 0 INTC 40 (null)
57: 1794 INTC 41 (null)
58: 7 INTC 42 (null)
59: 0 INTC 43 (null)
With this patch
root@am335x-evm:~# cat /proc/interrupts
CPU0
28: 2254 INTC 12 edma
30: 69 INTC 14 edma_error
44:324 INTC 28 mmc1
56: 0 INTC 40 eth0
57:271 INTC 41 eth0
58: 7 INTC 42 eth0
59: 0 INTC 43 eth0
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Changes from Initial version
* Changed the commit message to hold more details of the commit changes
---
drivers/net/ethernet/ti/cpsw.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 5120d9c..d80dfce 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2103,19 +2103,6 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
- while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
- for (i = res-start; i = res-end; i++) {
- if (devm_request_irq(pdev-dev, i, cpsw_interrupt, 0,
-dev_name(priv-dev), priv)) {
- dev_err(priv-dev, error attaching irq\n);
- goto clean_ale_ret;
- }
- priv-irqs_table[k] = i;
- priv-num_irqs = k + 1;
- }
- k++;
- }
-
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
ndev-netdev_ops = cpsw_netdev_ops;
@@ -2131,6 +2118,19 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
+ while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (devm_request_irq(pdev-dev, i, cpsw_interrupt, 0,
+dev_name(priv-dev), priv)) {
+ dev_err(priv-dev, error attaching irq\n);
+ goto clean_ale_ret;
+ }
+ priv-irqs_table[k] = i;
+ priv-num_irqs = k + 1;
+ }
+ k++;
+ }
+
if (cpts_register(pdev-dev, priv-cpts,
data-cpts_clock_mult, data-cpts_clock_shift))
dev_err(priv-dev, error registering cpts device\n);
--
1.8.5.1.93.g077f434
--
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 v1 2/2] mtd: nand: omap: fix ecclayout to be in sync with u-boot NAND driver
This patch mainly fixes ecc-layout for following ecc-schemes, to bring them
in sync with u-boot omap_gpmc NAND driver:
- BCH4_SW: OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
This ecc-scheme is mainly used on AM35xx and other legacy platforms.
- BCH8_SW: OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
This ecc-scheme is mainly used on OMAP3x and other legacy platforms.
Apart from above, this patch also touches other ecc-schemes as the fix
required refactoring common code, into ecc-scheme specific code.
Hence, end-to-end NAND boot sequence was tested on AM335x-EVM to avoid
any further regression on legacy or current platforms.
(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
*Configurations used to build u-boot and kernel for end-to-end NAND boot*
+++--+
| ecc-scheme | u-boot/SPL configs| kernel DTS |
+++--+
||| |
| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \ |ti,nand-ecc-opts= |
|| OMAP_ECC_HAM1_CODE_HW |ham1|
| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 | |
| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ | |
| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \| |
||10, 11, 12 }| |
|| (for NAND page-size=2048) | |
||| |
+++--+
||| |
| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |bch8|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM node)|
| using s/w | #define CONFIG_BCH | |
|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH | |
|for ECC | #define CONFIG_SPL_NAND_SIMPLE | |
| error | #define CONFIG_SYS_NAND_ECCPOS \ | |
|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ | |
|| 11, 12, 13, 14, \ | |
|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ | |
|| 25, 26, 27, 28, \ | |
|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ | |
|| 39, 40, 41, 42, \ | |
|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ | |
|| 53, 54, 55, 56, } | |
|| (for NAND page-size=2048) | |
|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
||| |
+++--+
||| |
| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW |bch8|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 | |
| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node) |
| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=elm |
|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \| |
| error | 10, 11, 12, 13, 14, 15, 16, 17, \| |
|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \| |
|| 26, 27, 28, 29, 30, 31, 32, 33, \| |
|| 34, 35, 36, 37, 38, 39, 40, 41, \| |
|| 42, 43, 44, 45, 46, 47, 48, 49, \| |
|| 50, 51, 52, 53, 54, 55, 56, 57, }| |
|| (for NAND page-size=2048) | |
|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
|||
[PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
As there were parallel set of patches running between u-boot and kernel.
hence, some patch-sets caused regression for OMAP3x platforms when booting
using u-boot specifically for ecc-schemes (like BCH4_SW).
Hence this patch series fixes those regressions, and tests complete
NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
(following configurations are required for building u-boot driver which is
compatible to kernel ecclayout for selected ecc-scheme)
(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
ROM - SPL - U-Boot - Kernel - File-System
*Configurations used to build u-boot and kernel for end-to-end NAND boot*
+++--+
| ecc-scheme | u-boot/SPL configs| kernel DTS |
+++--+
||| |
| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \ |ti,nand-ecc-opts= |
|| OMAP_ECC_HAM1_CODE_HW |ham1|
| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 | |
| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ | |
| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \| |
||10, 11, 12 }| |
|| (for NAND page-size=2048) | |
||| |
+++--+
||| |
| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |bch8|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM node)|
| using s/w | #define CONFIG_BCH | |
|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH | |
|for ECC | #define CONFIG_SPL_NAND_SIMPLE | |
| error | #define CONFIG_SYS_NAND_ECCPOS \ | |
|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ | |
|| 11, 12, 13, 14, \ | |
|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ | |
|| 25, 26, 27, 28, \ | |
|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ | |
|| 39, 40, 41, 42, \ | |
|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ | |
|| 53, 54, 55, 56, } | |
|| (for NAND page-size=2048) | |
|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
||| |
+++--+
||| |
| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
|| OMAP_ECC_BCH8_CODE_HW |bch8|
|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 | |
| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node) |
| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=elm |
|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \| |
| error | 10, 11, 12, 13, 14, 15, 16, 17, \| |
|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \| |
|| 26, 27, 28, 29, 30, 31, 32, 33, \| |
|| 34, 35, 36, 37, 38, 39, 40, 41, \| |
|| 42, 43, 44, 45, 46, 47, 48, 49, \| |
|| 50, 51, 52, 53, 54, 55, 56, 57, }| |
|| (for NAND page-size=2048) | |
|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
||| |
+++--+
#* In addition following patches need to be pulled for
[PATCH v1 1/2] mtd: nand: omap: fix ecclayout-oobfree-offset
This patch updates starting offset for free bytes in OOB which can be used by
file-systems to store their metadata (like clean-marker in case of JFFS2).
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f777250..bbdb5e8 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1835,8 +1835,6 @@ static int omap_nand_probe(struct platform_device *pdev)
ecclayout-eccpos[0]= BADBLOCK_MARKER_LENGTH;
else
ecclayout-eccpos[0]= 1;
- ecclayout-oobfree-offset = ecclayout-eccpos[0] +
- ecclayout-eccbytes;
break;
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
@@ -1854,8 +1852,6 @@ static int omap_nand_probe(struct platform_device *pdev)
(mtd-writesize /
nand_chip-ecc.size);
ecclayout-eccpos[0]= BADBLOCK_MARKER_LENGTH;
- ecclayout-oobfree-offset = ecclayout-eccpos[0] +
- ecclayout-eccbytes;
/* software bch library is used for locating errors */
nand_chip-ecc.priv = nand_bch_init(mtd,
nand_chip-ecc.size,
@@ -1890,8 +1886,6 @@ static int omap_nand_probe(struct platform_device *pdev)
(mtd-writesize /
nand_chip-ecc.size);
ecclayout-eccpos[0]= BADBLOCK_MARKER_LENGTH;
- ecclayout-oobfree-offset = ecclayout-eccpos[0] +
- ecclayout-eccbytes;
/* This ECC scheme requires ELM H/W block */
if (is_elm_present(info, pdata-elm_of_node, BCH4_ECC) 0) {
pr_err(nand: error: could not initialize ELM\n);
@@ -1920,8 +1914,6 @@ static int omap_nand_probe(struct platform_device *pdev)
(mtd-writesize /
nand_chip-ecc.size);
ecclayout-eccpos[0]= BADBLOCK_MARKER_LENGTH;
- ecclayout-oobfree-offset = ecclayout-eccpos[0] +
- ecclayout-eccbytes;
/* software bch library is used for locating errors */
nand_chip-ecc.priv = nand_bch_init(mtd,
nand_chip-ecc.size,
@@ -1963,8 +1955,6 @@ static int omap_nand_probe(struct platform_device *pdev)
(mtd-writesize /
nand_chip-ecc.size);
ecclayout-eccpos[0]= BADBLOCK_MARKER_LENGTH;
- ecclayout-oobfree-offset = ecclayout-eccpos[0] +
- ecclayout-eccbytes;
break;
#else
pr_err(nand: error: CONFIG_MTD_NAND_OMAP_BCH not enabled\n);
@@ -1978,9 +1968,6 @@ static int omap_nand_probe(struct platform_device *pdev)
goto return_error;
}
- /* populate remaining ECC layout data */
- ecclayout-oobfree-length = mtd-oobsize - (BADBLOCK_MARKER_LENGTH +
- ecclayout-eccbytes);
for (i = 1; i ecclayout-eccbytes; i++)
ecclayout-eccpos[i] = ecclayout-eccpos[0] + i;
/* check if NAND device's OOB is enough to store ECC signatures */
@@ -1990,6 +1977,10 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -EINVAL;
goto return_error;
}
+ /* populate remaining ECC layout data */
+ ecclayout-oobfree-offset = ecclayout-eccpos[ecclayout-eccbytes] + 1;
+ ecclayout-oobfree-length = mtd-oobsize - (BADBLOCK_MARKER_LENGTH +
+ ecclayout-eccbytes);
/* second phase scan */
if (nand_scan_tail(mtd)) {
--
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 0/5] Add more device nodes for am43x-epos-evm
+ Andrew Morton. Ping on this. On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote: The patch series adds support for enabling pwm backlight, i2c2, spi and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) [1]: https://patchwork.kernel.org/patch/3009541/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this temporary patch[2]. [2]: http://www.spinics.net/lists/arm-kernel/msg288215.html Darren Etheridge (1): pinctrl: am43xx: dt-bindings: add MUX_MODE8 Sourav Poddar (4): arm: dts: am4372: Add pwm-cellsproperty for ecap device. arm: dts: am43x-epos-evm: Add I2C data. arm: dts: am43x-epos-evm: Add SPI data. ARM: dts: am43x-epos-evm: Add pwm backlight support. arch/arm/boot/dts/am4372.dtsi|9 + arch/arm/boot/dts/am43x-epos-evm.dts | 67 ++ include/dt-bindings/pinctrl/am43xx.h |1 + 3 files changed, 77 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 91 +
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = 3;
power = 50;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+
+ dsi1_out_ep: endpoint {
+ remote-endpoint = lcd0_in;
+ lanes = 0 1 2 3 4 5;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
+ };
+
+ lcd0: display@0 {
+ compatible = tpo,taal, panel-dsi-cm;
+
+ gpios = gpio4 6 0; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = dsi1_out_ep;
+ };
+ };
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
On 2013-12-13 05:24, Laurent Pinchart wrote: Right. The real question is whether the DSI or HDMI IPs can be used in a system without the DSS core. If not, it might make sense to just merge the drivers into a single module (of course with a clear interface between the different parts to avoid spaghetti code). The drivers are already in single kernel module, omapdss.ko. The HDMI IP is used on another SoC, without DSS. They have their own display architecture. DSI IP might need some small modifications to work without DSS, but not much. It doesn't have any strict DSS/DISPC dependencies. Given that the DSS core has a set of registers not dedicated to any of the submodules I believe it should be represented by a device. The omapdss driver thus doesn't look virtual to me, it supports a real piece of hardware. As noted in another mail, dss_core and omapdss devices are different things. dss_core is not virtual, omapdss is. But then, I feel that they are quite independent and probably should be separate devices. Even if they're separate devices they could be instantiated by DSS core based on DT nodes. I'm not sure whether that's the best idea, but it might be worth thinking about it. What would be the difference to the one in this series? In this series, the submodules are instantiated automatically by the driver framework. The only difference I see is that the submodule devices would appear/disappear dynamically, but... what would be the benefit? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
On 2013-12-13 11:27, Archit Taneja wrote:
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 91
+
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts
b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = 3;
power = 50;
};
+
+dsi1 {
+vdds_dsi-supply = vcxio;
+
+dsi1_out_ep: endpoint {
+remote-endpoint = lcd0_in;
+lanes = 0 1 2 3 4 5;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.
In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.
My reasoning where a property belongs to:
If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.
If a property is about the link between two devices, like lanes here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.
If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.
But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.
+};
+
+lcd0: display@0 {
+compatible = tpo,taal, panel-dsi-cm;
+
+gpios = gpio4 6 0;/* 102, reset */
+
+lcd0_in: endpoint {
+remote-endpoint = dsi1_out_ep;
+};
+};
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
On Friday 13 December 2013 03:09 PM, Tomi Valkeinen wrote:
On 2013-12-13 11:27, Archit Taneja wrote:
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 91
+
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts
b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = 3;
power = 50;
};
+
+dsi1 {
+vdds_dsi-supply = vcxio;
+
+dsi1_out_ep: endpoint {
+remote-endpoint = lcd0_in;
+lanes = 0 1 2 3 4 5;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.
In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.
My reasoning where a property belongs to:
If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.
If a property is about the link between two devices, like lanes here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.
If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.
But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.
Okay, that makes sense.
+};
+
+lcd0: display@0 {
+compatible = tpo,taal, panel-dsi-cm;
+
+gpios = gpio4 6 0;/* 102, reset */
+
+lcd0_in: endpoint {
+remote-endpoint = dsi1_out_ep;
+};
+};
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Ah, I thought the port/endpoint stuff had something to do with this. I
forgot about the parent-child relationship for the control path.
In that case, for the sake of accuracy, the dsi-cm panel could get the
in parameter via the parent node wherever it's used for control, like
setting a DCS command for sleep out. And via
omapdss_of_find_source_for_first_ep() when it's used to start data
transfer, even though both the in's are finally the same dsi device?
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-13 05:45, Laurent Pinchart wrote: I know drivers/video is in practice fbdev, but drivers/video (the words) sound like the best place for things related to video. That's an option as well, but I'm not sure I like the idea of mixing fbdev and generic video in a single directory. We could use a subdirectory of drivers/video. Right, that's what I meant. I also don't supply the same data for both endpoints, when the data is about the link. E.g. I think the V4L2 binding doc suggests to supply things like bus-width for both endpoints. I only supply the data for the endpoint that uses that data. With some encoders/panels the same data could be needed on both ends, but not in these patches. How do you handle the situation where the two drivers (for each end of the link) need to know the bus width for instance ? Then I fill the bus-width for both ends, as shown in the V4L2 bindings. That's what I mean with I only supply the data for the endpoint that uses that data. If both ends use the data, I supply it for both. The most important thing in the DSS DT bindings for now is that they should contain enough information so that any future DT bindings changes can be handled with a boot-time conversion code. I'm afraid I can't give you any guarantee here. The bindings will be unstable for some time, and we'll have to deal with that somehow. I'm not asking for a guarantee. Just yes, feels fine =). The omapdss platform data structure contains the following fields - get_context_loss_count: What is that used for ? To find out if a HW block has been turned off and it has lost its registers contents. It's an optimization, without it we need to restore registers each time when runtime_resume() hook is called. However, that's on its way out. I've already made new PM code for dispc which doesn't use that. But I can't merge it before omapdrm has been fixed to properly set things up when enabling a display. - num_devices, devices, default_device: What are those used for ? Nothing anymore. They can be removed. - default_display_name: This should be easy to move to DT. How? I handled it so that I assign the aliases for displays, and display0 is always the default display. default display name is not really a hw property =). I think this should not be used for DT, and just use the display0 as default (if we use aliases). If we don't use aliases, and instead use the label properties as discussed in other thread, then there has to be some other mechanism to tell which display should be used. - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline. What's their purpose, and how are they implemented on platforms that make use of them ? Is the pinmux API an option ? They are used in mainline, grep again =). They set pinmuxing for DSI. Pinmux API is an option, but I think it would require a new driver. The DSI pins for DSI1 and DSI2 are configured in a single register, where the fields go in seemingly random order with varying widths. pinmux-single cannot be used. - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic solution is needed here. - version: Given that we detect the DSS revision based on the SoC revision, I'm tempted to either explicitly encode the DSS revision in the compatible string, or let the DSS driver query the SoC revision somehow. The later is considered as a layering violation, but let's face it, I can't see the DSS being used on a non-OMAP platform. I also would just use the compatible string, but we need to separate between different OMAP ES versions. Doing that would mean we'd need different .dtsi and .dts files for the different OMAP ES versions. It would be a mess. I have a TODO item to study this. There are only a few things that are problematic (changed between ES versions without changing DSS HW revision). If I can find a way around those, the compatible string should be enough. One example is the width of a blanking interval. Newer OMAP3 revisions have a slightly wider field. I didn't try, but maybe I can write 1-bits to the register, then read it, and if only part of those 1 bits stick, I know it's an old revision. Anyway, I think this platform data thing is not strictly related. None of these items affect the DT data (except the pinmuxing, but I think it's fine to add that later). So while the above issues need to be fixed at some point, I think they don't affect this series (well, the default display is there which may affect). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
On 2013-12-13 11:58, Archit Taneja wrote:
+};
+
+lcd0: display@0 {
+compatible = tpo,taal, panel-dsi-cm;
+
+gpios = gpio4 6 0;/* 102, reset */
+
+lcd0_in: endpoint {
+remote-endpoint = dsi1_out_ep;
+};
+};
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Ah, I thought the port/endpoint stuff had something to do with this. I
forgot about the parent-child relationship for the control path.
In that case, for the sake of accuracy, the dsi-cm panel could get the
in parameter via the parent node wherever it's used for control, like
setting a DCS command for sleep out. And via
omapdss_of_find_source_for_first_ep() when it's used to start data
transfer, even though both the in's are finally the same dsi device?
Don't mix the DT data and the current driver =). The current driver does
not handle things properly. The driver still uses the current model,
where we don't have separate control and data path handling. I.e. both
control and data are handled via the single API, using the in field.
The important thing with this DT data is that in the future we can
change the driver model, if we so want, to manage data and control
separately. Or maybe add a DSI bus, as has been proposed elsewhere.
It's true that we could change the driver as you describe, but I don't
think it helps anything, as the current model in the driver only has a
single control-data path.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
On 2013-12-13 05:27, Laurent Pinchart wrote: Hi Tony, On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote: On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote: On 2013-12-12 01:44, Laurent Pinchart wrote: So, are they independent? I don't know =). I think they lean on the independent side. dss_core is always needed for the submodules to work, but for example DSI could be used without DISPC, using system DMA to transfer data from memory to DSI. Not a very useful thing to do, but still, there are dedicated DMA channels for that. If they have separate hwmod entries, they should be considered separate independent devices for sure. To summarize, here are few reasons why they need to be treated as separate devices: Are you talking generally here, or about the DSS modules in particular ? 1. The modules maybe clocked/powered/idled separately and can have their own idle configuration so they can do the hardware based idling separately. I don't think this applies to the DSS modules. The DSS submodules have their own SYSCONFIG register, and idle settings can be set per module. So I think they idle separately, even if they are in a common power domain. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
On Mon, Dec 9, 2013 at 6:50 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131208 23:36]: Hi Tony, On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131203 01:21]: On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [1.209075] HS USB OTG: no transceiver configured [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. Yes it is regression and without that usb on most omap3 based boards without DT will not work. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. I'm still clueless which USB regression fix to apply for the -rc cycle though.. Hoping to see a single patch which clearly states the issue and has acks. Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). Otherwise I think only possible option to avoid non-working usb in 3.13 for omap is took my patch. Thanks. Regards, Tony BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi, On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: On Mon, Dec 9, 2013 at 6:50 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131208 23:36]: Hi Tony, On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131203 01:21]: On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [1.209075] HS USB OTG: no transceiver configured [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. Yes it is regression and without that usb on most omap3 based boards without DT will not work. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. I'm still clueless which USB regression fix to apply for the -rc cycle though.. Hoping to see a single patch which clearly states the issue and has acks. Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). I'm not sure as my patch modifies all the board files. There was initially some confusion w.r.t when the board files will be dropped. But since board files will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways if you have tested my patch (series), pls give your Tested-by. Tony, summary of the issue.. After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. So had to make the corresponding changes in board files. [1] - http://lists.scusting.com/index.php?t=msgth=375579start=0S=Google Thanks Kishon Otherwise I think only possible option to avoid non-working usb in 3.13 for omap is took my patch. Thanks. Regards, Tony BR, marek -- 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 06/26] OMAPDSS: if dssdev-name==NULL, use alias
On 2013-12-12 16:13, Tomi Valkeinen wrote:
On 2013-12-12 12:05, Sebastian Reichel wrote:
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a label property like this:
foo : node {
label = lcd;
...
};
See for example
Documentation/devicetree/bindings/leds/common.txt
Documentation/devicetree/bindings/mtd/partition.txt
Ah, I see. That kind of label was actually the first thing I did when
starting to work on DSS DT. But I removed it, as it didn't describe the
hardware and I didn't see others using anything similar.
But I guess one could argue it does describe hardware, not in electrical
level but in conceptual level.
The question is, do we need labeling for displays? For backward
compatibility omapdss would need it, but in general? I'm quite content
with having just display0, display1 etc. Using the alias node, those can
be fixed and display0 is always the same display.
I came to the conclusion that it's better to add the label to keep
backward compatibility, especially as it was very easy to add.
So we'll have 'name' and 'alias' for each display (as we have already).
In the current non-DT boot (which is going away):
- 'alias' is created by omapdss dynamically (first display to be
registered is display0, etc.)
- 'name' comes from platform data
In the DT boot:
- 'alias' comes from the DT aliases node, or if there are no display
aliases, it's created the same way as to non-DT. The code presumes that
there either is a DT alias for all displays, or there are none.
- 'name' comes from 'label' property
In both non-DT and DT cases, if 'name' is NULL (i.e. not set in platform
data or no 'label' property), the alias is used as a name.
I think this works fine, and was a trivial change.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
On Thu, Dec 12, 2013 at 11:29 PM, Andreas Naumann d...@andin.de wrote:
Hi Grazvydas,
Von: Grazvydas Ignotas [mailto:nota...@gmail.com]
Gesendet: Donnerstag, 12. Dezember 2013 01:21
An: linux-...@vger.kernel.org
Cc: Felipe Balbi; linux-omap@vger.kernel.org; Naumann Andreas; Grazvydas
Ignotas; sta...@vger.kernel.org
Betreff: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
which introduces save/restore of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).
This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usbm=138562574719654w=2
Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!
drivers/usb/musb/omap2430.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if (musb-context.otg_interfsel != 0)
+ musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
phy_power_on(musb-phy);
}
Oh, easy way out. I like it but I've also been thinking about your comment
on my original post, which was that initializing otg_interfsel to the PHYSEL
bits only might be dangerous because we cant be sure that there are other
bits in the register.
However, isnt assuming that 0 is invalid on all OMAPs just as dangerous?
Well I was trying to do a minimal fix so that it could be suitable for
merging to stable kernels. But yes you're right, I've just checked
OMAP4 TRM and 0 is actually valid value there..
After thinking about my patch again, I would propose to change otg_interfsel
into otg_physel and read-modify-write only those bits in resume() as you
suggested in your first answer. That way I could discard the problematic
first read in probe() while leaving other bits untouched. If you agree I
post a patch for this tomorrow.
Hmm I don't know about that, this would be inconsistent with what all
other OMAP drivers do. Maybe we should do what musb_core.c does just
to be consistent and add a similar comment. Only the static variable
could be avoided in favor of struct omap2430_glue member.
GraÅžvydas
--
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/1] drivers: net cpsw: Enable In Band mode in cpsw for 10 mbps
This patch adds support for enabling In Band mode in 10 mbps speed.
RGMII supports 1 Gig and 100 mbps mode for Forced mode of operation.
For 10mbps mode it should be configured to in band mode so that link
status, duplexity and speed are determined from the RGMII input data
stream
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index d80dfce..989968b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -740,6 +740,8 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
/* set speed_in input in case RMII mode is used in 100Mbps */
if (phy-speed == 100)
mac_control |= BIT(15);
+ else if (phy-speed == 10)
+ mac_control |= BIT(18); /* In Band mode */
*link = true;
} else {
--
1.8.5.1.93.g077f434
--
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/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi,
On Friday 13 December 2013 12:05:20 Tomi Valkeinen wrote:
On 2013-12-13 05:45, Laurent Pinchart wrote:
I know drivers/video is in practice fbdev, but drivers/video (the
words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev
and generic video in a single directory. We could use a subdirectory of
drivers/video.
Right, that's what I meant.
I also don't supply the same data for both endpoints, when the data is
about the link. E.g. I think the V4L2 binding doc suggests to supply
things like bus-width for both endpoints. I only supply the data for the
endpoint that uses that data. With some encoders/panels the same data
could be needed on both ends, but not in these patches.
How do you handle the situation where the two drivers (for each end of the
link) need to know the bus width for instance ?
Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
That's what I mean with I only supply the data for the endpoint that
uses that data. If both ends use the data, I supply it for both.
That sounds good to me.
The most important thing in the DSS DT bindings for now is that they
should contain enough information so that any future DT bindings changes
can be handled with a boot-time conversion code.
I'm afraid I can't give you any guarantee here. The bindings will be
unstable for some time, and we'll have to deal with that somehow.
I'm not asking for a guarantee. Just yes, feels fine =).
The omapdss platform data structure contains the following fields
- get_context_loss_count: What is that used for ?
To find out if a HW block has been turned off and it has lost its
registers contents. It's an optimization, without it we need to restore
registers each time when runtime_resume() hook is called.
However, that's on its way out. I've already made new PM code for dispc
which doesn't use that. But I can't merge it before omapdrm has been
fixed to properly set things up when enabling a display.
OK.
- num_devices, devices, default_device: What are those used for ?
Nothing anymore. They can be removed.
- default_display_name: This should be easy to move to DT.
How? I handled it so that I assign the aliases for displays, and
display0 is always the default display. default display name is not
really a hw property =).
I think this should not be used for DT, and just use the display0 as
default (if we use aliases). If we don't use aliases, and instead use
the label properties as discussed in other thread, then there has to be
some other mechanism to tell which display should be used.
Another option would be to add a phandle that references the default display.
I don't have a strong preference at the moment.
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
They set pinmuxing for DSI. Pinmux API is an option, but I think it would
require a new driver. The DSI pins for DSI1 and DSI2 are configured in a
single register, where the fields go in seemingly random order with varying
widths. pinmux-single cannot be used.
Or, as Archit mentioned, we could pass the SYSCONF registers as resources.
That might not be very clean though.
- set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a
generic solution is needed here.
- version: Given that we detect the DSS revision based on the SoC
revision, I'm tempted to either explicitly encode the DSS revision in the
compatible string, or let the DSS driver query the SoC revision somehow.
The later is considered as a layering violation, but let's face it, I
can't see the DSS being used on a non-OMAP platform.
I also would just use the compatible string, but we need to separate between
different OMAP ES versions. Doing that would mean we'd need different .dtsi
and .dts files for the different OMAP ES versions. It would be a mess.
I have a TODO item to study this. There are only a few things that are
problematic (changed between ES versions without changing DSS HW revision).
If I can find a way around those, the compatible string should be enough.
One example is the width of a blanking interval. Newer OMAP3 revisions have
a slightly wider field. I didn't try, but maybe I can write 1-bits to the
register, then read it, and if only part of those 1 bits stick, I know
it's an old revision.
Anyway, I think this platform data thing is not strictly related. None of
these items affect the DT data (except the pinmuxing, but I
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Tomi
signature.asc
Description: OpenPGP digital signature
RE: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
Hello -Original Message- From: Shilimkar, Santosh Sent: Thursday, December 12, 2013 7:29 PM To: Balbi, Felipe Cc: Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung-...@vger.kernel.org; Linux OMAP Mailing List; Kwok, WingMan Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I have tested the patch and the keystone usb driver continues to function, though I can't test suspend at this time as the rest of the system does not that functionality yet. Thanks WingMan -- 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: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
On 13.12.2013 13:34, Grazvydas Ignotas wrote:
On Thu, Dec 12, 2013 at 11:29 PM, Andreas Naumann d...@andin.de wrote:
Hi Grazvydas,
Von: Grazvydas Ignotas [mailto:nota...@gmail.com]
Gesendet: Donnerstag, 12. Dezember 2013 01:21
An: linux-...@vger.kernel.org
Cc: Felipe Balbi; linux-omap@vger.kernel.org; Naumann Andreas; Grazvydas
Ignotas; sta...@vger.kernel.org
Betreff: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c omap2+: save and restore OTG_INTERFSEL,
which introduces save/restore of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).
This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usbm=138562574719654w=2
Reported-and-bisected-by: Andreas Naumann anaum...@ultratronik.de
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!
drivers/usb/musb/omap2430.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb-mregs, OTG_INTERFSEL,
+ if (musb-context.otg_interfsel != 0)
+ musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
phy_power_on(musb-phy);
}
Oh, easy way out. I like it but I've also been thinking about your comment
on my original post, which was that initializing otg_interfsel to the PHYSEL
bits only might be dangerous because we cant be sure that there are other
bits in the register.
However, isnt assuming that 0 is invalid on all OMAPs just as dangerous?
Well I was trying to do a minimal fix so that it could be suitable for
merging to stable kernels. But yes you're right, I've just checked
OMAP4 TRM and 0 is actually valid value there..
After thinking about my patch again, I would propose to change otg_interfsel
into otg_physel and read-modify-write only those bits in resume() as you
suggested in your first answer. That way I could discard the problematic
first read in probe() while leaving other bits untouched. If you agree I
post a patch for this tomorrow.
Hmm I don't know about that, this would be inconsistent with what all
other OMAP drivers do. Maybe we should do what musb_core.c does just
Ok, thats cool.
to be consistent and add a similar comment. Only the static variable
could be avoided in favor of struct omap2430_glue member.
Whats wrong with the static?
cheers,
Andreas
GraÅžvydas
--
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] gpio: twl4030: fix regression for twl gpio outputs for led pins
Commit 0b2aa8b (gpio: twl4030: Fix regression for twl gpio output)
introduces yet another regression by ignoring the fact that we use twl
gpio even for LED. For example, leda (offset 18) is used for USB port2
power on beagleboard-xm.
The original logic was supposed to setup the TWL4030 GPIO direction
if the offset was TWL4030_GPIO_MAX, and anything greater used
twl4030_led_set_value as part of twl_set to setup the LED pin. However,
with the commit mentioned above, LEDa pin request will result in fail
as the GPIO number for LEDa is equal to TWL4030_GPIO_MAX and USB fails
to function on beagleboard-xm. This is reported in the log as:
hsusb2_vbus: Failed to request enable GPIO510: -22
To fix this, we should handle the fail case of
twl4030_set_gpio_direction independent of the offset TWL4030_GPIO_MAX
check.
Signed-off-by: Nishanth Menon n...@ti.com
---
Applies on v3.13-rc3
Tested on beagleboard-xm which uses ethernet over usb:
before the patch (USB regression): http://pastebin.mozilla.org/3769443
After this patch: http://pastebin.mozilla.org/3769454
drivers/gpio/gpio-twl4030.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..9242276 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,11 +354,16 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
+ int ret = 0;
mutex_lock(priv-mutex);
- if (offset TWL4030_GPIO_MAX)
+ if (offset TWL4030_GPIO_MAX) {
ret = twl4030_set_gpio_direction(offset, 0);
+ if (ret) {
+ mutex_unlock(priv-mutex);
+ return ret;
+ }
+ }
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
--
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: debugfs pinctrl crash on beagle-xm
* Nishanth Menon n...@ti.com [131212 15:38]: On 12/10/2013 04:41 AM, Tomi Valkeinen wrote: Hi, On beagle-xm, v3.13-rc3, I see the following crash if I use the pinctrl debugfs: # cat /debug/pinctrl/48002030.pinmux/pins [ 16.464233] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa002268 in 3630 TRM, There is a hole in the memory map between 0x48002264(CONTROL_PADCONF_SDRC_CKE1) and 0x480025A0(CONTROL_PADCONF_SDRC_BA0) which obviously generates abort when read at 0x48002268 on 3430, we should also see a crash in the hole region 0x48002264(CONTROL_PADCONF_SDRC_CKE1) to 0x480025D8(CONTROL_PADCONF_ETK_CLK). in dts, omap3_pmx_core: pinmux@48002030 describes the range as reg = 0x48002030 0x05cc (which is the max range for the module) wish pinctrl-single driver could support handle multiple address ranges? [...] There's an RFC patch from Laurent to split the pmx_core into two instances that should take care of this issue: [PATCH/RFC] ARM: omap3: Split the pinmux core device Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
* Archit Taneja arc...@ti.com [131213 00:33]: I have seen other OMAP drivers passing control module register info to their DT node. Instead of having a pinmux driver for a single register, we might want to consider just passing the control module register, and take care of the reg fields and masks in the OMAP DSI driver itself. See the PBIAS control module patches and their comments from Balaji. We can map the misc registers of SCM using drivers/mfd/syscon.c and that way drivers can access them via syscon. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debugfs pinctrl crash on beagle-xm
On 12/13/2013 11:04 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [131212 15:38]: On 12/10/2013 04:41 AM, Tomi Valkeinen wrote: Hi, On beagle-xm, v3.13-rc3, I see the following crash if I use the pinctrl debugfs: # cat /debug/pinctrl/48002030.pinmux/pins [ 16.464233] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa002268 in 3630 TRM, There is a hole in the memory map between 0x48002264(CONTROL_PADCONF_SDRC_CKE1) and 0x480025A0(CONTROL_PADCONF_SDRC_BA0) which obviously generates abort when read at 0x48002268 on 3430, we should also see a crash in the hole region 0x48002264(CONTROL_PADCONF_SDRC_CKE1) to 0x480025D8(CONTROL_PADCONF_ETK_CLK). in dts, omap3_pmx_core: pinmux@48002030 describes the range as reg = 0x48002030 0x05cc (which is the max range for the module) wish pinctrl-single driver could support handle multiple address ranges? [...] There's an RFC patch from Laurent to split the pmx_core into two instances that should take care of this issue: [PATCH/RFC] ARM: omap3: Split the pinmux core device Arggh.. yet again, I missed that :( grr... https://patchwork.kernel.org/patch/3335341/ follows the similar direction Laurent took for https://patchwork.kernel.org/patch/3283781/ -- Regards, Nishanth Menon -- 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 13/26] ARM: omap3.dtsi: add omapdss information
* Tomi Valkeinen tomi.valkei...@ti.com [131213 02:19]: On 2013-12-13 05:27, Laurent Pinchart wrote: Hi Tony, On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote: On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote: On 2013-12-12 01:44, Laurent Pinchart wrote: So, are they independent? I don't know =). I think they lean on the independent side. dss_core is always needed for the submodules to work, but for example DSI could be used without DISPC, using system DMA to transfer data from memory to DSI. Not a very useful thing to do, but still, there are dedicated DMA channels for that. If they have separate hwmod entries, they should be considered separate independent devices for sure. To summarize, here are few reasons why they need to be treated as separate devices: Are you talking generally here, or about the DSS modules in particular ? 1. The modules maybe clocked/powered/idled separately and can have their own idle configuration so they can do the hardware based idling separately. I don't think this applies to the DSS modules. The DSS submodules have their own SYSCONFIG register, and idle settings can be set per module. So I think they idle separately, even if they are in a common power domain. Yes. Please see the current omap_hwmod_*_data.c files, if they are separate entries there, that means we need to treat them as separate devices to avoid the issues I listed. We do have some entries still missing from omap_hwmod_*_data.c files, like the SSI entries as they are undocumented. But for the existing ones there please follow the same layout for the .dts entries. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
* Tomi Valkeinen tomi.valkei...@ti.com [131213 07:49]:
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: twl4030: fix regression for twl gpio outputs for led pins
* Nishanth Menon n...@ti.com [131213 08:48]:
Commit 0b2aa8b (gpio: twl4030: Fix regression for twl gpio output)
introduces yet another regression by ignoring the fact that we use twl
gpio even for LED. For example, leda (offset 18) is used for USB port2
power on beagleboard-xm.
The original logic was supposed to setup the TWL4030 GPIO direction
if the offset was TWL4030_GPIO_MAX, and anything greater used
twl4030_led_set_value as part of twl_set to setup the LED pin. However,
with the commit mentioned above, LEDa pin request will result in fail
as the GPIO number for LEDa is equal to TWL4030_GPIO_MAX and USB fails
to function on beagleboard-xm. This is reported in the log as:
hsusb2_vbus: Failed to request enable GPIO510: -22
To fix this, we should handle the fail case of
twl4030_set_gpio_direction independent of the offset TWL4030_GPIO_MAX
check.
Heh again :) Linus has already queued a similar fix, see
[PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output.
Regards,
Tony
Signed-off-by: Nishanth Menon n...@ti.com
---
Applies on v3.13-rc3
Tested on beagleboard-xm which uses ethernet over usb:
before the patch (USB regression): http://pastebin.mozilla.org/3769443
After this patch: http://pastebin.mozilla.org/3769454
drivers/gpio/gpio-twl4030.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..9242276 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,11 +354,16 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
+ int ret = 0;
mutex_lock(priv-mutex);
- if (offset TWL4030_GPIO_MAX)
+ if (offset TWL4030_GPIO_MAX) {
ret = twl4030_set_gpio_direction(offset, 0);
+ if (ret) {
+ mutex_unlock(priv-mutex);
+ return ret;
+ }
+ }
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
--
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: [PATCH v2 0/3] OMAP2+: hwmod: Add support to parse clock info from DT
* Rajendra Nayak rna...@ti.com [131212 03:40]: v1 of this series was posted a while back [1] but there wasn't much that was concluded if the approach used in the series was acceptable or if there are better alternatives. So I am just doing a repost of these to see if we can conclude this time around. Needless to say, patches are based off Teros omap-clocks-to-dt v10 series [2] and I also pulled in Tonys fix to handle DT nodes with multiple 'ti,hwmod' values [3]. The approach taken in the series *does not* work for cases with multiple 'ti,hwmod' values and hence [3] helps me skip those instances for now. But based on some of the recent discussions on multiple 'ti-hwmod' values [4] it looks like its generally agreed upon that having DT nodes with multiple 'ti-hwmod' property is wrong and that those instances need to be fixed up anyway. Yeah we need to have 1-to-1 mapping of device entries in the .dtsi files to the device entries in the omap_hwmod_*_data.c files. And then we can just deprecate ti,hwmods property and start parsing the standard compatible flag instead. Regards, Tony [1] http://www.spinics.net/lists/linux-omap/msg95746.html [2] http://www.spinics.net/lists/devicetree/msg13455.html [3] http://www.spinics.net/lists/arm-kernel/msg288036.html [4] http://www.spinics.net/lists/arm-kernel/msg288023.html Rajendra Nayak (3): ARM: OMAP2+: Add support to parse 'main_clk' info from DT ARM: OMAP2+: Add support to parse optional clk info from DT ARM: OMAP4: dts: Add main and optional clock data into DT arch/arm/boot/dts/omap4.dtsi | 100 +++ arch/arm/mach-omap2/omap_hwmod.c | 88 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 122 3 files changed, 180 insertions(+), 130 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: [PATCH] omap: twl-common: Fix musb-hdrc device name.
* Kishon Vijay Abraham I kis...@ti.com [131213 03:57]: On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). I'm not sure as my patch modifies all the board files. There was initially some confusion w.r.t when the board files will be dropped. But since board files will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways if you have tested my patch (series), pls give your Tested-by. Tony, summary of the issue.. After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. So had to make the corresponding changes in board files. OK. Can you please repost with a proper commit id for what caused the regression and summararize why it should be fixed this way. Something like: Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue with blah blah blah. Note that the board-*.c files will be removed soon, but for v3.13 we still support both legacy booting and device tree based booting and need to fix it. Regards, Tony [1] - http://lists.scusting.com/index.php?t=msgth=375579start=0S=Google -- 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] gpio: twl4030: fix regression for twl gpio outputs for led pins
On 12/13/2013 11:28 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [131213 08:48]: Commit 0b2aa8b (gpio: twl4030: Fix regression for twl gpio output) introduces yet another regression by ignoring the fact that we use twl gpio even for LED. For example, leda (offset 18) is used for USB port2 power on beagleboard-xm. The original logic was supposed to setup the TWL4030 GPIO direction if the offset was TWL4030_GPIO_MAX, and anything greater used twl4030_led_set_value as part of twl_set to setup the LED pin. However, with the commit mentioned above, LEDa pin request will result in fail as the GPIO number for LEDa is equal to TWL4030_GPIO_MAX and USB fails to function on beagleboard-xm. This is reported in the log as: hsusb2_vbus: Failed to request enable GPIO510: -22 To fix this, we should handle the fail case of twl4030_set_gpio_direction independent of the offset TWL4030_GPIO_MAX check. Heh again :) Linus has already queued a similar fix, see [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output. Alrite, I admit it, I need a vacation ;).. Sigh.. http://marc.info/?l=linux-gpiow=2r=1s=twl4030q=t is not good enough :(.. -- Regards, Nishanth Menon -- 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/RFC] pwm: omap: Add PWM support using dual-mode timers
* Thierry Reding thierry.red...@gmail.com [131212 05:02]: On Tue, Oct 29, 2013 at 02:23:18PM -0700, Tony Lindgren wrote: * NeilBrown ne...@suse.de [131023 23:36]: I submitted this in December last year. I got lots of good feedback and fixed some things, but it never got accepted. Not entirely sure why, maybe I dropped the ball. Anyway, here is again with device-tree support added. This is only an RFC and not a real submission for two reasons, both of which are really directed as Jon. 1/ I have to #include ../arch/arm/plat-omap/include/plat/dmtimer.h which is incredibly ugly. Is there any reason this cannot be moved to include/linux/omap-dmtimer.h? Yes that's what at least dw_apb_timer and sh_timer are doing. 2/ I found that I need to call omap_dm_timer_write_counter(omap-dm_timer, DM_TIMER_LOAD_MIN); when using device-tree. This is because with devicetree omap_timer_restore_context() is called much more often and it sets the counter register to 0 .. it takes a long time to count up to DM_TIMER_LOAD_MIN from there. Now I don't object to calling omap_dm_timer_write_counter (though it might be nice if omap_dm_timer_set_load wrote the one value to both LOAD_REG and COUNTER_REG). However it seems wrong that I have to call it *after* starting the counter. Currently _write_counter refuses to run if the timer hasn't been started. So Jon: a/ can we change omap_dm_timer_write_counter to work when the timer isn't running? b/ can we have omap_dm_timer_set_load also set the counter? For anyone else generous enough to read my code: is this otherwise acceptable? Did not look beyond the dmtimer stuff, but let's start by moving dmtimer.c to live under drivers and move the header, then do the pwm patches. Why does the driver have to move? There is certainly some precedent for having arch-specific code in arch/ but expose the public API via some header in include/linux. Sometimes there's just no proper place for the driver elsewhere, so rather than moving it somewhere more or less random keeping it in arch/arm/plat-omap is just as good. There's actually been some developments regarding the dmtimer usage after these comments, see below. Basically we don't want to export custom functions as we've seen what kind of mess exporting custom interfaces makes. See the current state of omap DMA for example. We've figured out a way to access the timers by doing a request_irq() on a timer, then do a clk_set_rate() to select the timer source clock. And then we need only about five custom functions to program the timer, which can be eventually replaced with some Linux generic hardware timer framework. For more info, see the discussion in thread [PATCH 6/8] devicetree: doc: Document ti,timer-parent property. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAPDSS: DT support for N900 panel
Hi, This patchset adds DT support for the N900 panel. The patchset is based on Tomi's work/dss-dt-2 branch [0]. I suggest to send the DT changes through Benoits queue, since I have more N900 DT changes for 3.14. Also the patch editing the rx51 boardcode can be dropped, since the file is removed in 3.14. I included those two with this patchset, since they are needed to test the other two patches. I did not include a documentation for the DT API, since the omapdss documentation is still missing. I have successfully tested this on the N900. [0] https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=work/dss-dt-2 -- Sebastian Sebastian Reichel (4): OMAPDSS: Add DT support to SDI OMAPDSS: ACX565AKM: Add DT support ARM: OMAP: rx51: DT boot: disable legacy dss init ARM: dts: omap3-n900: Add display support arch/arm/boot/dts/omap3-n900.dts | 18 ++- arch/arm/mach-omap2/board-rx51-video.c | 2 +- .../omap2/displays-new/panel-sony-acx565akm.c | 35 +- drivers/video/omap2/dss/sdi.c | 20 + 4 files changed, 72 insertions(+), 3 deletions(-) -- 1.8.5.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 4/4] ARM: dts: omap3-n900: Add display support
Add support for the Nokia N900's display.
Signed-off-by: Sebastian Reichel s...@debian.org
---
arch/arm/boot/dts/omap3-n900.dts | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c2c306d..cf776f3 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -472,12 +472,28 @@
reg = 0;
};
mipid@2 {
- compatible = acx565akm;
+ compatible = sony,acx565akm;
spi-max-frequency = 600;
reg = 2;
+ label = lcd;
+ reset-gpio = gpio3 26 GPIO_ACTIVE_HIGH; /* 90 */
+
pinctrl-names = default;
pinctrl-0 = display_pins;
+
+ lcd_in: endpoint {
+ remote-endpoint = sdi_out;
+ };
+ };
+};
+
+sdi {
+ vdds_sdi-supply = vaux1;
+
+ sdi_out: endpoint {
+ remote-endpoint = lcd_in;
+ data-lines = 2;
};
};
--
1.8.5.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 3/4] ARM: OMAP: rx51: DT boot: disable legacy dss init
This disables legacy initialization of the
omapdss, if the N900 is booted via DT.
Signed-off-by: Sebastian Reichel s...@debian.org
---
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 43a90c8..9cfebc5 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -48,7 +48,7 @@ static struct omap_dss_board_info rx51_dss_board_info = {
static int __init rx51_video_init(void)
{
- if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
+ if (!machine_is_nokia_rx51())
return 0;
if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
--
1.8.5.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 1/4] OMAPDSS: Add DT support to SDI
Add the code to make the SDI driver work with device tree on OMAP3.
Signed-off-by: Sebastian Reichel s...@debian.org
---
drivers/video/omap2/dss/sdi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index ccc569a..bdc6a68 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -26,6 +26,8 @@
#include linux/export.h
#include linux/platform_device.h
#include linux/string.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include dss.h
@@ -333,6 +335,9 @@ static const struct omapdss_sdi_ops sdi_ops = {
static void sdi_init_output(struct platform_device *pdev)
{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *ep;
+
struct omap_dss_device *out = sdi.output;
out-dev = pdev-dev;
@@ -344,6 +349,15 @@ static void sdi_init_output(struct platform_device *pdev)
out-owner = THIS_MODULE;
omapdss_register_output(out);
+
+ if (!pdev-dev.of_node)
+ return;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return;
+
+ of_property_read_u32(ep, data-lines, sdi.datapairs);
}
static void __exit sdi_uninit_output(struct platform_device *pdev)
@@ -369,12 +383,18 @@ static int __exit omap_sdi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id sdi_of_match[] = {
+ { .compatible = ti,omap3-sdi },
+ {},
+};
+
static struct platform_driver omap_sdi_driver = {
.probe = omap_sdi_probe,
.remove = __exit_p(omap_sdi_remove),
.driver = {
.name = omapdss_sdi,
.owner = THIS_MODULE,
+ .of_match_table = sdi_of_match,
},
};
--
1.8.5.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 2/4] OMAPDSS: ACX565AKM: Add DT support
This adds DT support to the ACX565AKM panel driver.
Signed-off-by: Sebastian Reichel s...@debian.org
---
.../omap2/displays-new/panel-sony-acx565akm.c | 35 +-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..942b8d4 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -30,6 +30,8 @@
#include linux/backlight.h
#include linux/fb.h
#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -531,7 +533,9 @@ static int acx565akm_panel_power_on(struct omap_dss_device
*dssdev)
dev_dbg(ddata-spi-dev, %s\n, __func__);
in-ops.sdi-set_timings(in, ddata-videomode);
- in-ops.sdi-set_datapairs(in, ddata-datapairs);
+
+ if (ddata-datapairs = 0)
+ in-ops.sdi-set_datapairs(in, ddata-datapairs);
r = in-ops.sdi-enable(in);
if (r) {
@@ -710,6 +714,30 @@ static int acx565akm_probe_pdata(struct spi_device *spi)
return 0;
}
+static int acx565akm_probe_of(struct spi_device *spi)
+{
+ struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
+ struct device_node *np = spi-dev.of_node;
+ struct omap_dss_device *dssdev;
+ int ret;
+
+ ddata-reset_gpio = of_get_named_gpio(np, reset-gpio, 0);
+
+ ddata-datapairs = -1;
+ ddata-in = omapdss_of_find_source_for_first_ep(np);
+ if (IS_ERR(ddata-in)) {
+ dev_err(spi-dev, failed to find video source\n);
+ return PTR_ERR(ddata-in);
+ }
+
+ dssdev = ddata-dssdev;
+ ret = of_property_read_string(np, label, dssdev-name);
+ if (ret 0)
+ return ret;
+
+ return 0;
+}
+
static int acx565akm_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -737,7 +765,12 @@ static int acx565akm_probe(struct spi_device *spi)
r = acx565akm_probe_pdata(spi);
if (r)
return r;
+ } else if (spi-dev.of_node) {
+ r = acx565akm_probe_of(spi);
+ if (r)
+ return r;
} else {
+ dev_err(spi-dev, platform data missing!\n);
return -ENODEV;
}
--
1.8.5.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: Add support for sbc-3xxx with cm-t3730
This adds support for CompuLab SBC-T3530, also known as cm-t3730:
http://compulab.co.il/products/sbcs/sbc-t3530/
It seems that with the sbc-3xxx mainboard is also used on
SBC-T3517 and SBC-T3730 with just a different CPU module:
http://compulab.co.il/products/sbcs/sbc-t3517/
http://compulab.co.il/products/sbcs/sbc-t3730/
So let's add a common omap3-sb-t35.dtsi and then separate SoC
specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
omap3-sbc-t3517.dts.
I've tested this with SBC-T3730 as that's the only one I have.
At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
work.
Note that WLAN seems to be different for SBC-T3530. And SBC-T3517
may need some changes for the EMAC Ethernet if that's used
instead of the smsc911x.
Cc: devicet...@vger.kernel.org
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile| 3 +
arch/arm/boot/dts/omap3-sb-t35.dtsi | 135 ++
arch/arm/boot/dts/omap3-sbc-t3517.dts | 18 +
arch/arm/boot/dts/omap3-sbc-t3530.dts | 18 +
arch/arm/boot/dts/omap3-sbc-t3730.dts | 130
arch/arm/mach-omap2/pdata-quirks.c| 7 ++
6 files changed, 311 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-sb-t35.dtsi
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3730.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fc37bca..41370d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -179,6 +179,9 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap2420-n810-wimax.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
+ omap3-sbc-t3530.dtb \
+ omap3-sbc-t3730.dtb \
+ omap3-sbc-t3517.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi
b/arch/arm/boot/dts/omap3-sb-t35.dtsi
new file mode 100644
index 000..fc676c5
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -0,0 +1,135 @@
+/*
+ * Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
SBC-T3730
+ */
+
+/ {
+ aliases {
+ ethernet0 = smsc1;
+ ethernet1 = smsc2;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ ledb {
+ label = cm-t35:green;
+ gpios = gpio6 26 GPIO_ACTIVE_HIGH; /* gpio186 */
+ linux,default-trigger = heartbeat;
+ };
+ };
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x0100,
+4 0 0x2d00 0x0100;
+
+ smsc1: ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ interrupt-parent = gpio6;
+ interrupts = 3 IRQ_TYPE_LEVEL_LOW;
+ reg = 5 0 0xff;
+ bank-width = 2;
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+ vddvario-supply = vddvario;
+ vdd33a-supply = vdd33a;
+ reg-io-width = 4;
+ smsc,save-mac-address;
+ };
+
+ smsc2: ethernet@4,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ interrupt-parent = gpio3;
+ interrupts = 1 IRQ_TYPE_LEVEL_LOW;
+ reg = 4 0 0xff;
+ bank-width = 2;
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+
Re: [GIT PULL] make mach-omap2 boot with device tree only for v3.14
* Tony Lindgren t...@atomide.com [131210 15:08]: * Tony Lindgren t...@atomide.com [131210 11:28]: * Tony Lindgren t...@atomide.com [131210 11:00]: * Paul Walmsley p...@pwsan.com [131210 10:47]: On Mon, 9 Dec 2013, Tony Lindgren wrote: The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) The description in Tony's pull request below alludes to what regressions will occur when this is pulled. But just to state it in terms of what happened on the local testbed here when I tried it: - CM-T3517 booting will break since there's no .dts file for it. Are there other boards that will be affected here too? Yeah the cm-t3770 is on my todo list, but I've left it last as it's my home router and has been behaving quite nicely. That should then cover: SBC-T3530 http://compulab.co.il/products/sbcs/sbc-t3530/ SBC-T3517 http://compulab.co.il/products/sbcs/sbc-t3517/ SBC-T3730 http://compulab.co.il/products/sbcs/sbc-t3730/ They all seem to have the same baseboard, and the CPU module is different. So getting the 3530 and 3517 variants working should be trivial. I don't have 3530 or 3517 variants, so somebody else will need to do those two. OK posted a patch for the SBC-T3730 with minimal support also for SBC-3530 and SBC-3517 that should boot far enough to start adding more devices. Paul, care to try it on the CM-T3517, the patch is: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730 Let's hope there's two smsc911x devices also on the 3517 based board, otherwise it should have a completely separate .dts file. And Nishant just posted a .dts file for the 3517 craneboard. And here's a list of other boards we don't have .dts file for if people have these: board-devkit8000.c omap3-ldp.dts or omap3-beagle.dts is a good starting point Oops, sorry this one we already have covered with omap3-devkit8000.dts. And please ignore the multiple comments, they all are pretty close to omap3-ldp and omap3-beagle. board-omap3logic.c omap3-ldp.dts or omap3-beagle.dts is a good starting point board-omap3pandora.comap3-ldp.dts or omap3-beagle.dts is a good starting point board-omap3stalker.c board-omap3touchbook.c For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting points. There's the DPI display pdata patch too, but it seems we want to wait to see if Tomi gets his display changes done before applying that. I don't have any of the ones above, so people using those please do the .dts files ASAP. Or send me those boards with working boot loaders and I'll do them at a rate of one board per day or so.. And then you're stuck with my criteria of usable which is usually serial port and NFS root unless I really like the board, mhuwahuhh! board-ti8168evm.c I doubt ti8168evm has even worked for a long time.. It's in pretty sorry state unfortunately with missing clock support and missing handle_irq entry in the board-ti8168evm.c. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
On Fri, Dec 13, 2013 at 10:04:38AM -0600, Kwok, WingMan wrote: Hello -Original Message- From: Shilimkar, Santosh Sent: Thursday, December 12, 2013 7:29 PM To: Balbi, Felipe Cc: Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung-...@vger.kernel.org; Linux OMAP Mailing List; Kwok, WingMan Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I have tested the patch and the keystone usb driver continues to function, though I can't test suspend at this time as the rest of the system does not that functionality yet. Thanks, should I add your Tested-by ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support
On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
Hi Felipe,
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
return 0;
}
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+ return clk_enable(exynos-clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).
I don't get what you mean but there is something that probably needs
fixing, I guess below makes it better:
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index c93919a..1e5720a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (pm_runtime_suspended(dev))
+ return 0;
+
return __dwc3_exynos_suspend(exynos);
}
Is that what you meant ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support
On Fri, Dec 13, 2013 at 01:56:18PM -0600, Felipe Balbi wrote:
On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
Hi Felipe,
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
return 0;
}
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+ return clk_enable(exynos-clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).
I don't get what you mean but there is something that probably needs
fixing, I guess below makes it better:
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index c93919a..1e5720a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (pm_runtime_suspended(dev))
+ return 0;
+
return __dwc3_exynos_suspend(exynos);
}
Is that what you meant ?
note, however, that this is *not* a case where we would fall today. See
that we pm_runtime_get() in probe and only pm_runtime_put() during
remove. So there would never be a case where we would try system suspend
while device was already runtime suspended.
I have fixed all patches in my testing/next branch anyway, just to make
sure we're idiot-proof when it comes to implementing real runtime pm
later on :-)
cheers
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
-Original Message- From: Balbi, Felipe Sent: Friday, December 13, 2013 2:55 PM To: Kwok, WingMan Cc: Shilimkar, Santosh; Balbi, Felipe; Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung- s...@vger.kernel.org; Linux OMAP Mailing List Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Fri, Dec 13, 2013 at 10:04:38AM -0600, Kwok, WingMan wrote: Hello -Original Message- From: Shilimkar, Santosh Sent: Thursday, December 12, 2013 7:29 PM To: Balbi, Felipe Cc: Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung-...@vger.kernel.org; Linux OMAP Mailing List; Kwok, WingMan Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I have tested the patch and the keystone usb driver continues to function, though I can't test suspend at this time as the rest of the system does not that functionality yet. Thanks, should I add your Tested-by ? Yes please. Thanks WingMan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
On Fri, Dec 13, 2013 at 02:18:42PM -0600, Kwok, WingMan wrote: -Original Message- From: Balbi, Felipe Sent: Friday, December 13, 2013 2:55 PM To: Kwok, WingMan Cc: Shilimkar, Santosh; Balbi, Felipe; Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung- s...@vger.kernel.org; Linux OMAP Mailing List Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Fri, Dec 13, 2013 at 10:04:38AM -0600, Kwok, WingMan wrote: Hello -Original Message- From: Shilimkar, Santosh Sent: Thursday, December 12, 2013 7:29 PM To: Balbi, Felipe Cc: Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung-...@vger.kernel.org; Linux OMAP Mailing List; Kwok, WingMan Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I have tested the patch and the keystone usb driver continues to function, though I can't test suspend at this time as the rest of the system does not that functionality yet. Thanks, should I add your Tested-by ? Yes please. you need to reply with Tested-by: Your Name your.em...@domain.com just to make it all official. Sorry -- balbi signature.asc Description: Digital signature
RE: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
-Original Message- From: Balbi, Felipe Sent: Friday, December 13, 2013 3:23 PM To: Kwok, WingMan Cc: Balbi, Felipe; Shilimkar, Santosh; Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung- s...@vger.kernel.org; Linux OMAP Mailing List Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Fri, Dec 13, 2013 at 02:18:42PM -0600, Kwok, WingMan wrote: -Original Message- From: Balbi, Felipe Sent: Friday, December 13, 2013 2:55 PM To: Kwok, WingMan Cc: Shilimkar, Santosh; Balbi, Felipe; Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux- samsung- s...@vger.kernel.org; Linux OMAP Mailing List Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Fri, Dec 13, 2013 at 10:04:38AM -0600, Kwok, WingMan wrote: Hello -Original Message- From: Shilimkar, Santosh Sent: Thursday, December 12, 2013 7:29 PM To: Balbi, Felipe Cc: Linux USB Mailing List; kgene@samsung.com; Linux ARM Kernel Mailing List; linux-samsung-...@vger.kernel.org; Linux OMAP Mailing List; Kwok, WingMan Subject: Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I have tested the patch and the keystone usb driver continues to function, though I can't test suspend at this time as the rest of the system does not that functionality yet. Thanks, should I add your Tested-by ? Yes please. you need to reply with Tested-by: Your Name your.em...@domain.com just to make it all official. Sorry Yes, you can add Tested-by: WingMan Kwok w-kw...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3: Pinmux: DT: missing irq domain
Hi, I get the stacktrace from below two times during booting my Nokia N900 via DT. Everything seems to work, but its annoying. [0.279571] irq: no irq domain found for /ocp/pinmux@48002030 ! [0.285827] [ cut here ] [0.290710] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x114/0x158() [0.299621] Modules linked in: [0.302856] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc2+ #477 [0.309753] [c00158b4] (unwind_backtrace+0x0/0xe0) from [c0011b24] (show_stack+0x10/0x14) [0.318695] [c0011b24] (show_stack+0x10/0x14) from [c051e9f8] (dump_stack+0x68/0x84) [0.327178] [c051e9f8] (dump_stack+0x68/0x84) from [c003db64] (warn_slowpath_common+0x64/0x88) [0.336547] [c003db64] (warn_slowpath_common+0x64/0x88) from [c003dba0] (warn_slowpath_null+0x18/0x1c) [0.346618] [c003dba0] (warn_slowpath_null+0x18/0x1c) from [c03b4254] (of_device_alloc+0x114/0x158) [0.356445] [c03b4254] (of_device_alloc+0x114/0x158) from [c03b42c8] (of_platform_device_create_pdata+0x30/0x8c) [0.367401] [c03b42c8] (of_platform_device_create_pdata+0x30/0x8c) from [c03b440c] (of_platform_bus_create+0xe8/0x168) [0.378936] [c03b440c] (of_platform_bus_create+0xe8/0x168) from [c03b4458] (of_platform_bus_create+0x134/0x168) [0.389801] [c03b4458] (of_platform_bus_create+0x134/0x168) from [c03b44e8] (of_platform_populate+0x5c/0x8c) [0.400451] [c03b44e8] (of_platform_populate+0x5c/0x8c) from [c075b5c0] (pdata_quirks_init+0x2c/0x70) [0.410430] [c075b5c0] (pdata_quirks_init+0x2c/0x70) from [c074e648] (customize_machine+0x1c/0x40) [0.420166] [c074e648] (customize_machine+0x1c/0x40) from [c0008920] (do_one_initcall+0x98/0x140) [0.429779] [c0008920] (do_one_initcall+0x98/0x140) from [c074cc64] (kernel_init_freeable+0x16c/0x23c) [0.439880] [c074cc64] (kernel_init_freeable+0x16c/0x23c) from [c051a520] (kernel_init+0x8/0x100) [0.449523] [c051a520] (kernel_init+0x8/0x100) from [c000dfb8] (ret_from_fork+0x14/0x3c) [0.458374] ---[ end trace 9ca308e4d03a2990 ]--- -- Sebastian signature.asc Description: Digital signature
Re: OMAP3: Pinmux: DT: missing irq domain
* Sebastian Reichel s...@ring0.de [131213 13:30]: Hi, I get the stacktrace from below two times during booting my Nokia N900 via DT. Everything seems to work, but its annoying. [0.279571] irq: no irq domain found for /ocp/pinmux@48002030 ! [0.285827] [ cut here ] [0.290710] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x114/0x158() [0.299621] Modules linked in: [0.302856] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc2+ #477 [0.309753] [c00158b4] (unwind_backtrace+0x0/0xe0) from [c0011b24] (show_stack+0x10/0x14) [0.318695] [c0011b24] (show_stack+0x10/0x14) from [c051e9f8] (dump_stack+0x68/0x84) [0.327178] [c051e9f8] (dump_stack+0x68/0x84) from [c003db64] (warn_slowpath_common+0x64/0x88) [0.336547] [c003db64] (warn_slowpath_common+0x64/0x88) from [c003dba0] (warn_slowpath_null+0x18/0x1c) [0.346618] [c003dba0] (warn_slowpath_null+0x18/0x1c) from [c03b4254] (of_device_alloc+0x114/0x158) [0.356445] [c03b4254] (of_device_alloc+0x114/0x158) from [c03b42c8] (of_platform_device_create_pdata+0x30/0x8c) [0.367401] [c03b42c8] (of_platform_device_create_pdata+0x30/0x8c) from [c03b440c] (of_platform_bus_create+0xe8/0x168) [0.378936] [c03b440c] (of_platform_bus_create+0xe8/0x168) from [c03b4458] (of_platform_bus_create+0x134/0x168) [0.389801] [c03b4458] (of_platform_bus_create+0x134/0x168) from [c03b44e8] (of_platform_populate+0x5c/0x8c) [0.400451] [c03b44e8] (of_platform_populate+0x5c/0x8c) from [c075b5c0] (pdata_quirks_init+0x2c/0x70) [0.410430] [c075b5c0] (pdata_quirks_init+0x2c/0x70) from [c074e648] (customize_machine+0x1c/0x40) [0.420166] [c074e648] (customize_machine+0x1c/0x40) from [c0008920] (do_one_initcall+0x98/0x140) [0.429779] [c0008920] (do_one_initcall+0x98/0x140) from [c074cc64] (kernel_init_freeable+0x16c/0x23c) [0.439880] [c074cc64] (kernel_init_freeable+0x16c/0x23c) from [c051a520] (kernel_init+0x8/0x100) [0.449523] [c051a520] (kernel_init+0x8/0x100) from [c000dfb8] (ret_from_fork+0x14/0x3c) [0.458374] ---[ end trace 9ca308e4d03a2990 ]--- Yeah.. Please see this thread on LAKML: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
On Thursday 12 December 2013 07:43 PM, Felipe Balbi wrote: On Thu, Dec 12, 2013 at 07:29:24PM -0500, Santosh Shilimkar wrote: On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: A bare-minimum PM implementation which will server as building block for more complex s/server/serve ;-) hah! :-) will fix in my branch. PM implementation in the future. At the least will not leave clocks on unnecessarily when e.g. a user write mem to /sys/power/state. Signed-off-by: Felipe Balbi ba...@ti.com --- improve error path a little bit. We will test this out. Thanks for the patch Felipe. I see Wingman already tested the patch. Feel free add, my ack if you need one... Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[SOLVED] Re: Cannot obtain needed commit when trying to clone?
oops, I'm very sorry. I had the wrong URL. Problem solved! -- 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
Cannot obtain needed commit when trying to clone?
Hey guys. I'm trying to grab v2.6.32.60 from http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git and I'm getting this sad little error: # git clone --reference /mnt/gentoo32/usr/src/linux-2.6.32.y --branch v2.6.32.60 http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git linux-omap-2.6.32.y Cloning into 'linux-omap-2.6.32.y'... error: Unable to find 811e7c87340b75dce5c488d9496075b00853942b under http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git Cannot obtain needed commit 811e7c87340b75dce5c488d9496075b00853942b while processing commit e942cc06e2d183975dd47d8da9e569316cb870ea. error: Fetch failed. Tried w/o a --reference and also tried to grab master, similar error: # git clone http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git linux-omap Cloning into 'linux-omap'... error: Unable to find 8bb9660418e05bb1845ac1a2428444d78e322cc7 under http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git Cannot obtain needed object 8bb9660418e05bb1845ac1a2428444d78e322cc7 while processing commit 9556974843c5a75c98a5e070c80b5bf7c304c85d. error: Fetch failed. Is there some type of server maintenance going on or is something broken? Any other clones out there where I can grab this from in the mean time? Thanks, Daniel -- 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/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-13 19:22, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [131213 07:49]:
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
mainline. What's their purpose, and how are they implemented on platforms
that make use of them ? Is the pinmux API an option ?
They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
That commit is not in the mainline. I'm talking about mainline.
v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
breaks DSI displays (just tested). It needs to be reverted (although the
HDMI parts can probably be removed).
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
We don't have any DT configured displays in the mainline.
pinctrl-single doesn't support the kind of register that contains the
DSI muxing. I don't know yet how that should be done. In any case, the
muxing via DT should've been added at the same time as removing the
muxing via platform callback in e30b06f4d5f000c31a77.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Only 4430sdp has a DSI display in the mainline. Those boards have DPI
displays.
Tomi
signature.asc
Description: OpenPGP digital signature
