ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
<ukleinek>
lag: is your request to get the mfd and backlight bits of my i2c-probe-new series still open? Or are you happy with the b4 cmdline I sent you?
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
<lag>
ukleinek: I plan to attempt the b4 solution
<ukleinek>
lag: did you see my question from yesterday?
viorel_suman has joined #armlinux
<lag>
ukleinek: No, I haven't been through my upstream mail today
matthias_bgg has joined #armlinux
<lag>
ukleinek: Oh, in here - yes, I do 10's of builds before pushing
<lag>
ukleinek: I'll take a look at that now
cleger has quit [Remote host closed the connection]
cleger has joined #armlinux
headless has joined #armlinux
apritzel has joined #armlinux
scosu has quit [Ping timeout: 260 seconds]
prabhakarlad8 has quit [Ping timeout: 260 seconds]
<lag>
ukleinek: Pushed, should be present in tomorrow's -next
prabhakarlad has joined #armlinux
headless has quit [Quit: Konversation terminated!]
snalty has quit [Ping timeout: 248 seconds]
wens has quit [Read error: Connection reset by peer]
wens has joined #armlinux
punit has joined #armlinux
amitk__ has joined #armlinux
snalty has joined #armlinux
amitk_ has quit [Ping timeout: 268 seconds]
frieder has joined #armlinux
frieder has quit [Remote host closed the connection]
cleger has quit [Quit: Leaving]
cleger has joined #armlinux
jclsn has joined #armlinux
cleger has quit [Remote host closed the connection]
cleger has joined #armlinux
<jclsn>
Can someone here help me modify my device tree for a display bridge driver? I read and watched a few guides and tutorials on device trees, but I am still lost
<jn>
hi :)
<jclsn>
Oh you again
<jn>
yep
<jclsn>
hey :)
<jn>
maybe someone here can help, when you provide the details
<jn>
i.e. link to the DT, description of what's wrong
<jclsn>
Our old driver used and lvds_bridge endpoint with the display timings
<jn>
what do you know about your panel (the piece of hardware)?
<jclsn>
I have tried using that endpoint, but it doesn't work
<jclsn>
It is a custom board
<jclsn>
custom panel I mean
<jclsn>
I was hoping that the simple-panel with the right timings would be sufficient
<jn>
the panel-simple binding doesn't allow specifying timings in DT, AFAICS it needs to happen in the C driver
<jclsn>
Ah okay
<jn>
drivers/gpu/drm/panel/panel-simple.c
<jclsn>
Yeah I have looked at it, but was hoping that I don't need to touch it
<jclsn>
or I thought that is what device trees are for in the first place
<jclsn>
not having to hard-code device-specific characteristics
<jn>
the boundary between DT and driver isn't always picked in the same way, and in this case the mainline developers decided to only port identification-by-name of the panels in the DT, and let the panel details live in the driver
<jn>
i think it was historically done differently in some downstream kernels
<jclsn>
Okay, so will try to define the timings there
<jclsn>
Guess I will need a panel description as well
<jn>
i hope you have a manufacturer name and part number of the panel, in order to pick good names in the code
<jclsn>
I have the data sheet here
<jn>
good
amitk__ has quit [Ping timeout: 260 seconds]
<jclsn>
I will try to study the panel driver tomorrow, add the required structs and will get back to you tomorrow if that is okay
<jn>
alright, glad to help
<jclsn>
Thanks
<jclsn>
But one thing
<jclsn>
I am not really sure if the simple panel is actually needed ^^
<marex>
ukleinek: could the error be somewhere in the schema itself ?
<marex>
like in one of the property descriptions ?
<marex>
is that from dt_bindings_check ?
derjanni has joined #armlinux
derjanni_ has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #armlinux
<jclsn>
ukleinek: I also want to understand this and not just c&p
<jclsn>
marex: Okay thanks. I will try that
<marex>
jclsn: if you have the mx8mm evk , you might want to assemble your setup on that and use mainline linux
<marex>
or use mainline linux on your machine and test the setup that way
<marex>
backporting stuff to the nxp downstream horrorshow ... and then fighting with their completely custom downstream pipeline ... is best avoided
<ukleinek>
marex: yes, it's dt_bindings_check that emits that warning
<marex>
ukleinek: and I assume those are bindings you're currently writing ?
<ukleinek>
marex: yes
<jclsn>
marex: We already had that conversation. I would go mainline, but it is not wanted. Also my last two weeks in this company, so I really don't bother anymore ;)
<ukleinek>
good idea to leave a company that wants to stick to vendor kernels
<ukleinek>
still more with i.MX8M* which has (compared to its age) good mainline support
<jclsn>
ukleinek: xDd
<marex>
ukleinek: +1
<marex>
ukleinek: wouldn't it make sense to keep removing parts of the bindings until you stop getting the error ?
<marex>
ukleinek: then you would know where it comes from
<jclsn>
We also did test the Vivante acceleration impact. It was close to none
<jclsn>
Still they don't go mainline until some expensive consulting guy tells them to
<jclsn>
Never listen to your employees
<jclsn>
Ah well nevermind. I don't care anymore ^^
<jclsn>
Let us see what happens next year
<marex>
next year is the year of Linux on embedded, everyone will use stock mainline with no patches (maybe)
<geertu>
marex: printing T-shirts?
<jclsn>
marex: Yeah of the rabbit actually
<jclsn>
s/yeah/year/
<marex>
so plan9 ?
<jclsn>
Speaking of the Chinese, I wonder if the rk3588 will be attractive to companies once its mainlined. No idea if it is actually an industrial-grade board, but its specs are surely impressive
macromorgan has joined #armlinux
<jclsn>
Ah took me a while to get the Plan9 joke
<jclsn>
Google is your friend
<jclsn>
Maybe ^^
<jclsn>
Unfortunately, there is no year of the penguin