<naoki>
5T schematic is not yet available, this is the reason I don't submit patch for 5T yet
<dsimic>
ah, I remember that E25 patch
<naoki>
it will be available soon
<naoki>
since that E25 patch was rejected, "dynamic rainbow effect with RGB LEDs" is (almost) impossible. it's just static color RGB LED
<dsimic>
I'm not sure about the E25 LED patch, I haven't looked at the E25 to that detail
<dsimic>
if you're quite sure that making a common .dtsi for the 5B, 5B+ and 5T is possible, perhaps it would be best to send a note to your latest patch series that they should be ignored until further notice
<dsimic>
though, having the same .dtsi shared between two seemingly disparate board series might raise some eyebrows :)
<dsimic>
however, if they're really that similar, perhaps it should be fine
<dsimic>
it's hard to tell without going into the nitty-gritty details :)
<naoki>
hehe
<dsimic>
also, I was quite surprised to see that the 4.039 V regulator was missing in the ROCK 5B board dts
<dsimic>
all that really needs fixing
warpme_ has joined #linux-rockchip
<dsimic>
I'm willing to review the 5B/5B+ dts(i) changes in detail, which will take a lot of time and effort, but please let me know if your final goal is to actually have a common dtsi for 5B, 5B+ and 5T, so I don't waste my time and effort :)
<dsimic>
actually, how about this as the plan...
<dsimic>
(1) let's put your latest two patch series on hold
<dsimic>
(2) let's wait for the 5T schematic to become publicly available
<dsimic>
(3) I'll have a look at the 5T schematic, to provide my opinion on the feasibility for the threeway-shared common dtsi
<dsimic>
(4) we'll then proceed accordingly
<naoki>
I'll do (1) soon
<dsimic>
please, let me know does that sound good to you?
<naoki>
I think I can submit shared dtsi for B and B+ at first, then submit 5T which use shared dtsi when it's ready
<dsimic>
hmm, but why do (1) then?
<dsimic>
I mean, that's also an option
<naoki>
btw I don't have B+ yet, it will be arrived soon. so I can do for 3 boards at once
<naoki>
well
<dsimic>
hmm, you should wait until you've got a 5B+ available for testing
<naoki>
this is the reason I don't submit 5B+ patch today ;)
warpme_ has quit [Ping timeout: 255 seconds]
<dsimic>
alright :)
<dsimic>
just checking, so these two series remain unaffected?
<naoki>
ah, it's WIP state, there are some missing pieces
<naoki>
btw
<naoki>
I still do not understand how to use Type-C port :(
<dsimic>
I'd rather wait until the 5T schematic is publicly available
warpme_ has quit [Ping timeout: 272 seconds]
<dsimic>
BTW, where does "T" in "5T" come from?
<dsimic>
is it turbocharged? :D
<naoki>
Terminator ;)
<dsimic>
:D
<naoki>
I'm thinking to add fusb302 and type-c role switch things to 5B, but it doesn't work well on 5B+/5T, I'm wondering if I should do it
<naoki>
add xhci "host" patch for 5B is not so smart
<dsimic>
well, nothing that doesn't work well should find its way into the dts(i) files
<dsimic>
that's the general rule
<naoki>
I'm thinking to drop non-working type-c things from 5B+/5T as a first patch
System_Error has quit [Remote host closed the connection]
<dsimic>
sorry, I don't get it?
<naoki>
well
<naoki>
current my WIP patches
<naoki>
there is non-working(or just I don't know how to use) type-c things in 5B+/5T dts
<naoki>
if it works, I'll add it to 5B
<dsimic>
would that come from the shared .dtsi file?
<naoki>
if it doesn't work, I'll drop it from 5B+/5T
<naoki>
if it works, it will be in shared .dtsi (and different GPIO pin definitions will be in board specific .dts)
<dsimic>
hmm, I see...
<naoki>
do you have 5-ITX?
<naoki>
type-c things are in 5-itx.dts
<dsimic>
perhaps it can go into the 5B board .dts first, if it doesn't work on the 5B+ and 5T, and can be moved later to the shared .dtsi when the issues are resolved
<naoki>
II imitated that
hexdump0815 has quit [Ping timeout: 255 seconds]
<dsimic>
I'd go into the details (the 5B schematic, etc.) while reviewing your future patches... I think that's the best approach
hexdump0815 has joined #linux-rockchip
warpme_ has joined #linux-rockchip
<dsimic>
(regarding the USB-C stuff)
<naoki>
$ grep -l fusb302 rk3588*[si]
<naoki>
rk3588-evb1-v10.dts
<naoki>
rk3588-friendlyelec-cm3588-nas.dts
<naoki>
rk3588-nanopc-t6.dtsi
<naoki>
rk3588-rock-5-itx.dts
<naoki>
rk3588-rock-5b-plus.dts
<naoki>
rk3588-rock-5t.dts
<naoki>
rk3588s-evb1-v10.dts
<naoki>
rk3588s-indiedroid-nova.dts
<naoki>
rk3588s-odroid-m2.dts
<naoki>
rk3588s-orangepi-5.dtsi
System_Error has joined #linux-rockchip
<naoki>
it seems there are some other boards which have type-c things
<dsimic>
yeah, it's used on quite a few boards, and not just RK3588-based boards :)
<naoki>
sure
<dsimic>
I might also compare it to the USB-C setup on the QuartzPro64, which megi talked about upstreaming
<dsimic>
if he doesn't do that in the next few weeks, I'll do that, so having USB-C layout compared and tested on a few boards at once should only be helpful with identifying any possible issues
<dsimic>
s/USB-C layout/the USB-C layouts/
<dsimic>
and should be a bit more efficient that way :)
warpme_ has quit [Ping timeout: 245 seconds]
<naoki>
btw can anyone test/review ROCK 5A/5C patch?
<dsimic>
I could review it at some point :)
warpme_ has joined #linux-rockchip
<dsimic>
but I need to review some other patches first, including some U-Boot patches
warpme_ has quit [Ping timeout: 246 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
ungeskriptet_ has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 252 seconds]
ungeskriptet_ is now known as ungeskriptet
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 272 seconds]
<naoki>
typec_fusb302 6-0022: error -EINVAL: cannot register tcpm port
<naoki>
hmm...?
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
ldevulder has joined #linux-rockchip
warpme has joined #linux-rockchip
franoosh has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 272 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 265 seconds]
suniel has joined #linux-rockchip
raster has joined #linux-rockchip
<suniel>
Hi all, please suggest device tree for the following configuration:
<suniel>
i have a UART controller(UART7) with two channels/pin-mux configuration:
<suniel>
one pinmux is taking care of RS485 and the other pinmux is
<suniel>
exposed on GPIO as GND, TX and RX.
<suniel>
I need to create two device files /dev/tty* for both
<suniel>
is this device tree configuration correct ?
<suniel>
&uart7 {
<suniel>
status = "okay";
<suniel>
uart7_gpio {
<suniel>
pinctrl-names = "default";
<suniel>
pinctrl-0 = <&uart7m1_xfer>;
<suniel>
};
<suniel>
uart7_rs485 {
<suniel>
pinctrl-names = "default";
<suniel>
pinctrl-0 = <&uart7m2_xfer>;
<suniel>
};
<suniel>
};
<suniel>
please suggest where am i wrong, thank you
<mmind00>
suniel: you will likely need a devicetree overlay for that ... i.e. you can't really configure to competely different modes for the one uart controller
<suniel>
mmind00 thank you for the reply. generally can i use two channels at the same time like one UART controller configured for both rs485 and let say another peripheral with a UART interface
<suniel>
the SOC i am using is a rk3588
mripard has joined #linux-rockchip
<mmind00>
suniel: not sure what you're asking ... one specific set of pins can only be configured for one pinmux at a time
<suniel>
in rk3588, i have two pinmuxes for UART7:
<suniel>
uart7 {
<suniel>
/omit-if-no-ref/
<suniel>
uart7m1_xfer: uart7m1-xfer {
<suniel>
rockchip,pins =
<suniel>
/* uart7_rx_m1 */
<suniel>
<3 RK_PC1 10 &pcfg_pull_up>,
<suniel>
/* uart7_tx_m1 */
<suniel>
<3 RK_PC0 10 &pcfg_pull_up>;
<suniel>
};
<suniel>
/omit-if-no-ref/
<suniel>
uart7m2_xfer: uart7m2-xfer {
<suniel>
rockchip,pins =
<suniel>
/* uart7_rx_m2 */
<suniel>
<1 RK_PB4 10 &pcfg_pull_up>,
<suniel>
/* uart7_tx_m2 */
<suniel>
<1 RK_PB5 10 &pcfg_pull_up>;
<suniel>
};
<suniel>
};
<mmind00>
suniel: yes and you can only ever activate one of them at the same time
<suniel>
okay got it, only one at a time. Thank you
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 255 seconds]
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
UndrWater has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
UndrWater has joined #linux-rockchip
mps_ has joined #linux-rockchip
mps has quit [Ping timeout: 255 seconds]
warpme_ has joined #linux-rockchip
<sre>
naoki: That patch is incomplete from kernel POV. I have a pending patch for the whole USB-C connector description for the kernel. It was waiting for the U-Boot part to be solved :)
<naoki>
sre: about kernel part, I could not make role/orientation things work. so I just define pdo thins part as like as -u-boot.dts