Re: OMAP4 SDP regression...
Hi, On Mon, Mar 17, 2014 at 06:35:07PM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [140317 16:35]: There's been a couple of regressions on OMAP4430 SDP I've only recently noticed: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=1597 Configuring network interfaces... udhcpc (v1.9.1) started Sending discover... Sending discover... Sending discover... No lease, failing done. No link lights come up either. The hardware is fine because uboot manages to successfully tftp the kernel. It looks like it was working in -rc4+armsoc and -rc5+armsoc, but not -rc6+armsoc. From what I can see, nothing has changed in drivers/net/ethernet/micrel/ since rc5. I've been through the delta from 3.14-rc5, and I don't see anything obvious. Any ideas? Known problem? Seems like plain v3.14-rc6 fails for me while -rc5 works. Bisecting points to: 66fda75f regulator: core: Replace direct ops-disable usage Also verified that v3.14-rc6 with 66fda75f reverted also works. Markus Mark, any ideas? I just had a look into the specific dts 'omap4-sdp.dts'. It defines a 'vdd_eth' at the top of the file, which is a fixed regulator using gpios with 'regulator-boot-on'. This regulator is also passed to the ks8851 driver as vdd-supply. But this supply is not used in the driver. The problem may be that the fixed regulator was never enabled/disabled before my patch. As the network driver does not enable the regulator manually, it will be disabled by the regulator framework. A 'regulator-always-on' may help here. Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH v2 3/5] net: cpsw: Add control-module macid driver
Hi, On Mon, Mar 17, 2014 at 10:11:36AM -0700, Tony Lindgren wrote: Hi, * Markus Pargmann m...@pengutronix.de [140315 06:12]: This driver extracts the hardware macid from the control module of am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw to get the macid from within the processor. Few things have improved recently :) This can be now implemented in a much cleaner way using regmap against the already defined syscon node. For an example, see how the MMC PBIAS regulator is using regmap in Linux next: 11469e0bb1 (regulator: add pbias regulator support) cd042fe5c1 (ARM: dts: add pbias dt node) That avoids the problem of the tinkering with SoC specific registers that belong to another device. So please update this series for regmap, let's not add more mapping of system control module registers to the drivers. Thanks, I will have a look into this and update the series. Regards, Markus Regards, Tony -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH v2 3/5] net: cpsw: Add control-module macid driver
Hi Uwe, On Mon, Mar 17, 2014 at 10:05:08AM +0100, Uwe Kleine-König wrote: Hello Markus, On Sat, Mar 15, 2014 at 02:07:42PM +0100, Markus Pargmann wrote: This driver extracts the hardware macid from the control module of am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw to get the macid from within the processor. Signed-off-by: Markus Pargmann m...@pengutronix.de --- .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 32 + drivers/net/ethernet/ti/Kconfig| 1 + drivers/net/ethernet/ti/Makefile | 2 +- drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + 4 files changed, 172 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c diff --git a/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt new file mode 100644 index 000..4eb39f6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt @@ -0,0 +1,32 @@ +TI CPSW ctrl macid Devicetree bindings +-- + +Required properties: + - compatible : Should be ti,am3352-cpsw-ctrl-macid this is called am3352-..., still you add it (in patch 5) to am33xx.dtsi and in the commit log you wrote about am335x. Looks abstruse. This is of course for the whole am335x series. But as the cpsw phy_sel driver already uses ti,am3352-cpsw-phy-sel as compatible, I didn't want to create more confusion about the bindings and stick with a similar compatible pattern. + - reg : physical base address and size of the cpsw + registers map + - reg-names : names of the register map given in reg node + - #ti,mac-address-ctrl-cells : Should be 1 Would be sensible to drop this property, or at least let it default to 1 if missing? I would actually prefer to have this property here. But I will implement a default value for this in the driver. Thanks, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP5: DSS hwmod data
Hi Tomi,
Thank you a lot for your assistance.
Here are my relevant DT nodes:
/ {
aliases {
display0 = hdmi0;
};
hdmi0: connector@0 {
compatible = hdmi-connector;
label = hdmi;
type = b;
hdmi_connector_in: endpoint {
remote-endpoint = hdmi_out;
};
};
};
dss {
status = ok;
};
hdmi {
status = ok;
vdda-supply = ldo4_reg;
pinctrl-names = default;
pinctrl-0 = dss_hdmi_pins;
hdmi_out: endpoint {
remote-endpoint = hdmi_connector_in;
};
};
I have the following kernel crash (caused by missing .detect callback):
[ 10.885320] Unable to handle kernel NULL pointer dereference at
virtual address
[ 10.893825] pgd = ed787240
[ 10.896670] [] *pgd=
[ 10.900427] Internal error: Oops: 8205 [#1] SMP ARM
[ 10.905883] Modules linked in: phy_omap_usb2 omapdrm(+)
drm_kms_helper connector_hdmi omap4_keypad matrix_keymap omapdss
fb_sys_fops omap_ocp2scp rtc_palmas spi_omap2_mcspi
[ 10.922032] CPU: 1 PID: 333 Comm: modprobe Tainted: G W
3.14.0-rc4-cm-t54-test-suit+ #111
[ 10.931486] task: ece1e040 ti: ecea2000 task.ti: ecea2000
[ 10.937122] PC is at 0x0
[ 10.939771] LR is at hdmic_detect+0x14/0x18 [connector_hdmi]
[ 10.945681] pc : []lr : [bf1531c4]psr: a013
[ 10.945681] sp : ecea3d50 ip : bf173158 fp :
[ 10.957664] r10: 0800 r9 : 0800 r8 : 0004
[ 10.963118] r7 : bf17317c r6 : ecdf0400 r5 : ed6d4000 r4 : ed6d402c
[ 10.969932] r3 : r2 : bf15c7cc r1 : bf0437d0 r0 : bf059470
[ 10.976754] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 10.984207] Control: 30c5387d Table: ad787240 DAC:
[ 10.990209] Process modprobe (pid: 333, stack limit = 0xecea2248)
[ 10.996574] Stack: (0xecea3d50 to 0xecea4000)
[ 11.001123] 3d40: bf1531b0
bf16a134 bf16a118 bf158abc
[ 11.009664] 3d60: 0004 c0b5ae60 0001 ece4ae00
0800 0800
[ 11.018203] 3d80: bf17a000 0020 bf15b7b8 0020
ece4ae00 ece4ae00 ecdf0400
[ 11.026751] 3da0: ed69b940 bf175978 bf16bfa4 081f
ecdf0400 ed69b940
[ 11.035288] 3dc0: bf167bbc
ecdf0400
[ 11.043828] 3de0: c03afef8 c0a876a0 bf17586c ecdf0400
c03b179c c08dffd4 c01d641c
[ 11.052365] 3e00: c03b1818 c0978eac c0a876b0 bf175978 c0a876b0
c03cc6c4 c03cc6ac c0b5af2c
[ 11.060902] 3e20: bf175978 c03ca8cc c0a876b0 bf175978 c0a876e4
c0020f04 c03cab64
[ 11.069442] 3e40: c0a876b0 bf175978 c03cac08 bf175978
c03cab7c c03c92dc
[ 11.077983] 3e60: edcd45dc eddcb234 bf175978 ece13480 c0ab8d48
c03ca1b8 bf1740d4 c0020f04
[ 11.086524] 3e80: bf175978 bf175978 ecea2000
c03cb264 c03cbd54 c0a7e510
[ 11.095067] 3ea0: ecea2000 c0008788 00d0 f02aefff
c0158bc0 c0003020 f02af000
[ 11.103608] 3ec0: bf175b24 c0a93b14 0001
bf175b24
[ 11.112156] 3ee0: 0001 c00dc9ec c00dcdbc fffb
c072932c c0a92348
[ 11.120702] 3f00: c0a92348 bf175b24 c0072830
bd94362e bf175b24
[ 11.129244] 3f20: 00400100 ecea2000 0080 c0020f04 ecea2000
c07137b4
[ 11.137785] 3f40: 0001dfea b6d5b000 b6fa7114 0001dfea b6d5b000
c00bad0c f029 0001dfea
[ 11.146323] 3f60: f02a29bc f02a2821 f02ab674 ecf0 00010510
[ 11.154860] 3f80: 0027 0028 001c 0020 0012
b87d23f8 0006
[ 11.163409] 3fa0: b87d2280 c0020d80 b87d23f8 0006 b6d5b000
0001dfea b6fa7114 b6d5b000
[ 11.171954] 3fc0: b87d23f8 0006 b87d2280 0080 b87d4c60
0001dfea b6fa7114
[ 11.180494] 3fe0: bee169cc b6f9e190 b6f02e04 6010
b6d5b000
[ 11.189071] [bf1531c4] (hdmic_detect [connector_hdmi]) from
[bf16a134] (omap_connector_detect+0x1c/0x58 [omapdrm])
[ 11.200274] [bf16a134] (omap_connector_detect [omapdrm]) from
[bf158abc] (drm_helper_probe_single_connector_modes+0x2b0/0x33c
[drm_kms_helper])
[ 11.214089] [bf158abc] (drm_helper_probe_single_connector_modes
[drm_kms_helper]) from [bf15b7b8]
(drm_fb_helper_initial_config+0x5c/0xac [drm_kms_helper])
[ 11.229011] [bf15b7b8] (drm_fb_helper_initial_config
[drm_kms_helper]) from [bf16bfa4] (omap_fbdev_init+0x90/0xc4 [omapdrm])
[ 11.241126] [bf16bfa4] (omap_fbdev_init [omapdrm]) from
[bf167bbc] (dev_load+0xcc/0x148 [omapdrm])
[ 11.250861] [bf167bbc] (dev_load [omapdrm]) from [c03afef8]
(drm_dev_register+0x78/0x138)
[ 11.259776] [c03afef8] (drm_dev_register) from [c03b179c]
(drm_get_platform_dev+0x50/0xa4)
[ 11.268785] [c03b179c] (drm_get_platform_dev) from [c03cc6c4]
Re: pandaboard boot crash with linux-next
On 03/17/2014 04:09 PM, Tomi Valkeinen wrote: Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. I did not taken crash log but the same linux-next fails to boot on am335x-evmsk as well. Tomi [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck [0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk [0.00] Unable to handle kernel NULL pointer dereference at virtual address 004c [0.00] pgd = c0004000 [0.00] [004c] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc6-next-20140317-09382-g8808b950581f #104 [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 [0.00] PC is at kernfs_find_ns+0x14/0x13c [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 [0.00] pc : [c019607c]lr : [c019628c]psr: 61d3 [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) [0.00] Stack: (0xc0883e00 to 0xc0884000) [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 ebfcd464 [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 c07c1814 ebfcd490 [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 ebfcd490 0001 [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 c0883e9c [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 c04c7c9c c04c72cc [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 c0883ee4 c0883ec8 [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 c0883f54 c0883ee8 [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 c0883f14 c0883f08 [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 c074dcc8 c074de24 [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 0001 c0883f68 [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 c0825250 c0824f1c [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 c081d67c c08253fc [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664 c08195d0 [0.00] 3fc0: c086ad60 10c5387d c088a92c c086ad5c c088f684 8000406a [0.00] 3fe0: 412fc09a c0883ff8 80008074 c0819840 [0.00] Backtrace: [0.00] [c0196068] (kernfs_find_ns) from [c019628c] (kernfs_find_and_get_ns+0x38/0x54) [0.00] r8:ebfcd464 r7: r6: r5:c07c1814 r4:c08e9ad8 [0.00] [c0196254] (kernfs_find_and_get_ns) from [c04c6180] (safe_name+0x2c/0x98) [0.00] r7:ebfcd490 r6:c07c1814 r5: r4:c07c1814 [0.00] [c04c6154] (safe_name) from [c04c7308] (__of_add_property_sysfs+0x48/0xc4) [0.00] r7:0001 r6:ebfcd490 r5:c07c1814 r4:c0891140 [0.00] [c04c72c0] (__of_add_property_sysfs) from [c04c7c9c] (of_add_property+0x94/0xa0) [0.00] r8:a1d3 r7:ebfcd464 r6:c0891140 r5:c07c1814 r4: [0.00] [c04c7c08] (of_add_property) from [c0824b70] (omap_get_timer_dt+0x64/0x108) [0.00] r8:c074de24 r7:0001 r6:c086bf64 r5:c074dcc8 r4:ebfcd464 r3:c0882000 [0.00] [c0824b0c] (omap_get_timer_dt) from [c0824c58] (omap_dm_timer_init_one+0x44/0x2fc) [0.00] r6:c074dcc8 r5: r4:c0938af8 r3:c0891114 [0.00] [c0824c14] (omap_dm_timer_init_one) from [c0824f5c] (omap2_gp_clockevent_init+0x4c/0xd0) [0.00] r10:c088a880 r8:c086ad60 r7:c074de24 r6:c074dcc8 r5:c08910c0 r4:c0938af8 [0.00] [c0824f10] (omap2_gp_clockevent_init) from [c0825250] (omap4_sync32k_timer_init+0x24/0x60) [0.00] r7: r6:c0882000 r5:c09380c0 r4:0001 [0.00] [c082522c] (omap4_sync32k_timer_init) from [c0825400] (omap4_local_timer_init+0x10/0x68) [0.00] [c08253f0] (omap4_local_timer_init) from [c081d67c] (time_init+0x24/0x38) [0.00] [c081d658] (time_init) from [c0819a30] (start_kernel+0x1fc/0x390) [0.00] [c0819834] (start_kernel) from [80008074]
Re: [PATCH] ARM: OMAP5: DSS hwmod data
On 18/03/14 10:19, Dmitry Lifshitz wrote:
Hi Tomi,
Thank you a lot for your assistance.
Here are my relevant DT nodes:
/ {
aliases {
display0 = hdmi0;
};
hdmi0: connector@0 {
compatible = hdmi-connector;
label = hdmi;
type = b;
hdmi_connector_in: endpoint {
remote-endpoint = hdmi_out;
};
};
};
dss {
status = ok;
};
hdmi {
status = ok;
vdda-supply = ldo4_reg;
pinctrl-names = default;
pinctrl-0 = dss_hdmi_pins;
hdmi_out: endpoint {
remote-endpoint = hdmi_connector_in;
};
};
The above looks fine.
I have the following kernel crash (caused by missing .detect callback):
Yes, it seems the hdmi driver is missing detect, as there's no support
in there for the detection at the moment. You can add the function to
omap5.c, and return true always.
How does the HPD work on your board? On uevm, the ESD/Level shifter chip
handles HPD, which is the only supported way at the moment.
While using FBDEV I have the following issue:
root@cm-debian:~# modprobe omapfb
[ 27.524419] [ cut here ]
[ 27.529256] WARNING: CPU: 1 PID: 2087 at
/home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492
__alloc_pages_nodemask+0x268/0x83c()
[ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt
cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2
connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp
rtc_palmas spi_omap2_mcspi
[ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W
3.14.0-rc4-cm-t54-test-suit+ #108
[ 27.572677] [c00280ac] (unwind_backtrace) from [c0024eb0]
(show_stack+0x10/0x14)
[ 27.580786] [c0024eb0] (show_stack) from [c06fc434]
(dump_stack+0x70/0x88)
[ 27.588341] [c06fc434] (dump_stack) from [c004d8e8]
(warn_slowpath_common+0x70/0x88)
[ 27.596815] [c004d8e8] (warn_slowpath_common) from [c004d91c]
(warn_slowpath_null+0x1c/0x24)
[ 27.606004] [c004d91c] (warn_slowpath_null) from [c01135ec]
(__alloc_pages_nodemask+0x268/0x83c)
[ 27.615562] [c01135ec] (__alloc_pages_nodemask) from [c002cd78]
(__dma_alloc_buffer.isra.16+0x2c/0xdc)
[ 27.625661] [c002cd78] (__dma_alloc_buffer.isra.16) from
[c002ce40] (__alloc_remap_buffer.isra.19+0x18/0xcc)
[ 27.636300] [c002ce40] (__alloc_remap_buffer.isra.19) from
[c002d248] (__dma_alloc+0x110/0x138)
[ 27.645757] [c002d248] (__dma_alloc) from [c002d3fc]
(arm_dma_alloc+0xb0/0xd8)
[ 27.653686] [c002d3fc] (arm_dma_alloc) from [bf1b1f74]
(omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb])
[ 27.663911] [bf1b1f74] (omapfb_alloc_fbmem.isra.24 [omapfb]) from
[bf1b7078] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb])
[ 27.676759] [bf1b7078] (omapfb_alloc_fbmem_display.isra.25
[omapfb]) from [bf1b21fc] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb])
[ 27.689419] [bf1b21fc] (omapfb_allocate_all_fbs [omapfb]) from
[bf1b30f8] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb])
[ 27.701432] [bf1b30f8] (omapfb_create_framebuffers [omapfb]) from
[bf1b3fdc] (omapfb_probe+0x28c/0x41c [omapfb])
[ 27.712446] [bf1b3fdc] (omapfb_probe [omapfb]) from [c03ab844]
(platform_drv_probe+0x18/0x48)
[ 27.721728] [c03ab844] (platform_drv_probe) from [c03a9a4c]
(really_probe+0x80/0x208)
[ 27.730284] [c03a9a4c] (really_probe) from [c03a9ce4]
(driver_probe_device+0x30/0x48)
[ 27.738834] [c03a9ce4] (driver_probe_device) from [c03a9d88]
(__driver_attach+0x8c/0x90)
[ 27.747661] [c03a9d88] (__driver_attach) from [c03a845c]
(bus_for_each_dev+0x54/0x88)
[ 27.756220] [c03a845c] (bus_for_each_dev) from [c03a9338]
(bus_add_driver+0xe4/0x1d8)
[ 27.764778] [c03a9338] (bus_add_driver) from [c03aa3e4]
(driver_register+0x78/0xf4)
[ 27.773148] [c03aa3e4] (driver_register) from [c0008788]
(do_one_initcall+0x44/0x174)
[ 27.781703] [c0008788] (do_one_initcall) from [c06f2934]
(do_init_module+0x48/0x17c)
[ 27.790172] [c06f2934] (do_init_module) from [c00bad0c]
(SyS_init_module+0x64/0x6c)
[ 27.798546] [c00bad0c] (SyS_init_module) from [c0020d80]
(ret_fast_syscall+0x0/0x30)
[ 27.807015] ---[ end trace 842d286115ab739d ]---
[ 27.811849] omapfb omapfb: failed to allocate framebuffer
[ 27.817490] omapfb omapfb: failed to allocate fbmem
[ 27.822746] omapfb omapfb: failed to setup omapfb
[ 27.827710] omapfb: probe of omapfb failed with error -12
Hmm, do you have CMA enabled? Maybe something like:
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_CMA_SIZE_SEL_MBYTES=y
And if you have omap5-uevm, you could first try that one to see if you
get the branch working.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: pandaboard boot crash with linux-next
On 03/18/2014 10:32 AM, Peter Ujfalusi wrote: On 03/17/2014 04:09 PM, Tomi Valkeinen wrote: Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. I did not taken crash log but the same linux-next fails to boot on am335x-evmsk as well. Looks like someone broke gptimer or alternatively some of the DT support routines. a call to of_add_property() is causing the crash. -Tero Tomi [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck [0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk [0.00] Unable to handle kernel NULL pointer dereference at virtual address 004c [0.00] pgd = c0004000 [0.00] [004c] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc6-next-20140317-09382-g8808b950581f #104 [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 [0.00] PC is at kernfs_find_ns+0x14/0x13c [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 [0.00] pc : [c019607c]lr : [c019628c]psr: 61d3 [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) [0.00] Stack: (0xc0883e00 to 0xc0884000) [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 ebfcd464 [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 c07c1814 ebfcd490 [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 ebfcd490 0001 [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 c0883e9c [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 c04c7c9c c04c72cc [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 c0883ee4 c0883ec8 [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 c0883f54 c0883ee8 [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 c0883f14 c0883f08 [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 c074dcc8 c074de24 [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 0001 c0883f68 [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 c0825250 c0824f1c [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 c081d67c c08253fc [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664 c08195d0 [0.00] 3fc0: c086ad60 10c5387d c088a92c c086ad5c c088f684 8000406a [0.00] 3fe0: 412fc09a c0883ff8 80008074 c0819840 [0.00] Backtrace: [0.00] [c0196068] (kernfs_find_ns) from [c019628c] (kernfs_find_and_get_ns+0x38/0x54) [0.00] r8:ebfcd464 r7: r6: r5:c07c1814 r4:c08e9ad8 [0.00] [c0196254] (kernfs_find_and_get_ns) from [c04c6180] (safe_name+0x2c/0x98) [0.00] r7:ebfcd490 r6:c07c1814 r5: r4:c07c1814 [0.00] [c04c6154] (safe_name) from [c04c7308] (__of_add_property_sysfs+0x48/0xc4) [0.00] r7:0001 r6:ebfcd490 r5:c07c1814 r4:c0891140 [0.00] [c04c72c0] (__of_add_property_sysfs) from [c04c7c9c] (of_add_property+0x94/0xa0) [0.00] r8:a1d3 r7:ebfcd464 r6:c0891140 r5:c07c1814 r4: [0.00] [c04c7c08] (of_add_property) from [c0824b70] (omap_get_timer_dt+0x64/0x108) [0.00] r8:c074de24 r7:0001 r6:c086bf64 r5:c074dcc8 r4:ebfcd464 r3:c0882000 [0.00] [c0824b0c] (omap_get_timer_dt) from [c0824c58] (omap_dm_timer_init_one+0x44/0x2fc) [0.00] r6:c074dcc8 r5: r4:c0938af8 r3:c0891114 [0.00] [c0824c14] (omap_dm_timer_init_one) from [c0824f5c] (omap2_gp_clockevent_init+0x4c/0xd0) [0.00] r10:c088a880 r8:c086ad60 r7:c074de24 r6:c074dcc8 r5:c08910c0 r4:c0938af8 [0.00] [c0824f10] (omap2_gp_clockevent_init) from [c0825250] (omap4_sync32k_timer_init+0x24/0x60) [0.00] r7: r6:c0882000 r5:c09380c0 r4:0001 [0.00] [c082522c] (omap4_sync32k_timer_init) from [c0825400] (omap4_local_timer_init+0x10/0x68) [0.00] [c08253f0] (omap4_local_timer_init) from [c081d67c] (time_init+0x24/0x38) [0.00] [c081d658] (time_init) from
[RFC PATCH 0/2] Sil9022 DPI to HDMI Encoder
This patch series adds the Silicon Image Sil9022 driver. Sil9022 is HDMI Transmitter compliant to HDMI 1.2a and DVI 1.0. It supports 1080p and UXGA. It has single slave I2C from Host, passing through to master I2C interface for DDC Connection. It provides Transmitter Programming Interface (TPI) for simplified API programming. Product brief: http://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf Current driver is tested on AM43x SOC. This series is on top of series posted to add DSS support on AM43x [2] [2] https://patchwork.kernel.org/patch/3822691/ This is initial driver supporting limited features. TODO - Audio Support Detailed Hot Plug event handling and also routing the hot plug event to host processor These features will be added in future. Sathya Prakash M R (2): OMAPDSS: Add Sil9022 DPI-HDMI Encoder Driver ARM: DTS: AM43x: Add sii9022 dt information arch/arm/boot/dts/am437x-gp-evm.dts| 58 +- arch/arm/boot/dts/am43x-epos-evm.dts | 59 +- drivers/video/omap2/displays-new/Kconfig |8 + drivers/video/omap2/displays-new/Makefile |1 + drivers/video/omap2/displays-new/encoder-sil9022.c | 748 drivers/video/omap2/displays-new/encoder-sil9022.h | 105 +++ 6 files changed, 973 insertions(+), 6 deletions(-) create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.c create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.h -- 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
[PATCH 2/2] ARM: DTS: AM43x: Add sii9022 dt information
AM43x-epos and AM437x-gp device use external sii9022
DPI to HDMI encoder.
Sii9022 use i2c for communication.
Sii9022 dt entries are added to corresponding dts.
Signed-off-by: Sathya prakash M R sath...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++--
arch/arm/boot/dts/am43x-epos-evm.dts | 59 --
2 files changed, 111 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a178e8d..c4225b1 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -51,6 +51,41 @@
remote-endpoint = dpi_out;
};
};
+
+ sii9022: encoder@0 {
+ compatible = sii,sii9022;
+ reset-gpio = gpio5 8 GPIO_ACTIVE_LOW;/* 'SelLCDorHDMI' Gpio,
LOW to select HDMI */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sil9022_out;
+ };
+ };
};
am43xx_pinmux {
@@ -119,6 +154,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
+ sii9022 {
+ reg = 0x3b;
+ }
};
epwmss0 {
@@ -141,8 +179,22 @@
pinctrl-names = default;
pinctrl-0 = dss_pinctrl;
- dpi_out: endpoint@0 {
- remote-endpoint = lcd_in;
- data-lines = 24;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ dpi_out: endpoint@0 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+
+ dpi_out:endpoint@1 {
+ remote-endpoint = sii9022_in;
+ data-lines = 24;
+
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 3f9643b..22bfa5e 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -29,6 +29,7 @@
aliases {
display0 = lcd0;
+ display1 = hdmi0;
};
lcd0: display {
@@ -54,6 +55,41 @@
};
};
+ sii9022: encoder@0 {
+ compatible = sii,sii9022;
+ reset-gpio = gpio2 1 GPIO_ACTIVE_LOW;/* 65'SelLCDorHDMI'
Gpio, LOW to select HDMI */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sil9022_out;
+ };
+ };
+
am43xx_pinmux: pinmux@44e10800 {
cpsw_default: cpsw_default {
pinctrl-single,pins =
@@ -284,6 +320,9 @@
pinctrl-names = default;
pinctrl-0 = i2c2_pins;
status = okay;
+ sii9022 {
+ reg = 0x3b;
+ }
};
gpio0 {
@@ -347,8 +386,22 @@
pinctrl-names = default;
pinctrl-0 = dss_pinctrl;
- dpi_out: endpoint@0 {
- remote-endpoint = lcd_in;
- data-lines = 24;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ dpi_out: endpoint@0 {
+
[PATCH 1/2] OMAPDSS: Add Sil9022 DPI-HDMI Encoder Driver
Sil9022 DPI to HDMI Encoder driver is part of
AM43xx SOC. Adding the basic Sil9022 driver
HPD and Audio support is not present yet.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
drivers/video/omap2/displays-new/Kconfig |8 +
drivers/video/omap2/displays-new/Makefile |1 +
drivers/video/omap2/displays-new/encoder-sil9022.c | 748
drivers/video/omap2/displays-new/encoder-sil9022.h | 105 +++
4 files changed, 862 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.c
create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.h
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index e6cfc38..9243dd7 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -12,6 +12,14 @@ config DISPLAY_ENCODER_TPD12S015
Driver for TPD12S015, which offers HDMI ESD protection and level
shifting.
+config DISPLAY_ENCODER_SIL9022
+tristate Sil9022 DPI to HDMI Encoder
+ depends on I2C
+ help
+ Driver for Silicon Image Sil9022 DPI to HDMI encoder and
+ a brief about Sil9022 can be found here:
+
http://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf
+
config DISPLAY_CONNECTOR_DVI
tristate DVI Connector
depends on I2C
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 0323a8a..f3c8997 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
+obj-$(CONFIG_DISPLAY_ENCODER_SIL9022) += encoder-sil9022.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
diff --git a/drivers/video/omap2/displays-new/encoder-sil9022.c
b/drivers/video/omap2/displays-new/encoder-sil9022.c
new file mode 100644
index 000..411867b
--- /dev/null
+++ b/drivers/video/omap2/displays-new/encoder-sil9022.c
@@ -0,0 +1,748 @@
+/*
+ * Silicon image Sil9022 DPI-to-HDMI encoder driver
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Sathya Prakash M R sath...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/of_gpio.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+#include encoder-sil9022.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+ struct i2c_client *i2c_client;
+ int reset_gpio;
+ int data_lines;
+ struct regmap *regmap;
+ struct omap_video_timings timings;
+};
+
+static struct regmap_config sil9022_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int sil9022_ddc_read(struct i2c_client *client,
+ unsigned char *buf, u16 count, u8 offset)
+{
+ int r, retries;
+
+ for (retries = 3; retries 0; retries--) {
+ struct i2c_msg msgs[] = {
+ {
+ .addr = 0x50,
+ .flags = 0,
+ .len= 1,
+ .buf= offset,
+ }, {
+ .addr = 0x50,
+ .flags = I2C_M_RD,
+ .len= count,
+ .buf= buf,
+ }
+ };
+
+ r = i2c_transfer(client-adapter, msgs, 2);
+ if (r == 2)
+ return 0;
+
+ if (r != -EAGAIN)
+ break;
+ }
+
+ return r 0 ? r : -EIO;
+}
+
+static int sil9022_hw_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+ u8 vals[8];
+ unsigned int val;
+ u16 xres;
+ u16 yres;
+ u16 pclk;
+
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_video_timings *hdmi_timings = ddata-timings;
+ struct i2c_client *sil9022_client = ddata-i2c_client;
+ struct regmap *map = ddata-regmap;
+
+
Re: [PATCH 2/2] ARM: DTS: AM43x: Add sii9022 dt information
On 18/03/14 12:07, Sathya Prakash M R wrote:
AM43x-epos and AM437x-gp device use external sii9022
DPI to HDMI encoder.
Sii9022 use i2c for communication.
Sii9022 dt entries are added to corresponding dts.
Signed-off-by: Sathya prakash M R sath...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++--
arch/arm/boot/dts/am43x-epos-evm.dts | 59
--
2 files changed, 111 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a178e8d..c4225b1 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -51,6 +51,41 @@
remote-endpoint = dpi_out;
};
};
+
+ sii9022: encoder@0 {
+ compatible = sii,sii9022;
See Documentation/devicetree/bindings/vendor-prefixes.txt
The vendor prefix is sil.
+ reset-gpio = gpio5 8 GPIO_ACTIVE_LOW;/* 'SelLCDorHDMI' Gpio,
LOW to select HDMI */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sil9022_out;
+ };
+ };
};
am43xx_pinmux {
@@ -119,6 +154,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
+ sii9022 {
+ reg = 0x3b;
+ }
This looks very very odd... The whole sii9022 node should be here.
};
epwmss0 {
@@ -141,8 +179,22 @@
pinctrl-names = default;
pinctrl-0 = dss_pinctrl;
- dpi_out: endpoint@0 {
- remote-endpoint = lcd_in;
- data-lines = 24;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ dpi_out: endpoint@0 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+
+ dpi_out:endpoint@1 {
+ remote-endpoint = sii9022_in;
+ data-lines = 24;
+
+ };
You add the same label, dpi_out to both endpoints. Does this even compile?
As there's just one port, you can leave out the 'ports' node.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 0/2] Sil9022 DPI to HDMI Encoder
On Tue, Mar 18, 2014 at 10:07:55AM +, Sathya Prakash M R wrote: This patch series adds the Silicon Image Sil9022 driver. Sil9022 is HDMI Transmitter compliant to HDMI 1.2a and DVI 1.0. It supports 1080p and UXGA. It has single slave I2C from Host, passing through to master I2C interface for DDC Connection. It provides Transmitter Programming Interface (TPI) for simplified API programming. Product brief: http://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf Current driver is tested on AM43x SOC. This series is on top of series posted to add DSS support on AM43x [2] [2] https://patchwork.kernel.org/patch/3822691/ This is initial driver supporting limited features. TODO - Audio Support Detailed Hot Plug event handling and also routing the hot plug event to host processor These features will be added in future. Sathya Prakash M R (2): OMAPDSS: Add Sil9022 DPI-HDMI Encoder Driver ARM: DTS: AM43x: Add sii9022 dt information arch/arm/boot/dts/am437x-gp-evm.dts| 58 +- arch/arm/boot/dts/am43x-epos-evm.dts | 59 +- drivers/video/omap2/displays-new/Kconfig |8 + drivers/video/omap2/displays-new/Makefile |1 + drivers/video/omap2/displays-new/encoder-sil9022.c | 748 drivers/video/omap2/displays-new/encoder-sil9022.h | 105 +++ 6 files changed, 973 insertions(+), 6 deletions(-) create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.c create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.h Is there already a binding document? If not, please add one. Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: DTS: AM43x: Add sii9022 dt information
On Tuesday 18 March 2014 04:01 PM, Tomi Valkeinen wrote:
On 18/03/14 12:07, Sathya Prakash M R wrote:
AM43x-epos and AM437x-gp device use external sii9022
DPI to HDMI encoder.
Sii9022 use i2c for communication.
Sii9022 dt entries are added to corresponding dts.
Signed-off-by: Sathya prakash M R sath...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++--
arch/arm/boot/dts/am43x-epos-evm.dts | 59 --
2 files changed, 111 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index a178e8d..c4225b1 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -51,6 +51,41 @@
remote-endpoint = dpi_out;
};
};
+
+ sii9022: encoder@0 {
+ compatible = sii,sii9022;
See Documentation/devicetree/bindings/vendor-prefixes.txt
The vendor prefix is sil.
My bad. that was typo.
+ reset-gpio = gpio5 8 GPIO_ACTIVE_LOW;/* 'SelLCDorHDMI' Gpio,
LOW to select HDMI */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sil9022_out;
+ };
+ };
};
am43xx_pinmux {
@@ -119,6 +154,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
+ sii9022 {
+ reg = 0x3b;
+ }
This looks very very odd... The whole sii9022 node should be here.
ok. i was also bit confused with this placement.
};
epwmss0 {
@@ -141,8 +179,22 @@
pinctrl-names = default;
pinctrl-0 = dss_pinctrl;
- dpi_out: endpoint@0 {
- remote-endpoint = lcd_in;
- data-lines = 24;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ dpi_out: endpoint@0 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+
+ dpi_out:endpoint@1 {
+ remote-endpoint = sii9022_in;
+ data-lines = 24;
+
+ };
You add the same label, dpi_out to both endpoints. Does this even compile?
As there's just one port, you can leave out the 'ports' node.
Will check. the ports was added as per documentation in video-interfaces.txt
Can you suggest how to add the 2 dpi_out endpoints?
Thanks
Tomi
Sathya
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: DTS: AM43x: Add sii9022 dt information
On 18/03/14 12:57, Sathya Prakash wrote:
You add the same label, dpi_out to both endpoints. Does this even
compile?
As there's just one port, you can leave out the 'ports' node.
Will check. the ports was added as per documentation in
video-interfaces.txt
It mentions that the 'ports' is optional.
Can you suggest how to add the 2 dpi_out endpoints?
Didn't try, but:
port {
#address-cells = 1;
#size-cells = 0;
dpi_lcd_out: endpoint@0 {
reg = 0;
remote-endpoint = lcd_in;
data-lines = 24;
};
dpi_sii_out: endpoint@1 {
reg = 1;
remote-endpoint = sii9022_in;
data-lines = 24;
};
};
However, we still need to handle the GPIO which is used to select the
LCD or HDMI. So, maybe the above works, but we should try the
encoder-gpio-switch to handle the GPIO, which we discussed about earlier.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] OMAPDSS: Add Sil9022 DPI-HDMI Encoder Driver
Hi Sathya,
On 18/03/14 12:07, Sathya Prakash M R wrote:
Sil9022 DPI to HDMI Encoder driver is part of
AM43xx SOC. Adding the basic Sil9022 driver
Umm it's not part of AM43xx SoC...
HPD and Audio support is not present yet.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
drivers/video/omap2/displays-new/Kconfig |8 +
drivers/video/omap2/displays-new/Makefile |1 +
drivers/video/omap2/displays-new/encoder-sil9022.c | 748
drivers/video/omap2/displays-new/encoder-sil9022.h | 105 +++
4 files changed, 862 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.c
create mode 100644 drivers/video/omap2/displays-new/encoder-sil9022.h
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index e6cfc38..9243dd7 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -12,6 +12,14 @@ config DISPLAY_ENCODER_TPD12S015
Driver for TPD12S015, which offers HDMI ESD protection and level
shifting.
+config DISPLAY_ENCODER_SIL9022
+tristate Sil9022 DPI to HDMI Encoder
Use a tab there.
+ depends on I2C
+ help
+ Driver for Silicon Image Sil9022 DPI to HDMI encoder and
+ a brief about Sil9022 can be found here:
+
http://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf
+
config DISPLAY_CONNECTOR_DVI
tristate DVI Connector
depends on I2C
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 0323a8a..f3c8997 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
+obj-$(CONFIG_DISPLAY_ENCODER_SIL9022) += encoder-sil9022.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
diff --git a/drivers/video/omap2/displays-new/encoder-sil9022.c
b/drivers/video/omap2/displays-new/encoder-sil9022.c
new file mode 100644
index 000..411867b
--- /dev/null
+++ b/drivers/video/omap2/displays-new/encoder-sil9022.c
@@ -0,0 +1,748 @@
+/*
+ * Silicon image Sil9022 DPI-to-HDMI encoder driver
The chip is SiI9022, not Sil, according to the specs from Silicon Image.
I'm not sure what would be the best naming all around, but at least in
the comments and Kconfig help texts it would be best to use the correct
names to help finding the chip with google.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Sathya Prakash M R sath...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/of_gpio.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+#include encoder-sil9022.h
You should quickly go though the includes, and remove unneeded ones.
There are no platform devices here, nor is video/omap-panel-data.h needed.
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+ struct i2c_client *i2c_client;
+ int reset_gpio;
+ int data_lines;
+ struct regmap *regmap;
+ struct omap_video_timings timings;
+};
+
+static struct regmap_config sil9022_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
Can this be const?
+
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int sil9022_ddc_read(struct i2c_client *client,
+ unsigned char *buf, u16 count, u8 offset)
+{
+ int r, retries;
+
+ for (retries = 3; retries 0; retries--) {
+ struct i2c_msg msgs[] = {
+ {
+ .addr = 0x50,
+ .flags = 0,
+ .len= 1,
+ .buf= offset,
+ }, {
+ .addr = 0x50,
+ .flags = I2C_M_RD,
+ .len= count,
+ .buf= buf,
+ }
+ };
+
+ r = i2c_transfer(client-adapter, msgs, 2);
+ if (r == 2)
+ return 0;
+
MEDDELELSER!
Emergency Information Din sikkerhed er vores højeste prioritet. Nylig opdagede vi en slags usædvanlig aktivitet på din e-mail-konto, som et resultat, alle e-mail brugere opfordres til at opgradere deres e-mail-konto inden for 24 timer efter modtagelse af e-mails ved hjælp af nedenstående link https://www.formstack.com/forms/?1706424-h5Lm7SzmaP til bekræfte, at din e-mail-adressen er opdateret med kravene af institutionen. Må ikke ignorere, Denne meddelelse med henblik på at undgå en afbrydelse af din webmail. Vi beklager ulejligheden, kan det medføre, men din konto sikkerhed og privatliv er meget vigtigt for os. Tak for dit samarbejde. Med venlig hilsen IT HELP DESK (C) Copyright (c) 2014 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node
This patch remove unnecessary function call in of_extcon_get_extcon_dev()
by using the name of device_node structure.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/extcon/of_extcon.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
index 72173ec..0a29f82 100644
--- a/drivers/extcon/of_extcon.c
+++ b/drivers/extcon/of_extcon.c
@@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
*dev, int index)
{
struct device_node *node;
struct extcon_dev *edev;
- struct platform_device *extcon_parent_dev;
if (!dev-of_node) {
dev_dbg(dev, device does not have a device node entry\n);
@@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
*dev, int index)
return ERR_PTR(-ENODEV);
}
- extcon_parent_dev = of_find_device_by_node(node);
- if (!extcon_parent_dev) {
- dev_dbg(dev, unable to find device by node\n);
- return ERR_PTR(-EPROBE_DEFER);
- }
-
- edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+ edev = extcon_get_extcon_dev(node-name);
if (!edev) {
- dev_dbg(dev, unable to get extcon device : %s\n,
- dev_name(extcon_parent_dev-dev));
+ dev_dbg(dev, unable to get extcon device : %s\n, node-name);
return ERR_PTR(-ENODEV);
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] extcon: Move OF helper function to extcon core and change function name
This patch move simply OF helper function to extcon core and change function
name as following:
- of_extcon_get_extcon_dev() - extcon_get_edev_by_phandle()
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/extcon/Kconfig | 4 ---
drivers/extcon/Makefile | 2 --
drivers/extcon/extcon-class.c| 43 ++
drivers/extcon/of_extcon.c | 56
drivers/usb/dwc3/dwc3-omap.c | 3 +--
include/linux/extcon.h | 12 +
include/linux/extcon/of_extcon.h | 31 --
7 files changed, 56 insertions(+), 95 deletions(-)
delete mode 100644 drivers/extcon/of_extcon.c
delete mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index bdb5a00..be56e8a 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -14,10 +14,6 @@ if EXTCON
comment Extcon Device Drivers
-config OF_EXTCON
- def_tristate y
- depends on OF
-
config EXTCON_GPIO
tristate GPIO extcon support
depends on GPIOLIB
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 43eccc0..bf7861e 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,8 +2,6 @@
# Makefile for external connector class (extcon) devices
#
-obj-$(CONFIG_OF_EXTCON)+= of_extcon.o
-
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 7632233..bc4c789 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -31,6 +31,7 @@
#include linux/extcon.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/of.h
/*
* extcon_cable_name suggests the standard cable names for commonly used
@@ -818,6 +819,48 @@ void extcon_dev_unregister(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
+#ifdef CONFIG_OF
+/*
+ * extcon_get_edev_by_phandle - Get the extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+
+ if (!dev-of_node) {
+ dev_err(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_err(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ edev = extcon_get_extcon_dev(node-name);
+ if (!edev) {
+ dev_err(dev, unable to get extcon device : %s\n, node-name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+#else
+static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
+ int index)
+{
+ return ERR_PTR(-ENOSYS);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
+
static int __init extcon_class_init(void)
{
return create_extcon_class();
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
deleted file mode 100644
index 0a29f82..000
--- a/drivers/extcon/of_extcon.c
+++ /dev/null
@@ -1,56 +0,0 @@
-/*
- * OF helpers for External connector (extcon) framework
- *
- * Copyright (C) 2013 Texas Instruments, Inc.
- * Kishon Vijay Abraham I kis...@ti.com
- *
- * Copyright (C) 2013 Samsung Electronics
- * Chanwoo Choi cw00.c...@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include linux/module.h
-#include linux/slab.h
-#include linux/err.h
-#include linux/extcon.h
-#include linux/of.h
-#include linux/of_platform.h
-#include linux/extcon/of_extcon.h
-
-/*
- * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
- * @dev - instance to the given device
- * @index - index into list of extcon_dev
- *
- * return the instance of extcon device
- */
-struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
-{
- struct device_node *node;
- struct extcon_dev *edev;
-
- if (!dev-of_node) {
- dev_dbg(dev, device does not have a device node entry\n);
- return ERR_PTR(-EINVAL);
- }
-
- node = of_parse_phandle(dev-of_node, extcon, index);
- if (!node) {
- dev_dbg(dev, failed to get phandle in %s node\n,
- dev-of_node-full_name);
-
[PATCH 0/2] extcon: of: Update OF helper function
Thisp patchset remove unnecessary function call in of_extcon_get_extcon_dev() which get the extcon device from devicetree. Also, this patchset move OF helper func to extcon core and change function name as following: - of_extcon_get_extcon_dev() - extcon_get_edev_by_phandle() Chanwoo Choi (2): extcon: of: Remove unnecessary function call by using the name of device_node extcon: Move OF helper function to extcon core and change function name drivers/extcon/Kconfig | 4 --- drivers/extcon/Makefile | 2 -- drivers/extcon/extcon-class.c| 43 +++ drivers/extcon/of_extcon.c | 64 drivers/usb/dwc3/dwc3-omap.c | 3 +- include/linux/extcon.h | 12 include/linux/extcon/of_extcon.h | 31 --- 7 files changed, 56 insertions(+), 103 deletions(-) delete mode 100644 drivers/extcon/of_extcon.c delete mode 100644 include/linux/extcon/of_extcon.h -- 1.8.0 -- 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] ARM: OMAP5: DSS hwmod data
Hi Tomi,
I've activated HDMI output with omapfb. Thank you very much !
Some minor issue are observed:
* the colors are inverted.
* DRM seems to be loaded with no failures, however there is no output.
HPD connector pin is connected to HDMI_HPD/GPIO7_193.
In addition we have DVI output (uses TFP410 encoder to convert DPI to DVI).
TFP410 is not connected to I2C and its PD always on.
I tried to turn DVI support using omap4-panda-common.dtsi as the
reference (with OMAP5 specific pinmux, of course),
however it fails. Does it supposed to work?
Please, could you share the .config you are using with uEvm?
Thank you in advance,
Dmitry
On 03/18/2014 10:37 AM, Tomi Valkeinen wrote:
On 18/03/14 10:19, Dmitry Lifshitz wrote:
Hi Tomi,
Thank you a lot for your assistance.
Here are my relevant DT nodes:
/ {
aliases {
display0 = hdmi0;
};
hdmi0: connector@0 {
compatible = hdmi-connector;
label = hdmi;
type = b;
hdmi_connector_in: endpoint {
remote-endpoint = hdmi_out;
};
};
};
dss {
status = ok;
};
hdmi {
status = ok;
vdda-supply = ldo4_reg;
pinctrl-names = default;
pinctrl-0 = dss_hdmi_pins;
hdmi_out: endpoint {
remote-endpoint = hdmi_connector_in;
};
};
The above looks fine.
I have the following kernel crash (caused by missing .detect callback):
Yes, it seems the hdmi driver is missing detect, as there's no support
in there for the detection at the moment. You can add the function to
omap5.c, and return true always.
How does the HPD work on your board? On uevm, the ESD/Level shifter chip
handles HPD, which is the only supported way at the moment.
While using FBDEV I have the following issue:
root@cm-debian:~# modprobe omapfb
[ 27.524419] [ cut here ]
[ 27.529256] WARNING: CPU: 1 PID: 2087 at
/home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492
__alloc_pages_nodemask+0x268/0x83c()
[ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt
cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2
connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp
rtc_palmas spi_omap2_mcspi
[ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W
3.14.0-rc4-cm-t54-test-suit+ #108
[ 27.572677] [c00280ac] (unwind_backtrace) from [c0024eb0]
(show_stack+0x10/0x14)
[ 27.580786] [c0024eb0] (show_stack) from [c06fc434]
(dump_stack+0x70/0x88)
[ 27.588341] [c06fc434] (dump_stack) from [c004d8e8]
(warn_slowpath_common+0x70/0x88)
[ 27.596815] [c004d8e8] (warn_slowpath_common) from [c004d91c]
(warn_slowpath_null+0x1c/0x24)
[ 27.606004] [c004d91c] (warn_slowpath_null) from [c01135ec]
(__alloc_pages_nodemask+0x268/0x83c)
[ 27.615562] [c01135ec] (__alloc_pages_nodemask) from [c002cd78]
(__dma_alloc_buffer.isra.16+0x2c/0xdc)
[ 27.625661] [c002cd78] (__dma_alloc_buffer.isra.16) from
[c002ce40] (__alloc_remap_buffer.isra.19+0x18/0xcc)
[ 27.636300] [c002ce40] (__alloc_remap_buffer.isra.19) from
[c002d248] (__dma_alloc+0x110/0x138)
[ 27.645757] [c002d248] (__dma_alloc) from [c002d3fc]
(arm_dma_alloc+0xb0/0xd8)
[ 27.653686] [c002d3fc] (arm_dma_alloc) from [bf1b1f74]
(omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb])
[ 27.663911] [bf1b1f74] (omapfb_alloc_fbmem.isra.24 [omapfb]) from
[bf1b7078] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb])
[ 27.676759] [bf1b7078] (omapfb_alloc_fbmem_display.isra.25
[omapfb]) from [bf1b21fc] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb])
[ 27.689419] [bf1b21fc] (omapfb_allocate_all_fbs [omapfb]) from
[bf1b30f8] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb])
[ 27.701432] [bf1b30f8] (omapfb_create_framebuffers [omapfb]) from
[bf1b3fdc] (omapfb_probe+0x28c/0x41c [omapfb])
[ 27.712446] [bf1b3fdc] (omapfb_probe [omapfb]) from [c03ab844]
(platform_drv_probe+0x18/0x48)
[ 27.721728] [c03ab844] (platform_drv_probe) from [c03a9a4c]
(really_probe+0x80/0x208)
[ 27.730284] [c03a9a4c] (really_probe) from [c03a9ce4]
(driver_probe_device+0x30/0x48)
[ 27.738834] [c03a9ce4] (driver_probe_device) from [c03a9d88]
(__driver_attach+0x8c/0x90)
[ 27.747661] [c03a9d88] (__driver_attach) from [c03a845c]
(bus_for_each_dev+0x54/0x88)
[ 27.756220] [c03a845c] (bus_for_each_dev) from [c03a9338]
(bus_add_driver+0xe4/0x1d8)
[ 27.764778] [c03a9338] (bus_add_driver) from [c03aa3e4]
(driver_register+0x78/0xf4)
[ 27.773148] [c03aa3e4] (driver_register) from [c0008788]
(do_one_initcall+0x44/0x174)
[ 27.781703] [c0008788] (do_one_initcall) from [c06f2934]
(do_init_module+0x48/0x17c)
[ 27.790172] [c06f2934] (do_init_module) from [c00bad0c]
(SyS_init_module+0x64/0x6c)
[ 27.798546] [c00bad0c] (SyS_init_module) from [c0020d80]
(ret_fast_syscall+0x0/0x30)
[ 27.807015] ---[ end trace 842d286115ab739d ]---
[ 27.811849] omapfb omapfb: failed to allocate framebuffer
[
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna s-a...@ti.com wrote: So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. Yes, this could be done too, but I agree it is less simple with no real win. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. Yeah. Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? I guess this is a question to the DT folks; both approaches work from hwspinlock perspective. In the past Arnd Benoit and myself were happy with adding one more property to the controller node, but this might be somewhat error prone as it leaves room for mistakes - developers can add hwlock phandles and forget to update the reserved property in the controller node. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
Hi Tony,
On 03/13/2014 11:44 PM, Paul Walmsley wrote:
On Wed, 12 Mar 2014, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140307 02:18]:
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
Paul, does this look OK to you?
I didn't go over every entry with a magnifying glass, but did take a
quick look at the sysc_offs and the clkdms - the basics look OK.
Acked-by: Paul Walmsley p...@pwsan.com
Is there any chance this can still make it into 3.15? Would be nice to have SATA
working out of the box.
cheers,
-roger
- Paul
Regards,
Tony
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if
*omap54xx_hwmod_ocp_ifs[] __initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.8.3.2
--
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
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/9] opp-modifier: Add opp-modifier-reg driver
On 03/17/2014 01:37 PM, Rob Herring wrote: On Mon, Mar 17, 2014 at 9:30 AM, Nishanth Menon n...@ti.com wrote: On 03/14/2014 04:00 PM, Rob Herring wrote: On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote: Driver to read from a register and depending on either set bits or a specific known selectively enable or disable OPPs based on DT node. Can support opp-modifier-reg-bit where single bits within the register determine the availability of an OPP or opp-modifier-reg-val where a certain value inside the register or a portion of it determine what the maximum allowed OPP is. The driver expects a device that has already has its OPPs loaded and then will disable the OPPs not matching the criteria specified in the opp-modifier table. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- .../devicetree/bindings/power/opp-modifier.txt | 111 + drivers/power/opp/Makefile | 1 + drivers/power/opp/opp-modifier-reg.c | 259 + 3 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/opp-modifier-reg.c diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt b/Documentation/devicetree/bindings/power/opp-modifier.txt new file mode 100644 index 000..af8a2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt @@ -0,0 +1,111 @@ +* OPP-Modifier - opp modifier to selectively enable operating points + +Many SoCs that have selectively modifiable OPPs can specify +all available OPPs in their operating-points listing and then define +opp_modifiers to enable or disable the OPPs that are actually available +on the specific hardware. + +* OPP Modifier Provider Uggg. Please stop designing around the current OPP binding which has the problem that the OPP table is not extensible to add more data. Define a new OPP binding that solves these problems. This is at least Generically, there are three different issues with current OPP bindings: a) ability to enable disable certain OPPs depending on SoC OTP/Efuse settings. More generically: ...depending on variety of factors. Agreed. b) ability to reuse OPPs defined for one device node for another (cpu1 to reuse OPP definitions of cpu0) c) ability to add additional information per OPP. we can argue this is a superset of (a), but really, the problems are different. It is all additional data per OPP. Additional different information is of course for different problems. That doesn't mean we need different solutions. Previous proposals include making each OPP as a phandle, but there does not seem much traction in that direction either. - proposal here has nothing to do with (b) or (c). They may have nothing to do with each other, but they all have to do with the OPP binding. If we're going to change/extend the binding, then all issues need to be taken into account. We aren't extending the existing binding in this series. We are just defining how hardware description of which OPPs are valid here. the 3rd OPP related binding addition I've seen recently. But I wouldn't spend a lot of effort on a new OPP binding just to add the functionality you are adding here because I don't like the whole concept in general. This might be a common way to determine valid OPPs on TI chips, but I think it is too low level and I don't want to see Not just TI chips, but iMX, now, Marvell, Xilinx as well. potentially more as well. doing OTP/Efuse based decision on which OPPs are valid on a chip is not a TI specific thing. This was the reason for us to try to define something generic enough to be reused by more SoCs than just TI. Agreed, but I'm not convinced how different SOCs determine valid OPPs is common enough. Certainly how to mark an entry disabled is common though. Fair enough, without procuring NDA documents for all the SoCs, I cannot comment much either, all we can do is see threads such as http://marc.info/?t=13947079113r=1w=2 and propose. This series does include iMx as well which seems to have equivalent challenges. I have given examples here on how the current driver at least tries to make generic the instances of SoCs that we have today, further, the driver in no way constraints us from using opp_modifier_register with proper ops in case we do something weirdly different (example: use non memory mapped operations) - it is just a simple framework. bindings for every different possible way. Just add platform code to do the OPP setup you need. Errr.. adding platform code means the hardware description goes back to kernel. is'nt that giving up on device tree binding for describing hardware? We're always going to have some platform code. I'm not saying you have to in this case. I'm saying either come up with an OPP binding addressing all these issues or live with the existing one and
Re: [PATCH 00/26] OMAP dma engine rework
On Mon, Feb 10, 2014 at 09:25:31PM +0530, Russell King - ARM Linux wrote: This is the current set of patches for the OMAP DMA engine rework, which should now work correctly on OMAP1 platforms thanks to Tony's testing. It would be good to get this validated by others across a range of OMAP platforms, and queued up for the next merge window, so it can be built upon. Acks appreciated, and once sufficient have been added, I'll send a pull request for this to Vinod. So is this series finalized. I havent seen the pull request for this or did i miss it! -- ~Vinod arch/arm/mach-omap1/dma.c | 191 ++ arch/arm/mach-omap2/dma.c | 183 ++--- arch/arm/plat-omap/dma.c | 17 +- drivers/dma/omap-dma.c| 659 +- include/linux/omap-dma.h | 25 +- 5 files changed, 784 insertions(+), 291 deletions(-) -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] extcon: Move OF helper function to extcon core and change function name
Hi,
On Tue, Mar 18, 2014 at 09:04:40PM +0900, Chanwoo Choi wrote:
This patch move simply OF helper function to extcon core and change function
name as following:
- of_extcon_get_extcon_dev() - extcon_get_edev_by_phandle()
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/extcon/Kconfig | 4 ---
drivers/extcon/Makefile | 2 --
drivers/extcon/extcon-class.c| 43 ++
drivers/extcon/of_extcon.c | 56
drivers/usb/dwc3/dwc3-omap.c | 3 +--
for dwc3:
Acked-by: Felipe Balbi ba...@ti.com
include/linux/extcon.h | 12 +
include/linux/extcon/of_extcon.h | 31 --
7 files changed, 56 insertions(+), 95 deletions(-)
delete mode 100644 drivers/extcon/of_extcon.c
delete mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index bdb5a00..be56e8a 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -14,10 +14,6 @@ if EXTCON
comment Extcon Device Drivers
-config OF_EXTCON
- def_tristate y
- depends on OF
-
config EXTCON_GPIO
tristate GPIO extcon support
depends on GPIOLIB
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 43eccc0..bf7861e 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,8 +2,6 @@
# Makefile for external connector class (extcon) devices
#
-obj-$(CONFIG_OF_EXTCON) += of_extcon.o
-
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 7632233..bc4c789 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -31,6 +31,7 @@
#include linux/extcon.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/of.h
/*
* extcon_cable_name suggests the standard cable names for commonly used
@@ -818,6 +819,48 @@ void extcon_dev_unregister(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
+#ifdef CONFIG_OF
+/*
+ * extcon_get_edev_by_phandle - Get the extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+
+ if (!dev-of_node) {
+ dev_err(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_err(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ edev = extcon_get_extcon_dev(node-name);
+ if (!edev) {
+ dev_err(dev, unable to get extcon device : %s\n, node-name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+#else
+static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device
*dev,
+ int index)
+{
+ return ERR_PTR(-ENOSYS);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
+
static int __init extcon_class_init(void)
{
return create_extcon_class();
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
deleted file mode 100644
index 0a29f82..000
--- a/drivers/extcon/of_extcon.c
+++ /dev/null
@@ -1,56 +0,0 @@
-/*
- * OF helpers for External connector (extcon) framework
- *
- * Copyright (C) 2013 Texas Instruments, Inc.
- * Kishon Vijay Abraham I kis...@ti.com
- *
- * Copyright (C) 2013 Samsung Electronics
- * Chanwoo Choi cw00.c...@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include linux/module.h
-#include linux/slab.h
-#include linux/err.h
-#include linux/extcon.h
-#include linux/of.h
-#include linux/of_platform.h
-#include linux/extcon/of_extcon.h
-
-/*
- * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
- * @dev - instance to the given device
- * @index - index into list of extcon_dev
- *
- * return the instance of extcon device
- */
-struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
-{
- struct device_node *node;
- struct extcon_dev *edev;
-
- if (!dev-of_node) {
- dev_dbg(dev, device does not have a device node entry\n);
- return ERR_PTR(-EINVAL);
- }
rts-gpio DT binding
Hi Mark, I'm looking at the omap-serial driver and saw that you added rts-gpio binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both actual RTS signals. Instead of adding that extra GPIO handling, why didn't you just mux those signals as RTS and enable auto-RTS/auto-CTS feature ? It looks to me like that's highly unnecessary binding. -- balbi signature.asc Description: Digital signature
Re: rts-gpio DT binding
On Tue, Mar 18, 2014 at 05:04:47PM +, Mark Jackson wrote: On 18/03/14 16:55, Felipe Balbi wrote: Hi Mark, I'm looking at the omap-serial driver and saw that you added rts-gpio binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both actual RTS signals. Instead of adding that extra GPIO handling, why didn't you just mux those signals as RTS and enable auto-RTS/auto-CTS feature ? It looks to me like that's highly unnecessary binding. I agree !! I think it was to allow delays pre- and post- sending the comms data. Several RS485 drivers require a warm up time before they will transmit data correctly, and also need a cool down time to prevent clipping of the last few bits of data. IIRC the built-in RTS handling did not allow for this. you might be right here. I can't find anywhere to write rts delays. Weird... digging TRM. It also allows the RTS signal to be inverted, again required for some RS485 driver chips. However, I'll dig into why I did this and report back. cool, thanks -- balbi signature.asc Description: Digital signature
Re: rts-gpio DT binding
hi, On Tue, Mar 18, 2014 at 12:11:10PM -0500, Felipe Balbi wrote: On Tue, Mar 18, 2014 at 05:04:47PM +, Mark Jackson wrote: On 18/03/14 16:55, Felipe Balbi wrote: Hi Mark, I'm looking at the omap-serial driver and saw that you added rts-gpio binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both actual RTS signals. Instead of adding that extra GPIO handling, why didn't you just mux those signals as RTS and enable auto-RTS/auto-CTS feature ? It looks to me like that's highly unnecessary binding. I agree !! I think it was to allow delays pre- and post- sending the comms data. Several RS485 drivers require a warm up time before they will transmit data correctly, and also need a cool down time to prevent clipping of the last few bits of data. IIRC the built-in RTS handling did not allow for this. you might be right here. I can't find anywhere to write rts delays. Weird... digging TRM. hmm, you can change RTS value manually if you don't use auto-RTS. Just write MCR BIT(1) to toggle that line. The warm up time you mention, however, can be coped with by means of RX FIFO trigger level. TRM mentions that far end could send another byte after RTS has been deasserted. So if we set RX trigger level to always have room for one extra byte, then we will never loose data and the warm up time is probably negligible. Am I missing something ? -- balbi signature.asc Description: Digital signature
Re: rts-gpio DT binding
Hi, On Tue, Mar 18, 2014 at 12:18:41PM -0500, Felipe Balbi wrote: hi, On Tue, Mar 18, 2014 at 12:11:10PM -0500, Felipe Balbi wrote: On Tue, Mar 18, 2014 at 05:04:47PM +, Mark Jackson wrote: On 18/03/14 16:55, Felipe Balbi wrote: Hi Mark, I'm looking at the omap-serial driver and saw that you added rts-gpio binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both actual RTS signals. Instead of adding that extra GPIO handling, why didn't you just mux those signals as RTS and enable auto-RTS/auto-CTS feature ? It looks to me like that's highly unnecessary binding. I agree !! I think it was to allow delays pre- and post- sending the comms data. Several RS485 drivers require a warm up time before they will transmit data correctly, and also need a cool down time to prevent clipping of the last few bits of data. IIRC the built-in RTS handling did not allow for this. you might be right here. I can't find anywhere to write rts delays. Weird... digging TRM. hmm, you can change RTS value manually if you don't use auto-RTS. Just write MCR BIT(1) to toggle that line. The warm up time you mention, however, can be coped with by means of RX FIFO trigger level. TRM mentions that far end could send another byte after RTS has been deasserted. So if we set RX trigger level to always have room for one extra byte, then we will never loose data and the warm up time is probably negligible. Am I missing something ? another small gem hidden in the TRM: You must ensure that TCR[3:0] TCR[7:4], whenever auto-RTS or software flow control is enabled to avoid a misoperation of the device. In FIFO interrupt mode with flow control, you have to also ensure that the trigger level to HALT transmission is greater or equal to receive FIFO trigger level (either TLR[7:4] or FCR[7:6]); otherwise, FIFO operation stalls. so there are quite a few things needed to get this working properly. -- balbi signature.asc Description: Digital signature
Re: [PATCH] mfd: twl-core: Fix accessibility of some twl4030 audio registers
* Peter Ujfalusi peter.ujfal...@ti.com [140311 01:33]:
On 03/10/2014 08:12 PM, Tomas Novotny wrote:
There are some unused registers in twl4030 at I2C address 0x49 and function
twl4030_49_nop_reg() is used to check accessibility of that registers. These
registers are written in decimal format but the values are correct in
hexadecimal format. (It can be checked few lines above the patched code -
these registers are marked as unused there.)
As a consequence three registers of audio submodule are treated as
inaccessible (preamplifier carkit right and both handsfree registers).
CC: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Tomas Novotny to...@novotny.cz
---
drivers/mfd/twl-core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index ed71832..e87140b 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -282,11 +282,11 @@ static struct reg_default twl4030_49_defaults[] = {
static bool twl4030_49_nop_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
- case 0:
- case 3:
- case 40:
- case 41:
- case 42:
+ case 0x00:
+ case 0x03:
+ case 0x40:
+ case 0x41:
+ case 0x42:
Uhm, I can not be that @#$%^ that I did this... I have no idea how I left out
the 0x
Thanks for spotting it!
Acked-by Peter Ujfalusi peter.ujfal...@ti.com
Peter, if this does not make it to the -rc series, care to send this to
the stable for inclusion after it hits mainline?
This fixes twl4030 audio regression at least on boards using HandsfreeL
for audio.
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: rts-gpio DT binding
On 18/03/14 16:55, Felipe Balbi wrote: Hi Mark, I'm looking at the omap-serial driver and saw that you added rts-gpio binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both actual RTS signals. Instead of adding that extra GPIO handling, why didn't you just mux those signals as RTS and enable auto-RTS/auto-CTS feature ? It looks to me like that's highly unnecessary binding. I agree !! I think it was to allow delays pre- and post- sending the comms data. Several RS485 drivers require a warm up time before they will transmit data correctly, and also need a cool down time to prevent clipping of the last few bits of data. IIRC the built-in RTS handling did not allow for this. It also allows the RTS signal to be inverted, again required for some RS485 driver chips. However, I'll dig into why I did this and report back. Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: edma: fix incorrect SG list handling
On 03/18/2014 10:28 AM, Vinod Koul wrote: On Mon, Mar 17, 2014 at 09:14:14AM -0400, Jon Ringle wrote: On Mon, 17 Mar 2014, Sekhar Nori wrote: Hi Jon, On Monday 17 March 2014 06:28 PM, Jon Ringle wrote: On Mon, 17 Mar 2014, Sekhar Nori wrote: The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: sta...@vger.kernel.org # v3.12.x+ Cc: Joel Fernandes jo...@ti.com Reported-by: Jon Ringle jrin...@gridpoint.com Signed-off-by: Sekhar Nori nsek...@ti.com --- Jon, can you please confirm this fixes the issue you reported? The patch does not apply on linux-3.12 due to changes to the 3 context lines at the start of the hunk. But, I manually fixed up the code and it does fix the issue on our AM1808 board. Thanks for the testing. The patch is meant for latest mainline but based on what you said, a manual backport to v3.12-stable will be required. Can you please reply with a formal Tested-by: ? Tested-by: Jon Ringle jrin...@gridpoint.com where is this patch, somehow am not able to find in my inbox or archives... I found it archived here: http://comments.gmane.org/gmane.linux.davinci/28569 Patch doesn't breaking anything for MAX_NR_SG list size on AM335x, so it looks good. Acked-by: Joel Fernandes jo...@ti.com Regards, -Joel -- 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] mfd: twl-core: Fix accessibility of some twl4030 audio registers
There are some unused registers in twl4030 at I2C address 0x49 and
function
twl4030_49_nop_reg() is used to check accessibility of that registers.
These
registers are written in decimal format but the values are correct in
hexadecimal format. (It can be checked few lines above the patched code -
these registers are marked as unused there.)
As a consequence three registers of audio submodule are treated as
inaccessible (preamplifier carkit right and both handsfree registers).
CC: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Tomas Novotny to...@novotny.cz
---
drivers/mfd/twl-core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index ed71832..e87140b 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -282,11 +282,11 @@ static struct reg_default twl4030_49_defaults[] = {
static bool twl4030_49_nop_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
- case 0:
- case 3:
- case 40:
- case 41:
- case 42:
+ case 0x00:
+ case 0x03:
+ case 0x40:
+ case 0x41:
+ case 0x42:
Uhm, I can not be that @#$%^ that I did this... I have no idea how I left
out
the 0x
Thanks for spotting it!
Acked-by Peter Ujfalusi peter.ujfal...@ti.com
Peter, if this does not make it to the -rc series, care to send this to
the stable for inclusion after it hits mainline?
This fixes twl4030 audio regression at least on boards using HandsfreeL
for audio.
I think it's a little late in the cycle to send this to the -rcs.
Stable will be Cc'ed however.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] twl4030-madc device tree support
Hi Tony/Benoît, The DT support for twl4030-madc has been added to mfd queue [0], so I guess it's safe to merge the following DTS addition for 3.15. [0] https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=ib-mfd-io-3.15id=2f39b70fef194a54c9decd8687bb05d576afebe5 -- Sebastian Sebastian Reichel (1): DTS: ARM: TWL4030: Add madc arch/arm/boot/dts/twl4030.dtsi | 6 ++ 1 file changed, 6 insertions(+) -- 1.9.0 -- 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] DTS: ARM: TWL4030: Add madc
Add madc node to twl4030, so that board DTS
files can simply reference the A/D converter.
Signed-off-by: Sebastian Reichel s...@debian.org
---
arch/arm/boot/dts/twl4030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 86cfc7d..36ae916 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -152,4 +152,10 @@
keypad,num-rows = 8;
keypad,num-columns = 8;
};
+
+ twl_madc: madc {
+ compatible = ti,twl4030-madc;
+ interrupts = 3;
+ #io-channel-cells = 1;
+ };
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates
Quoting Tomi Valkeinen (2014-03-17 05:53:03)
On 27/02/14 04:25, Mike Turquette wrote:
Quoting Tero Kristo (2014-02-14 05:45:22)
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
14400 - 14400
14399 - 123428571
123428572 - 123428571
123428571 - 10800
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.
This means that the following code works a bit oddly:
rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);
As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.
This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:
14400 - 14400
14399 - 123428572
123428572 - 123428572
123428571 - 10800
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clk-divider.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
* enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * rate - rate is adjustable. clk-rate = DIV_ROUND_UP(parent-rate /
divisor)
* parent - fixed parent. No clk_set_parent support
*/
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
return parent_rate;
}
- return parent_rate / div;
+ return DIV_ROUND_UP(parent_rate, div);
}
/*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
+ now = DIV_ROUND_UP(parent_rate, i);
if (now = rate now best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
- return *prate / div;
+ return DIV_ROUND_UP(*prate, div);
}
static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
if (value div_mask(divider))
Basically the patch looks good to me, but it might be good to have a
testing round of sort with this. It can potentially cause regressions on
multiple boards if the drivers happen to rely on the broken clock
rates. Same for patch #2 which is a copy paste of this one, but only
impacts TI boards.
Agreed. I've taken patches #1 #2 into clk-next. Let's let them stew in
-next for a while and see if anyone's board catches on fire.
Are these on the way to 3.15?
Yes, they've been in -next for a couple of weeks.
Regards,
Mike
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: edma: fix incorrect SG list handling
On Wednesday 19 March 2014 12:16 AM, Joel Fernandes wrote: On 03/18/2014 10:28 AM, Vinod Koul wrote: where is this patch, somehow am not able to find in my inbox or archives... I found it archived here: http://comments.gmane.org/gmane.linux.davinci/28569 Patch doesn't breaking anything for MAX_NR_SG list size on AM335x, so it looks good. Acked-by: Joel Fernandes jo...@ti.com Joel, thanks for the ack. Vinod, Looks like the vger and Intel spam filters dropped the patch. I will try again. Thanks, Sekhar -- 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] dma: edma: fix incorrect SG list handling
The code to handle any length SG lists calls edma_resume()
even before edma_start() is called. This is incorrect
because edma_resume() enables edma events on the channel
after which CPU (in edma_start) cannot clear posted
events by writing to ECR (per the EDMA user's guide).
Because of this EDMA transfers fail to start if due
to some reason there is a pending EDMA event registered
even before EDMA transfers are started. This can happen if
an EDMA event is a byproduct of device initialization.
Fix this by calling edma_resume() only if it is not the
first batch of MAX_NR_SG elements.
Without this patch, MMC/SD fails to function on DA850 EVM
with DMA. The behaviour is triggered by specific IP and
this can explain why the issue was not reported before
(example with MMC/SD on AM335x).
Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.
Cc: sta...@vger.kernel.org # v3.12.x+
Cc: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
Tested-by: Jon Ringle jrin...@gridpoint.com
Tested-by: Alexander Holler hol...@ahsoftware.de
Reported-by: Jon Ringle jrin...@gridpoint.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Same as the version send previously (which did not make
into all mailing lists). Commit message updates with
tested-by and acks received.
drivers/dma/edma.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cd8da45..bf5ad0f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -182,11 +182,13 @@ static void edma_execute(struct edma_chan *echan)
echan-ecc-dummy_slot);
}
- edma_resume(echan-ch_num);
-
if (edesc-processed = MAX_NR_SG) {
dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
edma_start(echan-ch_num);
+ } else {
+ dev_dbg(dev, chan: %d: completed %d elements, resuming\n,
+ echan-ch_num, edesc-processed);
+ edma_resume(echan-ch_num);
}
/*
--
1.7.10.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
