Re: [RFC 0/4] rockchip-dsi for rk3568
On Fri, Aug 12, 2022 at 4:33 PM Chris Morgan wrote: > > From: Chris Morgan Good Afternoon, > > This series adds support for the dsi and dphy controllers on the > Rockchip RK3568. I can confirm that for the Rockchip RK3568 this > current series DOES NOT WORK properly yet. The image on the screen > is shifted about 100 pixels to the right and does not appear to be > a timing issue. This behavior was observed on both the Anbernic RG503 > and RG353 portable gaming devices with different screens. These changes > were also tested on an RK3326 based device (an Odroid Go Advance) with > no noticeable regressions. > > An example of the issue on multiple devices: > https://media.discordapp.net/attachments/973914035890290718/1007407064647221299/IMG_1999.jpg > https://media.discordapp.net/attachments/995430498677571604/1003754966932008960/AB25898E-73EC-40A9-BD47-3FB970DDFB31.jpg > > > Given the fact that the DSI controller is identical on the PX30 and > RK3568 aside from different grf registers I am assuming the PHY is > likely where the bugs are currently. I'm posting this as an RFC in the > hopes that someone more knowledgeable than I can help identify the > problem. Thank you for this. It will be a few weeks before I'm in the position to test your series, but what you have described matches what I have observed in my attempts as well. I suspect the issue is actually in the VOP2 driver, since the PHY test functions display without corruption and loading up a 1080P hdmi connection allows DSI to display correctly. Very Respectfully, Peter Geis > > Chris Morgan (4): > dt-bindings: display: rockchip-dsi: add rk3568 compatible > dt-bindings: phy: phy-rockchip-inno-dsidphy: add compatible for rk3568 > drm/rockchip: dsi: add rk3568 support > phy/rockchip: inno-dsidphy: Add support for rk3568 > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + > .../bindings/phy/rockchip,px30-dsi-dphy.yaml | 1 + > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 51 - > .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 204 ++ > 4 files changed, 209 insertions(+), 48 deletions(-) > > -- > 2.25.1 > > > ___ > Linux-rockchip mailing list > linux-rockc...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Sat, Jun 25, 2022 at 9:18 AM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Peter Geis w dniu > > 25.06.2022, o godz. 01:50: > > > > On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk > > wrote: > >> > >> > >> > >>> Wiadomość napisana przez Peter Geis w dniu > >>> 24.06.2022, o godz. 14:40: > >>> > >>>> > >>>> Sascha, Peter > >>>> > >>>> I returned to trying to find why hdmi-cec is not working on rock3-a > >>>> v1.31 hw. > >>>> > >>>> I'm on vop2 v11 on 5.18 mainline. > >>>> > >>>> Current findings: > >>>> > >>>> (1) the same sw. stack/binaries works on rock-3b (where cec uses > >>>> hdmitx_m0 instead of hdmitx_m1 I/O line); > >>>> > >>>> (2) gpio-cec however works no problem on rock3-a; > >>>> > >>>> (3) monitoring cec messages with v4-utils 'cec-follower -s' shows exact > >>>> the same events in non-working rock3-a and working rock3-b > >>>> (tested by issue configure cec by 'cec-ctl -d /dev/cec0 > >>>> --phys-addr=1.0.0.0 --playback' command) > >>> > >>> --phys-addr isn't a valid command for this controller. The device > >>> designation is only required if you have more than one cec device. > >>> > >>>> > >>>> --> i'm interpreting this as confirmation that low level phy layer > >>>> receives ok cec data from connected device on non-working rock3-a; > >>>> > >>>> (4) debug sysfs for cec shows "has CEC follower (in passthrough mode)" > >>>> for working rock-3b and there is NO "has CEC follower" debug message in > >>>> failing rock3-a. > >>> > >>> This makes me suspect you are in fact not using the same software > >>> stack, or are not running the same commands. > >> > >> It was the same SD card - with only DT declaration changed in boot.scr > >> Such SD card has cec perfectly working in rock3b > >> > >>> Running `cec-follower -v -m -T` on a rk3566 device with working cec > >>> using 5.19-rc1, I see no mention of cec-follower in the debugfs cec0 > >>> status entry. > >>> > >>>> > >>>> For me It looks like low-level hdmi-cec works ok on failing rock3-a - > >>>> but upper layers (in hdmi vop2?) are not registering (or failing to > >>>> register) cec-follower filehandle. This happens just when hdmitx I/O in > >>>> DT is changed from hdmitx_m0 to hdmutx_m1. A bit strange - but all my > >>>> tests consistently confirming this observation > >>> > >>> There is nothing wrong with vop2 as it is not involved at all in this. > >>> The rockchip hdmi driver (which is not specific to vop2) does nothing > >>> more than call the cec registration method in the dw hdmi bridge > >>> driver, which then calls the kernel cec registration functions. > >>> Changing pinmux changes nothing in how this functions. > >>> > >>>> > >>>> I'm too weak in kernel cec internals - so maybe you have any pointers > >>>> how to further debug/investigate this issue? > >>> > >>> As we discussed in the pine64 room, this is still very likely a > >>> hardware issue with this board. A configuration issue with your u-boot > >>> or tf-a is also a possibility, but is less likely. > >>> > >>> You showed with your logic analyzer with nothing plugged in and cec > >>> not muxed to m1, data was present on m1. > >> > >> Issue of presence of data on m1 with nothing plugged was mistake from my > >> side: wrong board pin used to connect logic analyser GND. > >> After correctly connecting GND - all is ok (no any unexpected data; pulses > >> appears only after cec commands; pulses timings are ok so cec protocol > >> analyser shows reasonable data; no cec timing errors reported by protocol > >> analyser). > >> > >> > >>> I requested you investigate > >>> the following, to which you haven't replied: > >>> Have you tried forcing m0 to be assigned to a device other than hdmi-cec? > >> > >> I'm a bit lost here: v1.31 hw uses m1 and m0 is unused. > >> Is you idea to verify that m0 is not used by hdmi-cec - even when m1 is
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Peter Geis w dniu > > 24.06.2022, o godz. 14:40: > > > >> > >> Sascha, Peter > >> > >> I returned to trying to find why hdmi-cec is not working on rock3-a v1.31 > >> hw. > >> > >> I'm on vop2 v11 on 5.18 mainline. > >> > >> Current findings: > >> > >> (1) the same sw. stack/binaries works on rock-3b (where cec uses hdmitx_m0 > >> instead of hdmitx_m1 I/O line); > >> > >> (2) gpio-cec however works no problem on rock3-a; > >> > >> (3) monitoring cec messages with v4-utils 'cec-follower -s' shows exact > >> the same events in non-working rock3-a and working rock3-b > >> (tested by issue configure cec by 'cec-ctl -d /dev/cec0 > >> --phys-addr=1.0.0.0 --playback' command) > > > > --phys-addr isn't a valid command for this controller. The device > > designation is only required if you have more than one cec device. > > > >> > >> --> i'm interpreting this as confirmation that low level phy layer > >> receives ok cec data from connected device on non-working rock3-a; > >> > >> (4) debug sysfs for cec shows "has CEC follower (in passthrough mode)" for > >> working rock-3b and there is NO "has CEC follower" debug message in > >> failing rock3-a. > > > > This makes me suspect you are in fact not using the same software > > stack, or are not running the same commands. > > It was the same SD card - with only DT declaration changed in boot.scr > Such SD card has cec perfectly working in rock3b > > > Running `cec-follower -v -m -T` on a rk3566 device with working cec > > using 5.19-rc1, I see no mention of cec-follower in the debugfs cec0 > > status entry. > > > >> > >> For me It looks like low-level hdmi-cec works ok on failing rock3-a - but > >> upper layers (in hdmi vop2?) are not registering (or failing to register) > >> cec-follower filehandle. This happens just when hdmitx I/O in DT is > >> changed from hdmitx_m0 to hdmutx_m1. A bit strange - but all my tests > >> consistently confirming this observation > > > > There is nothing wrong with vop2 as it is not involved at all in this. > > The rockchip hdmi driver (which is not specific to vop2) does nothing > > more than call the cec registration method in the dw hdmi bridge > > driver, which then calls the kernel cec registration functions. > > Changing pinmux changes nothing in how this functions. > > > >> > >> I'm too weak in kernel cec internals - so maybe you have any pointers how > >> to further debug/investigate this issue? > > > > As we discussed in the pine64 room, this is still very likely a > > hardware issue with this board. A configuration issue with your u-boot > > or tf-a is also a possibility, but is less likely. > > > > You showed with your logic analyzer with nothing plugged in and cec > > not muxed to m1, data was present on m1. > > Issue of presence of data on m1 with nothing plugged was mistake from my > side: wrong board pin used to connect logic analyser GND. > After correctly connecting GND - all is ok (no any unexpected data; pulses > appears only after cec commands; pulses timings are ok so cec protocol > analyser shows reasonable data; no cec timing errors reported by protocol > analyser). > > > > I requested you investigate > > the following, to which you haven't replied: > > Have you tried forcing m0 to be assigned to a device other than hdmi-cec? > > I'm a bit lost here: v1.31 hw uses m1 and m0 is unused. > Is you idea to verify that m0 is not used by hdmi-cec - even when m1 is > declared for hdmi-cec in DT? > May you pls hint me with any example of DT snippet for Your m0 assignment > idea? As pinctrl is only assigned when a device explicitly requests it in the kernel driver, it is possible to have multiple pinctrl pins assigned to a single device if it was left that way by previous software or userspace has fun with it. Such as both the m0 and m1 pins are assigned to the cec-controller. Such a case is broken. You can assign the m0 pin to another device explicitly, but before doing so I'd read the register manually just to see if it. For example that pin also is the spi3m1_cs1 pin. > > > Have you checked if m1 is shorted to another pin? > > Yes. Looks ok for me. > (as radxa debian has working ok hdmi-cec i think hw is ok) > > > > > In regards to your data frames for 4.19 vs 5.18, image-view
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Fri, Jun 24, 2022 at 4:30 AM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Piotr Oniszczuk w dniu > > 14.05.2022, o godz. 15:58: > > > > > > > >> Wiadomość napisana przez Peter Geis w dniu > >> 09.05.2022, o godz. 18:00: > >> > >> If you want to confirm the hardware is configured correctly you can > >> remove the cec pin from the hdmi node and set up a cec-gpio node. > >> https://elixir.bootlin.com/linux/v5.18-rc5/source/Documentation/devicetree/bindings/media/cec-gpio.txt > > > > Peter, Sascha > > > > I configured cec-gpio and can confirm: with gpio cec works on my rock3-a > > board v1.31. > > > > So summarising my tests: > > > >rock3-a v1.1 rock3-a v1.31 > > rock3-b > > > > radxa debian: ok ok > > ok > > > > other ppl mainline 5.18: ok n/tn/t > > > > me with mainline 5.18: n/tnok ok > > > > me with mainline 5.18 gpio-cec: n/t okn/t > > > > Non-working combination is: rock3-a v1.31 hw on mainline 5.18. > > For me it looks like there is bug in case when rk3568 using cec on > > hdmitxm1_cec line. > > (The same binaries working ok on my rock3-b where cec is on hdmitxm0_cec > > line. It also works on Peter's rock3a v1.1 - which also uses hdmitxm0_cec > > line). > > > > It looks like upper cec driver can talk to lower driver (dw-hdmi?) but > > nothing is received from lower driver, as my app says: > > CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls > > > > btw: I verified with oscilloscope connected to hdmitxm1_cec line: starting > > cec-compliance -v -T shows expected series of 0V pulses on hdmitxm1_cec > > line > > > > > > Sascha, Peter > > I returned to trying to find why hdmi-cec is not working on rock3-a v1.31 hw. > > I'm on vop2 v11 on 5.18 mainline. > > Current findings: > > (1) the same sw. stack/binaries works on rock-3b (where cec uses hdmitx_m0 > instead of hdmitx_m1 I/O line); > > (2) gpio-cec however works no problem on rock3-a; > > (3) monitoring cec messages with v4-utils 'cec-follower -s' shows exact the > same events in non-working rock3-a and working rock3-b > (tested by issue configure cec by 'cec-ctl -d /dev/cec0 --phys-addr=1.0.0.0 > --playback' command) --phys-addr isn't a valid command for this controller. The device designation is only required if you have more than one cec device. > > --> i'm interpreting this as confirmation that low level phy layer receives > ok cec data from connected device on non-working rock3-a; > > (4) debug sysfs for cec shows "has CEC follower (in passthrough mode)" for > working rock-3b and there is NO "has CEC follower" debug message in failing > rock3-a. This makes me suspect you are in fact not using the same software stack, or are not running the same commands. Running `cec-follower -v -m -T` on a rk3566 device with working cec using 5.19-rc1, I see no mention of cec-follower in the debugfs cec0 status entry. > > For me It looks like low-level hdmi-cec works ok on failing rock3-a - but > upper layers (in hdmi vop2?) are not registering (or failing to register) > cec-follower filehandle. This happens just when hdmitx I/O in DT is changed > from hdmitx_m0 to hdmutx_m1. A bit strange - but all my tests consistently > confirming this observation There is nothing wrong with vop2 as it is not involved at all in this. The rockchip hdmi driver (which is not specific to vop2) does nothing more than call the cec registration method in the dw hdmi bridge driver, which then calls the kernel cec registration functions. Changing pinmux changes nothing in how this functions. > > I'm too weak in kernel cec internals - so maybe you have any pointers how to > further debug/investigate this issue? As we discussed in the pine64 room, this is still very likely a hardware issue with this board. A configuration issue with your u-boot or tf-a is also a possibility, but is less likely. You showed with your logic analyzer with nothing plugged in and cec not muxed to m1, data was present on m1. I requested you investigate the following, to which you haven't replied: Have you tried forcing m0 to be assigned to a device other than hdmi-cec? Have you checked if m1 is shorted to another pin? In regards to your data frames for 4.19 vs 5.18, image-view-on is not a valid command if the topology doesn't detect a device on the bus. I recommend running the same test, except run `cec-ctl -S --playback` and post the results for both. > > > > BTW: i'm not alone with cec issue on rock3a v1.31 - already 2 other users > contacted me with the same issue... > >
Re: [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support
On Fri, May 20, 2022 at 6:12 AM Sascha Hauer wrote: > > Hi Maya, > > On Fri, May 20, 2022 at 12:02:33PM +0200, Maya Matuszczyk wrote: > > Hello, > > > > wt., 17 maj 2022 o 20:28 Heiko Stuebner napisał(a): > > > > > > Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer: > > > > It's v11 time. There's only one small change to v10. Discussion seems to > > > > have settled now. Is there anything left that prevents the series from > > > > being merged? I'd really like to have it in during the next merge > > > > window. > > > > > > > > This series still depends on: > > > > drm/rockchip: Refactor IOMMU initialisation > > > > (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html) > > > > arm64: dts: rockchip: add basic dts for the radxa rock3 model a > > > > > > > > Sascha > > > > > > I've now picked up everything except the hdmi-rate stuff in some way. > > > The driver changes will go into 5.19 and the DT-changes into 5.20. > > > > > > I'll now move the series out of my focus and would expect further > > > hdmi rate voodoo to start a new series :-) . > > > > > > Thanks to all involved for working on this. > > > Heiko > > > > What do I need besides this patch series, mentioned before IOMMU refactor, > > and DTS changes for MIPI-DSI support on RK356x? > > I'm working on mainline kernel support for a a RK3566 board with > > a DSI display. > > Apart from these patches you'll need updates for the DSI. I've pushed > these once to > https://git.pengutronix.de/cgit/sha/linux/log/?h=rockchip-vop2-mipi > Particularly I think you need: > > 383ff250345f0 drm: rockchip: dw-mipi-dsi: Call host attach from probe > e79a16ead833d dw-mipi-dsi-rockchip: increase bandwidth > ac400bdd8d0cb drm: rockchip: dw-mipi-dsi-rockchip: Add rk3568 support > b6b7fabbc9fe2 drm: panel-simple: Add init sequence support > 3c13a030e92f3 arm64: dts: rockchip: rk3568-evb: Add Display support > 3433935a31675 arm64: dts: rockchip: rk356x: Add dsi nodes > > I'm not sure how well these fit onto the current state. I'll likely > update the branch when the VOP2 has hit mainline after the next merge > window. I have no plans currently to upstream the DSI bits though. Yeah DSI needs a bit of love with the merged version. Even updating the series to the new version we get a null pointer exception: [2.304528] Unable to handle kernel NULL pointer dereference at virtual address 0250 [2.305311] Mem abort info: [2.305563] ESR = 0x9605 [2.305839] EC = 0x25: DABT (current EL), IL = 32 bits [2.306311] SET = 0, FnV = 0 [2.306586] EA = 0, S1PTW = 0 [2.306868] FSC = 0x05: level 1 translation fault [2.307301] Data abort info: [2.307559] ISV = 0, ISS = 0x0005 [2.307926] CM = 0, WnR = 0 [2.308197] [0250] user address but active_mm is swapper [2.308763] Internal error: Oops: 9605 [#1] PREEMPT SMP [2.309260] Modules linked in: [2.309541] CPU: 0 PID: 51 Comm: kworker/u8:1 Not tainted 5.18.0-rc2-00072-g4d2476a40e3e-dirty #307 [2.310343] Hardware name: Pine64 RK3566 Quartz64-A Board (DT) [2.310862] Workqueue: events_unbound deferred_probe_work_func [2.311391] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [2.312010] pc : __drm_crtc_init_with_planes+0x44/0x2d0 [2.312482] lr : drm_crtc_init_with_planes+0x64/0x94 [2.312929] sp : ffc00aaa3830 [2.313226] x29: ffc00aaa3830 x28: 0001 x27: ffc00aaa38c0 [2.313866] x26: ffc009950fb0 x25: ff8100f24080 x24: ffc009452748 [2.314504] x23: ffc009950fb0 x22: x21: 0008 [2.315142] x20: ff8100d1e800 x19: ff8100f244e8 x18: fffd [2.315781] x17: 08d1 x16: 0891 x15: 0020 [2.316419] x14: x13: ff8100f24478 x12: ff8100f2445d [2.317057] x11: ffc00aaa3920 x10: ffc00aaa3920 x9 : ffc008843994 [2.317694] x8 : ffc00aaa3910 x7 : ffc00aaa3910 x6 : ffc00aaa38c0 [2.318333] x5 : ffc009950fb0 x4 : ffc0094522a0 x3 : [2.318970] x2 : 0008 x1 : ff8100f244e8 x0 : ff8100d1e800 [2.319609] Call trace: [2.319829] __drm_crtc_init_with_planes+0x44/0x2d0 [2.320268] drm_crtc_init_with_planes+0x64/0x94 [2.320684] vop2_bind+0x61c/0x960 [2.320996] component_bind_all+0x10c/0x270 [2.321374] rockchip_drm_bind+0xc0/0x20c [2.321738] try_to_bring_up_aggregate_device+0x16c/0x1e0 [2.31] __component_add+0xac/0x17c [2.322568] component_add+0x20/0x30 [2.322890] dw_mipi_dsi_rockchip_host_attach+0x60/0x11c [2.323365] dw_mipi_dsi_host_attach+0x80/0xd4 [2.323767] mipi_dsi_attach+0x34/0x50 [2.324107] feiyang_dsi_probe+0x100/0x17c [2.324476] mipi_dsi_drv_probe+0x2c/0x40 [2.324838] really_probe.part.0+0xa4/0x2a0 [2.325215] __driver_probe_device+0xa0/0x150 [2.325607]
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Thu, May 12, 2022 at 8:17 AM Robin Murphy wrote: > > On 2022-05-08 17:53, Peter Geis wrote: > > On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk > > wrote: > >> > >> > >> > >>> Wiadomość napisana przez Sascha Hauer w dniu > >>> 22.04.2022, o godz. 09:28: > >>> > >>> From: Michael Riesch > >>> > >>> Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > >>> ROCK3 Model A. > >>> > >>> Signed-off-by: Michael Riesch > >>> Reported-by: kernel test robot > >>> Link: > >>> https://lore.kernel.org/r/20220310210352.451136-4-michael.rie...@wolfvision.net > >>> Signed-off-by: Sascha Hauer > >>> --- > >> > >> Sascha, Michael, > > > > Good Afternoon, > >> > >> I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. > >> Recently i started to work on rock3-a (rk3568). > >> v11 gives me video, audio - but cec is not working on rock3-a. > >> > >> I was told: > >> > >> 32k clock needed for cec and this clock is generated by the rtc which is > >> embedded in the rk8xx regulator. > >> So you should make sure it is enabled when hdmi is powerd on, eg adding it > >> to the RK3568_PD_VO powerdomain should help > >> > >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is > >> still non-functional > >> > >> Maybe You have some hints/pointers here? > > > > Add the following to the HDMI node: > > assigned-clocks = < CLK_HDMI_CEC>; > > assigned-clock-rates = <32768>; > > > > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which > > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to > > function. > > I submitted a patch to have the hdmi driver handle this, but it broke > > other SoCs because 32k is an optional clock. > > Since this is the case, I'd like Robin to weigh in on going the > > assigned-clock route again. > > (did you mean to CC me or have I missed another thread elsewhere?) Apologies, I made an unsafe assumption here. > > FWIW I still think it would be good to fix the clock driver(s) and/or > DTs to correctly deal with the availability and configuration of xin_32k > where appropriate. However, much like the HCLK_VO mess I guess that's a > larger cleanup tangent in its own right, so using "assigned-clocks" for > this one case in the meantime doesn't seem unreasonable. I was > optimistic for the cleanest, most generic solution, but if reality gets > in the way then oh well. I was thinking about this problem and came to a realization. The root dtsi files all have clk32k_in defined, even though it's listed as an optional clock. I think this should move to the device boards (much like the gmac input clock) that have it. The clock driver might need some help coping with it being missing, I haven't tested this. > > Judging by the datasheet, RK3568 might actually have a similar situation > with its clk32k_in pin, so you may want "assigned-clock-parents" as well > to ensure the whole clk_rtc32k branch is really set up the way you > currently expect - baking any more assumptions into DTBs now only seems > to add potential for breakage if kernel behaviour changes in future. rk3568 defaults to using a clock divider from the 24m clock, so it works even in the absence of clk32_in. It seemed rk3399 did as well, but unlike rk3568 it would switch to clk32k_in if the exact frequency was chosen. Implementing the above would fix that issue, and we can then implement the driver fix. > > Robin. Very Respectfully, Peter
[PATCH v2 3/3] arm64: dts: rockchip: add pine64 touch panel display to rockpro64
The Pine64 touch panel is a panel consisting of the Feiyang fy07024di26a30d
panel with a Goodix gt911 touch screen. Add the device tree nodes to the
rockpro64 to permit attaching this display to the device.
Signed-off-by: Peter Geis
---
.../boot/dts/rockchip/rk3399-rockpro64.dtsi | 80 ++-
1 file changed, 76 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index 45e77f86d329..f0fb450ddba6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -20,6 +20,15 @@ chosen {
stdout-path = "serial2:150n8";
};
+ /* enable for panel backlight support */
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 100 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ status = "disabled";
+ };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <12500>;
@@ -220,6 +229,14 @@ vdd_log: vdd-log {
regulator-min-microvolt = <80>;
regulator-max-microvolt = <170>;
};
+
+ avdd: avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "avdd";
+ regulator-min-microvolt = <1100>;
+ regulator-max-microvolt = <1100>;
+ vin-supply = <_s0>;
+ };
};
_l0 {
@@ -301,6 +318,11 @@ {
status = "okay";
};
+/* force hdmi to vopb */
+_in_vopl {
+ status = "disabled";
+};
+
_sound {
status = "okay";
};
@@ -400,8 +422,6 @@ regulator-state-mem {
vcc3v0_touch: LDO_REG2 {
regulator-name = "vcc3v0_touch";
- regulator-always-on;
- regulator-boot-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-state-mem {
@@ -490,8 +510,6 @@ regulator-state-mem {
vcc3v3_s0: SWITCH_REG2 {
regulator-name = "vcc3v3_s0";
- regulator-always-on;
- regulator-boot-on;
regulator-state-mem {
regulator-off-in-suspend;
};
@@ -565,6 +583,19 @@ fusb0: typec-portc@22 {
vbus-supply = <_typec>;
status = "okay";
};
+
+ /* enable for pine64 touch screen support */
+ touch: touchscreen@5d {
+ compatible = "goodix,gt911";
+ reg = <0x5d>;
+ AVDD28-supply = <_touch>;
+ VDDIO-supply = <_touch>;
+ interrupt-parent = <>;
+ interrupts = ;
+ irq-gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ status = "disabled";
+ };
};
{
@@ -600,6 +631,47 @@ _domains {
gpio1830-supply = <_3v0>;
};
+/* enable for pine64 panel display support */
+_dsi {
+ status = "disabled";
+ clock-master;
+
+ ports {
+ mipi_out: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <_in_panel>;
+ };
+ };
+ };
+
+ mipi_panel: panel@0 {
+ compatible = "feiyang,fy07024di26a30d";
+ reg = <0>;
+ avdd-supply = <>;
+ backlight = <>;
+ dvdd-supply = <_s0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_in_panel: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+ };
+};
+
+/* force dsi to vopl */
+_in_vopb {
+ status="disabled";
+};
+
{
ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
--
2.25.1
[PATCH v2 2/3] drm/panel: feiyang-fy07024di26a30d: make reset gpio optional
Some implementations do not use the reset signal, instead tying it to dvdd. Make the reset gpio optional to permit this. Signed-off-by: Peter Geis --- drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c index a9cd7135cb51..ee61d60eceae 100644 --- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c +++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c @@ -209,7 +209,7 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi) return dev_err_probe(>dev, PTR_ERR(ctx->avdd), "Couldn't get avdd regulator\n"); - ctx->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW); + ctx->reset = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW); if (IS_ERR(ctx->reset)) return dev_err_probe(>dev, PTR_ERR(ctx->reset), "Couldn't get our reset GPIO\n"); -- 2.25.1
[PATCH v2 1/3] dt-bindings: display: panel: feiyang, fy07024di26a30d: make reset gpio optional
Some implementations do not use the reset signal, instead tying it to dvdd. Make the reset gpio optional to permit this. Signed-off-by: Peter Geis Acked-by: Rob Herring --- .../bindings/display/panel/feiyang,fy07024di26a30d.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 95acf9e96f1c..1cf84c8dd85e 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -35,7 +35,6 @@ required: - reg - avdd-supply - dvdd-supply - - reset-gpios additionalProperties: false -- 2.25.1
[PATCH v2 0/3] add Pine64 touch panel support to rockpro64
Good Morning, Apologies Heiko on taking so long for this v2. This patch series adds support for the Pine64 touch panel to the rockpro64 single board computer. This panel attaches to the dsi port and includes an i2c touch screen. The first two patches involve making the reset pin to the Feiyang fy07024di26a30d panel optional. On the rockpro64 and quartz64-a this pin is tied to dvdd and automatically comes high when power is applied. The third patch adds the device tree nodes to rockpro64 to permit the panel to be used. Changelog: v2: - Drop patch 4 so we don't "enable" the nodes - Drop the unnecessary null checks - Rebase to 5.18-rc1 Peter Geis (3): dt-bindings: display: panel: feiyang, fy07024di26a30d: make reset gpio optional drm/panel: feiyang-fy07024di26a30d: make reset gpio optional arm64: dts: rockchip: add pine64 touch panel display to rockpro64 .../panel/feiyang,fy07024di26a30d.yaml| 1 - .../boot/dts/rockchip/rk3399-rockpro64.dtsi | 80 ++- .../drm/panel/panel-feiyang-fy07024di26a30d.c | 2 +- 3 files changed, 77 insertions(+), 6 deletions(-) -- 2.25.1
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Tue, May 10, 2022 at 4:54 PM Peter Geis wrote: > > On Tue, May 10, 2022 at 9:49 AM Piotr Oniszczuk > wrote: > > > > > > > > > Wiadomość napisana przez Peter Geis w dniu > > > 10.05.2022, o godz. 14:08: > > > > > > > > > You are on the clk_rtc32k_frac which is a fractional divider that is > > > fed from the 24m clock. Your clock likely isn't the issue here. I'd > > > recommend setting up the cec-gpio node to validate your hardware > > > works. > > > > Peter, > > > > Here is what i done to verify my rock3-a HW: > > > > 1.download & burn on SD Radxa Ubuntu > > 2.boot and install v4l-utils > > 3.run cec-compliance -v -T. It fails with error -22 > > 4.decompile Ubunntu DT. > > 5.Check what HDMITX_CEC_M hdmi uses. It was M0 > > 6.Chenge to HDMITX_CEC_M1; compile dtb; install on sd > > 7.reboot. > > 8.cec-compliance -v -T gives all tests OK > > 9.cec-ctl --image-view-on -t0 turns-on my TV > > > > hope this proves my HW is ok? > > > > That does show that the hardware works with the oem image. It does not > unfortunately prove if it works with your current dts. cec-gpio will > show if it's an issue with the cec controller or an external problem. I've pulled your dts and with a few fixes got a working system from it. At least on the v1.1 board cec is functional: Total for dwhdmi-rockchip device /dev/cec0: 1, Succeeded: 1, Failed: 0, Warnings: 0
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Tue, May 10, 2022 at 9:49 AM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Peter Geis w dniu > > 10.05.2022, o godz. 14:08: > > > > > > You are on the clk_rtc32k_frac which is a fractional divider that is > > fed from the 24m clock. Your clock likely isn't the issue here. I'd > > recommend setting up the cec-gpio node to validate your hardware > > works. > > Peter, > > Here is what i done to verify my rock3-a HW: > > 1.download & burn on SD Radxa Ubuntu > 2.boot and install v4l-utils > 3.run cec-compliance -v -T. It fails with error -22 > 4.decompile Ubunntu DT. > 5.Check what HDMITX_CEC_M hdmi uses. It was M0 > 6.Chenge to HDMITX_CEC_M1; compile dtb; install on sd > 7.reboot. > 8.cec-compliance -v -T gives all tests OK > 9.cec-ctl --image-view-on -t0 turns-on my TV > > hope this proves my HW is ok? > That does show that the hardware works with the oem image. It does not unfortunately prove if it works with your current dts. cec-gpio will show if it's an issue with the cec controller or an external problem.
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Tue, May 10, 2022 at 3:29 AM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Peter Geis w dniu > > 10.05.2022, o godz. 03:35: > > > > Could you grab the clock tree from /sys/kernel/debug/clk/clk_summary > > for the clk_hdmi_cec tree? > > Here it is: > enable prepare protect > duty hardware >clock countcountcountrate > accuracy phase cycleenable > --- >clk_rtc32k_frac 110 32768 > 0 0 5 Y >clk_rtc_32k110 32768 > 0 0 5 Y > clk_hdmi_cec120 32768 > 0 0 5 Y You are on the clk_rtc32k_frac which is a fractional divider that is fed from the 24m clock. Your clock likely isn't the issue here. I'd recommend setting up the cec-gpio node to validate your hardware works.
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Mon, May 9, 2022 at 3:49 PM Piotr Oniszczuk wrote: > > > > > If you want to confirm the hardware is configured correctly you can > > remove the cec pin from the hdmi node and set up a cec-gpio node. > > https://elixir.bootlin.com/linux/v5.18-rc5/source/Documentation/devicetree/bindings/media/cec-gpio.txt > > > > For some reason the board developers decided to make this selectable, > > check the location of R90652 and R90653. > > > > Peter, > > my board is v1.31 and is using HDMITX_CEC_M1 i think. > I verified this by temp. changing to HDMITX_CEC_M0 > > For M1: > 2022-05-09 21:12:37.130188 I CECAdapter: Using physical address 1.0.0.0 from > EDID > 2022-05-09 21:12:37.173267 I CECAdapter: Found 1 CEC devices(s). > 2022-05-09 21:12:37.173299 I CECAdapter: Device 1: path '/dev/cec0' com port > 'Linux' SELECTED > 2022-05-09 21:12:37.173307 I CECAdapter: Trying to open device /dev/cec0 > (Linux). > 2022-05-09 21:12:37.180095 I CECAdapter: connection opened > 2022-05-09 21:12:37.545229 I CECAdapter: setting HDMI port to 1 on device TV > (0) > 2022-05-09 21:12:37.904145 I CECAdapter: >> source deactivated: Playback 1 > (4) > 2022-05-09 21:12:37.904311 I CECAdapter: Source 4 Deactivated > 2022-05-09 21:12:38.284452 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:12:38.284492 I CECAdapter: Source 4 Activated > 2022-05-09 21:12:38.284694 I CECAdapter: CEC client registered: libCEC > version = 6.0.2, client version = 6.0.2, firmware version = 0, logical > address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: > v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 > 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux > 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux > 2022-05-09 21:12:38.519394 I CECAdapter: Opened CEC device. > 2022-05-09 21:12:38.636950 I CECAdapter: << powering on 'TV' (0) > 2022-05-09 21:12:38.754023 E CECAdapter: Failed to turn TV on. > 2022-05-09 21:12:38.754313 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:12:38.754343 I CECAdapter: Source 4 Activated > 2022-05-09 21:12:38.872079 I CECAdapter: << Playback 1 (4) -> broadcast (F): > active source (1000) > 2022-05-09 21:12:38.974698 I CECAdapter: Asked TV to switch to this input. > 2022-05-09 21:13:07.292069 W CECAdapter: CEC device can't poll TV: TV does > not respond to CEC polls > 2022-05-09 21:13:37.296372 W CECAdapter: CEC device can't poll TV: TV does > not respond to CEC polls > > for M0: > 2022-05-09 21:37:47.632175 I CECAdapter: Using physical address 1.0.0.0 from > EDID > 2022-05-09 21:37:47.680618 I CECAdapter: Found 1 CEC devices(s). > 2022-05-09 21:37:47.680644 I CECAdapter: Device 1: path '/dev/cec0' com port > 'Linux' SELECTED > 2022-05-09 21:37:47.680654 I CECAdapter: Trying to open device /dev/cec0 > (Linux). > 2022-05-09 21:37:47.694974 I CECAdapter: connection opened > 2022-05-09 21:37:56.341846 I CECAdapter: setting HDMI port to 1 on device TV > (0) > 2022-05-09 21:38:17.675457 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:38:17.675561 I CECAdapter: Source 4 Activated > 2022-05-09 21:38:17.675657 I CECAdapter: CEC client registered: libCEC > version = 6.0.2, client version = 6.0.2, firmware version = 0, logical > address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: > v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 > 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux > 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux > 2022-05-09 21:38:30.475336 I CECAdapter: Opened CEC device. > 2022-05-09 21:38:34.741846 I CECAdapter: << Playback 1 (4) -> broadcast (F): > active source (1000) > 2022-05-09 21:38:39.008432 I CECAdapter: << powering on 'TV' (0) > 2022-05-09 21:38:39.008506 E CECAdapter: > CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - > tx_status=00 errno=22 > 2022-05-09 21:38:39.008526 E CECAdapter: > CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - > tx_status=00 errno=22 > 2022-05-09 21:38:43.275094 E CECAdapter: Failed to turn TV on. > 2022-05-09 21:38:43.275201 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:38:43.275224 I CECAdapter: Source 4 Activated > 2022-05-09 21:38:43.275375 W CECAdapter: CEC device can't poll TV: TV does > not respond to CEC polls > 2022-05-09 21:38:47.541811 I CECAdapter: << Playback 1 (4) -> broadcast (F): > active source (1000) > 2022-05-09 21:38:47.541898 E CECAdapter: > CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - > tx_status=00 errno=22 > 2022-05-09 21:38:47.541909 E CECAdapter: > CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - > tx_status=00 errno=22 > 2022-05-09 21:38:47.541924 E CECAdapter: Failed to switch to this input. > 2022-05-09 21:38:51.808626 I CECAdapter: << Playback 1 (4) -> broadcast (F): > active
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Sun, May 8, 2022 at 2:21 PM Piotr Oniszczuk
wrote:
>
>
> >>
> >> I think i have this already (pls see L231/L232 in
> >> https://pastebin.com/67wu9QrH )
> >
> > I see you have hdmitxm1_cec as the enabled pin. Are you certain it's
> > the m1 pin and not the m0 pin?
>
> It depends on board ver.
> pls look:
> https://github.com/radxa/kernel/commit/c1d727692e85c0a265913a72e517cf2bd71131ba
If you want to confirm the hardware is configured correctly you can
remove the cec pin from the hdmi node and set up a cec-gpio node.
https://elixir.bootlin.com/linux/v5.18-rc5/source/Documentation/devicetree/bindings/media/cec-gpio.txt
For some reason the board developers decided to make this selectable,
check the location of R90652 and R90653.
>
> >>
> >> Maybe i miss something but adding:
> >>
> >> _otg {
> >>phy-supply = <_usb_host>;
> >>status = "okay";
> >> };
> >>
> >> breaks working usb3 port0
> >> (so none of usb3 ports are working)
> >
> > Please pass along a full dmesg in this configuration.
>
> Here it is: https://pastebin.com/uArtBLaZ
I have some concerns about the DTS you've built here. For instance how
come you are modifying the power domains?
USB3 is broken because the rock3-a is a rk3568 device and you're
missing combophy0.
>
>
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Sun, May 8, 2022 at 1:36 PM Piotr Oniszczuk
wrote:
>
>
>
> > Wiadomość napisana przez Peter Geis w dniu
> > 08.05.2022, o godz. 18:53:
> >
> >>
> >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is
> >> still non-functional
> >>
> >> Maybe You have some hints/pointers here?
> >
> > Add the following to the HDMI node:
> > assigned-clocks = < CLK_HDMI_CEC>;
> > assigned-clock-rates = <32768>;
>
> I think i have this already (pls see L231/L232 in
> https://pastebin.com/67wu9QrH )
I see you have hdmitxm1_cec as the enabled pin. Are you certain it's
the m1 pin and not the m0 pin?
>
> >
> >>
> >> br
> >>
> >> btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3
> >> port1 is non-working
> >> maybe you know what is missing?
> >
> > You're missing _otg.
>
> Maybe i miss something but adding:
>
> _otg {
> phy-supply = <_usb_host>;
> status = "okay";
> };
>
> breaks working usb3 port0
> (so none of usb3 ports are working)
Please pass along a full dmesg in this configuration.
>
>
Re: [PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a
On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk wrote: > > > > > Wiadomość napisana przez Sascha Hauer w dniu > > 22.04.2022, o godz. 09:28: > > > > From: Michael Riesch > > > > Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > > ROCK3 Model A. > > > > Signed-off-by: Michael Riesch > > Reported-by: kernel test robot > > Link: > > https://lore.kernel.org/r/20220310210352.451136-4-michael.rie...@wolfvision.net > > Signed-off-by: Sascha Hauer > > --- > > Sascha, Michael, Good Afternoon, > > I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. > Recently i started to work on rock3-a (rk3568). > v11 gives me video, audio - but cec is not working on rock3-a. > > I was told: > > 32k clock needed for cec and this clock is generated by the rtc which is > embedded in the rk8xx regulator. > So you should make sure it is enabled when hdmi is powerd on, eg adding it to > the RK3568_PD_VO powerdomain should help > > I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still > non-functional > > Maybe You have some hints/pointers here? Add the following to the HDMI node: assigned-clocks = < CLK_HDMI_CEC>; assigned-clock-rates = <32768>; The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to function. I submitted a patch to have the hdmi driver handle this, but it broke other SoCs because 32k is an optional clock. Since this is the case, I'd like Robin to weigh in on going the assigned-clock route again. > > br > > btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3 port1 > is non-working > maybe you know what is missing? You're missing _otg. Very Respectfully, Peter Geis
Re: [PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
On Sun, Mar 13, 2022 at 6:13 AM Piotr Oniszczuk
wrote:
>
>
>
> > Wiadomość napisana przez Peter Geis w dniu
> > 26.01.2022, o godz. 21:24:
> >
> > The hdmi-cec clock must be 32khz in order for cec to work correctly.
> > Ensure after enabling the clock we set it in order for the hardware to
> > work as expected.
> > Warn on failure, in case this is a static clock that is slighty off.
> > Fixes hdmi-cec support on Rockchip devices.
> >
> > Fixes: ebe32c3e282a ("drm/bridge: synopsys/dw-hdmi: Enable cec clock")
> >
> > Signed-off-by: Peter Geis
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 54d8fdad395f..1a96da60e357 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -48,6 +48,9 @@
> >
> > #define HDMI14_MAX_TMDSCLK34000
> >
> > +/* HDMI CEC needs a clock rate of 32khz */
> > +#define HDMI_CEC_CLK_RATE32768
> > +
> > enum hdmi_datamap {
> > RGB444_8B = 0x01,
> > RGB444_10B = 0x03,
> > @@ -3347,6 +3350,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
> > *pdev,
> > ret);
> > goto err_iahb;
> > }
> > +
> > + ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
> > + if (ret)
> > + dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate:
> > %d\n", ret);
> > }
> >
> > /* Product and revision IDs */
> > --
> > 2.25.1
> >
> >
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
> Peter,
>
> On my 5.17-rc7 with applied rk356x VOP2 v8 series - this patch makes CEC
> working on rk3566.
> Unfortunately it breaks working ok CEC on rk3399 rockpi-4b.
>
> Reverting this patch brings back CEC on rk3399 - but rk3366 becomes with non
> working CEC
>
> I'm not sure how to move forward with this
I was worried about that, thanks for testing it.
Can you send me the cec_clk rate before and after this patch?
>
> br
Re: [PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
On Thu, Jan 27, 2022 at 4:33 AM Sascha Hauer wrote: > > Hi Peter, > > On Wed, Jan 26, 2022 at 03:24:26PM -0500, Peter Geis wrote: > > The hdmi-cec clock must be 32khz in order for cec to work correctly. > > Ensure after enabling the clock we set it in order for the hardware to > > work as expected. > > Warn on failure, in case this is a static clock that is slighty off. > > Fixes hdmi-cec support on Rockchip devices. > > You removed this sentence in v2, but I just wanted to mention that > clk_set_rate() won't fail when the desired clock rate can't be > archieved. Instead, you will get the best rate that actually can be > reached. If you want to check that you are happy with the rate you'll > have to do a clk_round_rate() before setting the rate or a > clk_get_rate() afterwards. Thanks, the behavior in v2 is actually what I'm looking for. I dug into clk_set_rate while checking into its interaction with clk_prepare and I came to this conclusion. > > Sascha > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v2] drm/bridge: synopsys/dw-hdmi: set cec clock rate
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure before enabling the clock we set it in order for the hardware to
work as expected.
Fixes hdmi-cec support on Rockchip devices.
Fixes: ebe32c3e282a ("drm/bridge: synopsys/dw-hdmi: Enable cec clock")
Signed-off-by: Peter Geis
---
Changelog:
v2:
- Set the clock rate before enabling the clock
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f..65c16455b76a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -48,6 +48,9 @@
#define HDMI14_MAX_TMDSCLK 34000
+/* HDMI CEC needs a clock rate of 32khz */
+#define HDMI_CEC_CLK_RATE 32768
+
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -3341,6 +3344,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
*pdev,
hdmi->cec_clk = NULL;
goto err_iahb;
} else {
+ ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
+ if (ret)
+ dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate:
%d\n", ret);
+
ret = clk_prepare_enable(hdmi->cec_clk);
if (ret) {
dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
--
2.25.1
[PATCH] drm/bridge: synopsys/dw-hdmi: set cec clock rate
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after enabling the clock we set it in order for the hardware to
work as expected.
Warn on failure, in case this is a static clock that is slighty off.
Fixes hdmi-cec support on Rockchip devices.
Fixes: ebe32c3e282a ("drm/bridge: synopsys/dw-hdmi: Enable cec clock")
Signed-off-by: Peter Geis
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f..1a96da60e357 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -48,6 +48,9 @@
#define HDMI14_MAX_TMDSCLK 34000
+/* HDMI CEC needs a clock rate of 32khz */
+#define HDMI_CEC_CLK_RATE 32768
+
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -3347,6 +3350,10 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
*pdev,
ret);
goto err_iahb;
}
+
+ ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
+ if (ret)
+ dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate:
%d\n", ret);
}
/* Product and revision IDs */
--
2.25.1
Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
On Wed, Jan 26, 2022 at 2:25 PM Robin Murphy wrote:
>
> On 2022-01-26 18:44, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
> >>
> >> On 2022-01-26 16:04, Peter Geis wrote:
> >>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer
> >>> wrote:
> >>>>
> >>>> Add support for the HDMI port found on RK3568.
> >>>>
> >>>> Signed-off-by: Sascha Hauer
> >>>> ---
> >>>>arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
> >>>>1 file changed, 36 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> index 4008bd666d01..e38fb223e9b8 100644
> >>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> @@ -10,7 +10,6 @@
> >>>>#include
> >>>>#include
> >>>>#include
> >>>> -#include
> >>>>#include
> >>>>
> >>>>/ {
> >>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>> + hdmi: hdmi@fe0a {
> >>>> + compatible = "rockchip,rk3568-dw-hdmi";
> >>>> + reg = <0x0 0xfe0a 0x0 0x2>;
> >>>> + interrupts = ;
> >>>> + clocks = < PCLK_HDMI_HOST>,
> >>>> +< CLK_HDMI_SFR>,
> >>>> +< CLK_HDMI_CEC>,
> >>>> +< CLK_HDMI_REF>,
> >>>> +< HCLK_VOP>;
> >>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >>>> + pinctrl-names = "default";
> >>>> + pinctrl-0 = <_scl _sda _cec>;
> >>>
> >>> I looked into CEC support here, and it seems that it does work with one
> >>> change.
> >>> Please add the two following lines to your patch:
> >>> assigned-clocks = < CLK_HDMI_CEC>;
> >>> assigned-clock-rates = <32768>;
> >>>
> >>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> >>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> >>> function.
> >>
> >> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> >> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
> >
> > This is handled purely in the
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
> > touch it there as it would affect all users, not just Rockchip.
>
> I'd have a strong hunch that it's a standard thing for the DesignWare IP
> and not affected by platform integration. I don't have the magical
> Synopsys databook, but between the trusty old i.MX6 manual and most of
> the other in-tree DTs getting their dw-hdmi "cec" clock from
> suspiciously-obviously-named sources, I'd be somewhat surprised if it
> was ever anything other than 32KHz.
My main concern was similar to the other HDMI clock issues, mainly
setting the clock can propagate up and affect other users of the
upstream clock.
I'll spin up a quick patch for this method.
Thanks,
Peter
>
> Robin.
>
> > Could someone familiar with the dw-hdmi IP weigh in on the minimum and
> > maximum clock rate the CEC block can handle?
> >
> >>
> >> Robin.
> >>
> >>>> + power-domains = < RK3568_PD_VO>;
> >>>> + reg-io-width = <4>;
> >>>> + rockchip,grf = <>;
> >>>> + #sound-dai-cells = <0>;
> >>>> + status = "disabled";
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + hdmi_in: port@0 {
> >>>> + reg = <0>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> +
> >>>> + hdmi_out: port@1 {
> >>>> + reg = <1>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +
> >>>> qos_gpu: qos@fe128000 {
> >>>> compatible = "rockchip,rk3568-qos", "syscon";
> >>>> reg = <0x0 0xfe128000 0x0 0x20>;
> >>>> --
> >>>> 2.30.2
> >>>>
> >>>
> >>> ___
> >>> Linux-rockchip mailing list
> >>> linux-rockc...@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
>
> On 2022-01-26 16:04, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
> >>
> >> Add support for the HDMI port found on RK3568.
> >>
> >> Signed-off-by: Sascha Hauer
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
> >> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> index 4008bd666d01..e38fb223e9b8 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> @@ -10,7 +10,6 @@
> >> #include
> >> #include
> >> #include
> >> -#include
> >> #include
> >>
> >> / {
> >> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >> status = "disabled";
> >> };
> >>
> >> + hdmi: hdmi@fe0a {
> >> + compatible = "rockchip,rk3568-dw-hdmi";
> >> + reg = <0x0 0xfe0a 0x0 0x2>;
> >> + interrupts = ;
> >> + clocks = < PCLK_HDMI_HOST>,
> >> +< CLK_HDMI_SFR>,
> >> +< CLK_HDMI_CEC>,
> >> +< CLK_HDMI_REF>,
> >> +< HCLK_VOP>;
> >> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <_scl _sda _cec>;
> >
> > I looked into CEC support here, and it seems that it does work with one
> > change.
> > Please add the two following lines to your patch:
> > assigned-clocks = < CLK_HDMI_CEC>;
> > assigned-clock-rates = <32768>;
> >
> > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> > function.
>
> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
This is handled purely in the
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
touch it there as it would affect all users, not just Rockchip.
Could someone familiar with the dw-hdmi IP weigh in on the minimum and
maximum clock rate the CEC block can handle?
>
> Robin.
>
> >> + power-domains = < RK3568_PD_VO>;
> >> + reg-io-width = <4>;
> >> + rockchip,grf = <>;
> >> + #sound-dai-cells = <0>;
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + hdmi_in: port@0 {
> >> + reg = <0>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> +
> >> + hdmi_out: port@1 {
> >> + reg = <1>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> + };
> >> + };
> >> +
> >> qos_gpu: qos@fe128000 {
> >> compatible = "rockchip,rk3568-qos", "syscon";
> >> reg = <0x0 0xfe128000 0x0 0x20>;
> >> --
> >> 2.30.2
> >>
> >
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> index 4008bd666d01..e38fb223e9b8 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> @@ -10,7 +10,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> / {
> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> status = "disabled";
> };
>
> + hdmi: hdmi@fe0a {
> + compatible = "rockchip,rk3568-dw-hdmi";
> + reg = <0x0 0xfe0a 0x0 0x2>;
> + interrupts = ;
> + clocks = < PCLK_HDMI_HOST>,
> +< CLK_HDMI_SFR>,
> +< CLK_HDMI_CEC>,
> +< CLK_HDMI_REF>,
> +< HCLK_VOP>;
> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> + pinctrl-names = "default";
> + pinctrl-0 = <_scl _sda _cec>;
I looked into CEC support here, and it seems that it does work with one change.
Please add the two following lines to your patch:
assigned-clocks = < CLK_HDMI_CEC>;
assigned-clock-rates = <32768>;
The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
function.
> + power-domains = < RK3568_PD_VO>;
> + reg-io-width = <4>;
> + rockchip,grf = <>;
> + #sound-dai-cells = <0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hdmi_in: port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + hdmi_out: port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + };
> +
> qos_gpu: qos@fe128000 {
> compatible = "rockchip,rk3568-qos", "syscon";
> reg = <0x0 0xfe128000 0x0 0x20>;
> --
> 2.30.2
>
[PATCH 2/4] drm/panel: feiyang-fy07024di26a30d: make reset gpio optional
Some implementations do not use the reset signal, instead tying it to dvdd.
Make the reset gpio optional to permit this.
Signed-off-by: Peter Geis
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..1c88d752b14e 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -65,7 +65,8 @@ static int feiyang_prepare(struct drm_panel *panel)
/* T3 (dvdd rise + avdd start + avdd rise) T3 >= 20ms */
msleep(20);
- gpiod_set_value(ctx->reset, 0);
+ if (ctx->reset)
+ gpiod_set_value(ctx->reset, 0);
/*
* T5 + T6 (avdd rise + video & logic signal rise)
@@ -73,7 +74,8 @@ static int feiyang_prepare(struct drm_panel *panel)
*/
msleep(20);
- gpiod_set_value(ctx->reset, 1);
+ if (ctx->reset)
+ gpiod_set_value(ctx->reset, 1);
/* T12 (video & logic signal rise + backlight rise) T12 >= 200ms */
msleep(200);
@@ -126,7 +128,8 @@ static int feiyang_unprepare(struct drm_panel *panel)
/* T13 (backlight fall + video & logic signal fall) T13 >= 200ms */
msleep(200);
- gpiod_set_value(ctx->reset, 0);
+ if (ctx->reset)
+ gpiod_set_value(ctx->reset, 0);
regulator_disable(ctx->avdd);
@@ -211,7 +214,7 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
return PTR_ERR(ctx->avdd);
}
- ctx->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ ctx->reset = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset)) {
dev_err(>dev, "Couldn't get our reset GPIO\n");
return PTR_ERR(ctx->reset);
--
2.32.0
[PATCH 1/4] dt-bindings: display: panel: feiyang, fy07024di26a30d: make reset gpio optional
Some implementations do not use the reset signal, instead tying it to dvdd. Make the reset gpio optional to permit this. Signed-off-by: Peter Geis --- .../bindings/display/panel/feiyang,fy07024di26a30d.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 95acf9e96f1c..1cf84c8dd85e 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -35,7 +35,6 @@ required: - reg - avdd-supply - dvdd-supply - - reset-gpios additionalProperties: false -- 2.32.0
[PATCH 0/4] add pine64 touch panel support to rockpro64
This patch series adds support for the Pine64 touch panel to the rockpro64 single board computer. This panel attaches to the dsi port and includes an i2c touch screen. The first two patches involve making the reset pin to the Feiyang fy07024di26a30d panel optional. On the rockpro64 and quartz64-a this pin is tied to dvdd and automatically comes high when power is applied. The third patch adds the device tree nodes to rockpro64 to permit the panel to be used. The fourth patch is an example patch to enable this support, tagged do not merge as this is something for the end user to enable only when they have the panel attached. Peter Geis (4): dt-bindings: display: panel: feiyang,fy07024di26a30d: make reset gpio optional drm/panel: feiyang-fy07024di26a30d: make reset gpio optional arm64: dts: rockchip: add pine64 touch panel display to rockpro64 arm64: dts: rockchip: enable the pine64 touch screen on rockpro64 .../panel/feiyang,fy07024di26a30d.yaml| 1 - .../boot/dts/rockchip/rk3399-rockpro64.dtsi | 80 ++- .../drm/panel/panel-feiyang-fy07024di26a30d.c | 11 ++- 3 files changed, 83 insertions(+), 9 deletions(-) -- 2.32.0
[PATCH 0/4] add pine64 touch panel support to rockpro64
This patch series adds support for the Pine64 touch panel to the rockpro64 single board computer. This panel attaches to the dsi port and includes an i2c touch screen. The first two patches involve making the reset pin to the Feiyang fy07024di26a30d panel optional. On the rockpro64 and quartz64-a this pin is tied to dvdd and automatically comes high when power is applied. The third patch adds the device tree nodes to rockpro64 to permit the panel to be used. The fourth patch is an example patch to enable this support, tagged do not merge as this is something for the end user to enable only when they have the panel attached. Peter Geis (4): dt-bindings: display: panel: feiyang,fy07024di26a30d: make reset gpio optional drm/panel: feiyang-fy07024di26a30d: make reset gpio optional arm64: dts: rockchip: add pine64 touch panel display to rockpro64 arm64: dts: rockchip: enable the pine64 touch screen on rockpro64 .../panel/feiyang,fy07024di26a30d.yaml| 1 - .../boot/dts/rockchip/rk3399-rockpro64.dtsi | 80 ++- .../drm/panel/panel-feiyang-fy07024di26a30d.c | 11 ++- 3 files changed, 83 insertions(+), 9 deletions(-) -- 2.32.0
Re: [BUG] dw-mipi-dsi-rockchip display corruption with dsi panel
On Tue, Aug 10, 2021 at 7:11 PM Heiko Stübner wrote:
>
> Hi Peter,
>
> Am Mittwoch, 11. August 2021, 00:31:24 CEST schrieb Peter Geis:
> > Good Evening,
> >
> > I've been attempting to light off the feiyang fy07024di26a30d panel on
> > the rockpro64. This is the official panel from the Pine64 store.
> > I've confirmed it works with the downstream kernel on both the rk3399
> > and rk3566, but on the mainline driver the display is partially
> > corrupted (see attached photo: [1]).
> >
> > As you can see, the left half of the display is fine, but the right half
> > of the display is corrupted with the pixels smearing horizontally.
> >
> > I saw when the panel was added, some additional code was added to
> > handle burst mode in the sun6_mipi_dsi driver [2].
> > I've seen that the dw-mipi-dsi driver appears to already support burst
> > mode and I can't find anything out of place there.
> > I also haven't had much success finding anything obviously different in
> > the downstream driver vs the upstream driver that would explain this.
> >
> > Attached below is the in-progress dts changes for an example of how the
> > panel is plugged in.
>
> is that really a dual-dsi panel needing two dsi controllers to drive it?
>
> With that tiny resultion of 1024x600 I definitly wouldn't expect this,
> in contrast to say the 2048x1536 dual-dsi displays used in the
> Gru-Scarlet ChromeOS tablets.
>
> So maybe just drop the 2nd dsi controller connection in a first step?
> Because I really don't think that is the case on the hardware.
>
> The dual-dsi setup means that you have one vop supplying half of its
> display data to each of the 2 involved dsi controllers. And you're missing
> in fact half of your display data.
Thanks, that was it.
I had tried removing the link previously, but I had to also disable
that controller altogether or the vop fails to probe silently.
That is a common issue I ran into when getting this all set up,
anything failed to probe for the dsi panel the vop just silently dies
in the background and graphics fail everywhere.
>
>
> Heiko
>
>
>
> > I admit, I have little understanding of the mipi-dsi internal workings,
> > so I'm reaching out to the experts on how to correct this.
> >
> > Thank you for your time,
> > Peter Geis
> >
> > [1] https://photos.app.goo.gl/LBA9M2WcweGaEb4cA
> > [2]
> > https://patchwork.kernel.org/project/linux-arm-kernel/cover/20181116163916.29621-1-ja...@amarulasolutions.com/
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > index 687a5afa5d2c..af55a30297ae 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > @@ -20,6 +20,13 @@ chosen {
> > stdout-path = "serial2:150n8";
> > };
> >
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = < 0 100 0>;
> > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > + default-brightness-level = <128>;
> > + };
> > +
> > clkin_gmac: external-gmac-clock {
> > compatible = "fixed-clock";
> > clock-frequency = <12500>;
> > @@ -69,7 +76,7 @@ diy_led: led-1 {
> >
> > fan: pwm-fan {
> > compatible = "pwm-fan";
> > - cooling-levels = <0 150 200 255>;
> > + cooling-levels = <0 100 150 255>;
> > #cooling-cells = <2>;
> > fan-supply = <_dcin>;
> > pwms = < 0 5 0>;
> > @@ -220,6 +227,16 @@ vdd_log: vdd-log {
> > regulator-max-microvolt = <170>;
> > vin-supply = <_sys>;
> > };
> > +
> > + avdd: avdd {
> > + compatible = "regulator-fixed";
> > + regulator-name = "avdd";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + regulator-min-microvolt = <1100>;
> > + regulator-max-microvolt = <1100>;
> > + vin-supply = <_s0>;
> > + };
> > };
> >
> > _l0 {
> > @@ -428,8 +445,8 @@ regulator-state-mem {
> >
> > vcc3v0_touch: LDO_REG2 {
> > regulator-name = "vcc3v
[BUG] dw-mipi-dsi-rockchip display corruption with dsi panel
Good Evening,
I've been attempting to light off the feiyang fy07024di26a30d panel on
the rockpro64. This is the official panel from the Pine64 store.
I've confirmed it works with the downstream kernel on both the rk3399
and rk3566, but on the mainline driver the display is partially
corrupted (see attached photo: [1]).
As you can see, the left half of the display is fine, but the right half
of the display is corrupted with the pixels smearing horizontally.
I saw when the panel was added, some additional code was added to
handle burst mode in the sun6_mipi_dsi driver [2].
I've seen that the dw-mipi-dsi driver appears to already support burst
mode and I can't find anything out of place there.
I also haven't had much success finding anything obviously different in
the downstream driver vs the upstream driver that would explain this.
Attached below is the in-progress dts changes for an example of how the
panel is plugged in.
I admit, I have little understanding of the mipi-dsi internal workings,
so I'm reaching out to the experts on how to correct this.
Thank you for your time,
Peter Geis
[1] https://photos.app.goo.gl/LBA9M2WcweGaEb4cA
[2]
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20181116163916.29621-1-ja...@amarulasolutions.com/
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index 687a5afa5d2c..af55a30297ae 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -20,6 +20,13 @@ chosen {
stdout-path = "serial2:150n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 100 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <128>;
+ };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <12500>;
@@ -69,7 +76,7 @@ diy_led: led-1 {
fan: pwm-fan {
compatible = "pwm-fan";
- cooling-levels = <0 150 200 255>;
+ cooling-levels = <0 100 150 255>;
#cooling-cells = <2>;
fan-supply = <_dcin>;
pwms = < 0 5 0>;
@@ -220,6 +227,16 @@ vdd_log: vdd-log {
regulator-max-microvolt = <170>;
vin-supply = <_sys>;
};
+
+ avdd: avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "avdd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100>;
+ regulator-max-microvolt = <1100>;
+ vin-supply = <_s0>;
+ };
};
_l0 {
@@ -428,8 +445,8 @@ regulator-state-mem {
vcc3v0_touch: LDO_REG2 {
regulator-name = "vcc3v0_touch";
- regulator-always-on;
- regulator-boot-on;
+// regulator-always-on;
+// regulator-boot-on;
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-state-mem {
@@ -518,8 +535,8 @@ regulator-state-mem {
vcc3v3_s0: SWITCH_REG2 {
regulator-name = "vcc3v3_s0";
- regulator-always-on;
- regulator-boot-on;
+// regulator-always-on;
+// regulator-boot-on;
regulator-state-mem {
regulator-off-in-suspend;
};
@@ -593,6 +610,19 @@ fusb0: typec-portc@22 {
vbus-supply = <_typec>;
status = "okay";
};
+
+ touch: touchscreen@5d {
+ compatible = "goodix,gt911";
+ reg = <0x5d>;
+ AVDD28-supply = <_touch>;
+ VDDIO-supply = <_touch>;
+ interrupt-parent = <>;
+ interrupts = ;
+ irq-gpios = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+// touchscreen-inverted-x;
+// touchscreen-inverted-y;
+ };
};
{
@@ -628,6 +658,88 @@ _domains {
gpio1830-supply = <_3v0>;
};
+_dsi {
+ status = "okay";
+ clock-master;
+
+ ports {
+ mipi_out: port@1 {
+ reg = <1>;
+
+
