freemangordon has quit [Ping timeout: 480 seconds]
<LordKalma>
I do have a question still...
<LordKalma>
The DTB the community decompiled says this like: `power-supply = <0x1b>; reset-gpios = <0x45 0x00 0x0b 0x01>;`. But the struct I made says `struct st7701s {/*...*/ struct gpio_desc *reset; struct regulator *supply;};` and the `_probe` function says: `/*...*/ ctx->supply = devm_regulator_get(dev, "power"); /*...*/ ctx->reset = devm_gpiod_get(dev,
<LordKalma>
"reset", GPIOD_OUT_LOW);`. What I don't get is where exactly the names in the DTB come into play, and whether I should change anything. The names in the `_probe` function are taken directly from the decompilation... Only the `struct st7701s` I "invented"...
<szemzoa>
regarding to T113, if it's more or less the same as D1s or D1, is it possible that I can use the reverse engineered mctl_hal.c from sun20i_d1_spl? In theory, becouse so far I was not able to init the DDR with the working xfel's DDR_params... :)
<DuClare>
LordKalma: Names seem fine but I don't fully understand what you're asking
<DuClare>
Names come into play when looking up nodes in the DT
<DuClare>
Apart from that, it's just about sticking to conventions
<DuClare>
reset-gpios and power-supply definitely seem conventional
<LordKalma>
ah, I thought the DTB somehow said to the code what has like the actual pin location
apritzel has joined #linux-sunxi
<LordKalma>
and I needed to ask it for the right name
<DuClare>
I mean <0x45 0x00 0x0b 0x01> should refer to an actual pin group in some gpio controller
<LordKalma>
but it's not up to my code to ask for that information directly
<LordKalma>
is that it?
<DuClare>
devm_gpiod_get finds the right pin for you based on what the dt contains
<LordKalma>
well, that's what leads to my question
<LordKalma>
one asks for "reset" and the other is called "reset-gpios"
<LordKalma>
is that a problem?
<DuClare>
Not a problem, there are hardcoded suffixes like -gpios or -supply
<apritzel>
LordKalma: this is the point where you are happy that you based your driver on an existing one ;-)
<DuClare>
E.g. of_get_regulator() will look for "%s-supply", filling in the name you passed to devm_regulator_get()
<LordKalma>
thank you!
<LordKalma>
that makes me much more confident this will work
<LordKalma>
tangential question, what does array syntax means in the DTB: <0x45 0x00 0x0b 0x01>
<LordKalma>
versys just a single number?
<DuClare>
It's node specific but in this case it'd contain the phandle of the gpio controller, pin number, and flags
<LordKalma>
apritzel, well, `_probe` in particular was what I most scared of, but it turned out to only take an hour to write because it was literally copy paste from other drivers
<LordKalma>
replcing with my names
<DuClare>
In source form it could look something like <&gpio2 11 GPIO_ACTIVE_LOW>
<LordKalma>
ah okay, thanks
<LordKalma>
again, I can't thank you enough for all you've explained to me
<LordKalma>
but yeah, _probe was quickly to write, much faster than _get_modes
<LordKalma>
*quick to*
<LordKalma>
because it was 90% copy->paste->rename
apritzel has quit [Ping timeout: 480 seconds]
pmp-p has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
ftg has joined #linux-sunxi
freemangordon has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
indy has quit []
indy has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
indy_ has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
indy_ is now known as indy
<LordKalma>
you here probably know more than anyone else
<LordKalma>
whats the legal grounds on what I just did?
<LordKalma>
is it upstreamable?
rajkosto has quit [Read error: Connection reset by peer]
<apritzel>
since the original code must have been under the GPL, I don't see any issues
<apritzel>
normally the approach is to copy an existing (GPLed) driver, then just fill in the details (like the display timings or pins) from the reverse engineering efforts
<LordKalma>
should I chnge the attribution macros to the original copyright owner?
<LordKalma>
I left both names in the header in the comment, other files seem to do the same
indy_ is now known as indy
apritzel_ has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
apritzel_ has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
evgeny_boger1 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
<apritzel>
LordKalma: I would make just you the module author, though
<apritzel>
since that is the person of contact and the responsible person for any inquiries
<apritzel>
You could put something like: "based on a reverse engineered driver by Jet Yee" in the header
pmp-p has joined #linux-sunxi
<cyrozap>
LordKalma: If you just took uncopyrightable facts from the RE'd driver (e.g., display timings, register configuration sequences), then you should not be providing attribution to the original driver author as you didn't use any copyrighted information from that driver. This is important because if you _did_ use copyrighted information, you wouldn't have the legal right to include that information in
<cyrozap>
your driver. Even though the RE'd driver should have been released under the GPL, if it wasn't properly done so (i.e., if it wasn't written somewhere that the code in that specific module was GPL) its license needs to be considered "all rights reserved". Just because the GPL requires someone to release a derivative work under the GPL, doesn't automatically mean that any derivative work they publish
<cyrozap>
is GPL.
<apritzel>
cyrozap: IIUC, they used the Linux MODULE_LICENSE macro in their driver, so that GPLv2 string actually ended up in the binary
<apritzel>
cyrozap: check that .png file LordKalma linked above
<apritzel>
but I agree that it would be much cleaner to just take the hardware details bit, and write the driver from scratch/copy an existing GPLed one
<cyrozap>
LordKalma: Kernel maintainers take copyright very seriously because _lawyers_ take it seriously--if your code looks like it might be infringing (e.g., by having a big statement saying "based on reverse engineering a driver"), there's a really good chance it won't be accepted upstream due to the legal risk.
<cyrozap>
*statement in the file
<LordKalma>
well, the driver is basically the same as the other 50 SPI display panel drivers
<LordKalma>
they all look the same
<LordKalma>
I need mostly to reverse engineer SPI frequency and resolution
<apritzel>
LordKalma: yes, but you didn't do it this way, did you?
<LordKalma>
no, I looked at the decompiled code indeed
<LordKalma>
so yeah, idk
<apritzel>
LordKalma: you could start over, though:
<LordKalma>
cannot be unseen haha
<apritzel>
delete that file, and copy one of the other 50
<apritzel>
then fill in the blanks either from memory
<apritzel>
or just by looking at those screenshots you found in this IRC channel's logs ;-)
<cyrozap>
apritzel: The MODULE_LICENSE thing *might* count, but it's still kinda sketchy.
<apritzel>
cyrozap: sure, but I think copyright doesn't count here, since the whole kernel is under the GPL, and he didn't copy from an actual source file with a differing license
<apritzel>
LordKalma: have you tried contacting Jet Yee directly?
<cyrozap>
LordKalma: If you send a sketchy patch to the mailing list, and aren't able to truthfully say you just copied one of the other SPI panel drivers and filled in the blanks with the numbers from the driver binary, there's a good chance the kernel maintainers will reject the patch and treat future patches from you with greater scrutiny. Please be sure to have your legal ducks in a row before submitting a
<LordKalma>
only the company
<cyrozap>
patch--don't just YOLO it to the mailing list.
<LordKalma>
yeah, I won't
<LordKalma>
not of that kind of official record
<apritzel>
LordKalma: is there is anyone else in the community who could do that exercise?
<LordKalma>
maybe
<apritzel>
I mean copy a SPI driver and fill in the blank, with numbers that you tell him/her?
<apritzel>
that would mimic clean room reverse engineering
<LordKalma>
btw, first testing with the driver
<LordKalma>
the screen looks yellowish and "low res"
<cyrozap>
apritzel: If the maintainers would accept "based on a decompiled (but GPL-licensed) driver", then it _might_ be okay, since the GPL doesn't restrict decompiling or reverse engineering.
<LordKalma>
they did write GPLv2, they just didn't send me the source code hahaha
<cyrozap>
apritzel: (that was a reply to the "he didn't copy from an actual source file with a differing license" message)
<LordKalma>
that's why it *might* be a "derivative work"
<apritzel>
LordKalma: try reading "Sign your work - the Developer's Certificate of Origin" in Documentation/process/submitting-patches.rst
<apritzel>
jernej: thanks, it's WIP anyway, if you just look at that DT binding change, and see if that makes sense to you
<LordKalma>
will try thanks
<jernej>
apritzel: that I can do :)
<jernej>
LordKalma: btw, 0xdc0 means GFP_KERNEL | __GFP_ZERO
<jernej>
but zero flag is actually automatically added if you use devm_kzalloc() variant
machinehum has joined #linux-sunxi
<LordKalma>
jernej, yes, I realized I was the only one using kmalloc, changed to kzalloc which was what everybody was doing and noticed the `GFP_KERNEL | __GFP_ZERO` as well
<jernej>
apritzel: looks ok at first glance, just a couple of notes
<jernej>
1. actual PHY code can be considerably shortened using various helpers - see submitted PHY code
<apritzel>
jernej: yes, I skipped over that for now ;-)
<apritzel>
actually I wonder if we really need that at all
<jernej>
2. I'm not too happy with having phy-address property in EPHY controller note
<jernej>
it's actually determined with reg property in PHY node
<jernej>
and having same value in two places begs for troubles
<jernej>
apritzel: PHY code is not needed, I use simple hack for enabling EPHY in U-Boot and Linux treats it as generic PHY and it works just fine
<jernej>
that however doesn't mean there could not be any issue
<jernej>
but initial submission can be without it
<jernej>
apritzel: one more thing, does EPHY controller really need "syscon" compatibility? I would skip that...
<apritzel>
no, it doesn't, and I was indeed planning on removing that
<apritzel>
I see where you are coming from with the PHY address, but I think we need a separate property:
<apritzel>
a) for supporting more than one AC200 (which is admittedly somewhat theoretical)
<apritzel>
b) because this mirrors the typical PHY hardware address configuration (the tie-ups or tie-downs of the pins)
<jernej>
I guess Rob or net maintainers can decide that
<jernej>
anyway, good enough for RFCv2 :)
<jernej>
apritzel: btw, I didn't mean to hardcode PHY, just somehow inspect PHY node for reg value
<apritzel>
but how do you refer to the right PHY node? at the moment there is no link in that direction
evgeny_boger has joined #linux-sunxi
<apritzel>
my thinking was that the EPHY ctl DT node mimics the hardware configuration that you typically have on an external PHY (like a Realtek):
<apritzel>
there you set the PHY address through some pins, you specify the *MII interface through the actual traces you connect, you specify LED polarity by wiring the LEDs accordingly, etc
<apritzel>
especially for the PHY address I think there is good rationale to keep that separate: in the PHY DT node you specify what the MAC is using, in the PHY ctl node you say which address the PHY is listening to
evgeny_boger1 has joined #linux-sunxi
<apritzel>
and having those separate also links those two together
<apritzel>
but I could also be convinced to provide a "phy" link from the ctl node to the PHY used, and grab the PHY address through a phandle lookup
<apritzel>
as you said, could be subject to an ML discussion
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger1 has quit [Ping timeout: 480 seconds]
<jernej>
I'm fine with that too in general
<jernej>
apritzel: you don't have to wait on me, if you have time, you can post it, just to start discussion
<jernej>
btw, I don't have e-mail with siol.net anymore, please change to gmail
<jernej>
and I think you can skip my authorship on some parts, like ephy controller driver
<apritzel>
right, will do, I just grabbed those patches from the LE repo, and then mixed them up badly with your RFC post
<apritzel>
I think one of them has an IRQ part, and the other is more modern
<jernej>
oh yeah, I forgot about IRQ already
<jernej>
I wasn't sure how to properly model it
<apritzel>
btw: I added this Eachlink H6 Mini DT, because that's my test machine, and used the tanix.dtsi, because they are very similiar (just different WiFi and one less USB), do you think that's feasible for upstream?
<jernej>
yeah, I saw that
<jernej>
it would be better to rename tanix.dtsi to generic-stb.dtsi or something like that IMO
<jernej>
I think something similar is done for tablets for older SoCs
<apritzel>
right, was wondering about that
<apritzel>
thanks, will try that, and will see what people say
<jernej>
apritzel: btw, wasn't there some DRAM issue on eachlink mini?
<jernej>
I mean with the driver
<apritzel>
I think that went away with lowering the DRAM freq, at least I haven't seen any issue anymore
<apritzel>
(or something else improved in the driver?)
<apritzel>
I have 660 MHz now, that's even a notch higher than the Tanix
<apritzel>
need to do some stability tests, though
<jernej>
I did some changes to the driver, but I believe reports come back that still doesn't work
<jernej>
maybe it's lower frequency or combination of both
<jernej>
anyway, I'm glad it went away
<apritzel>
reports for the Eachlink? Or in general?
<jernej>
for eachlink
<jernej>
uh, what about HDMI plug detection? that also didn't work, right?
<apritzel>
yes, I think we figured that's broken, in hardware
<apritzel>
you need to specify your resolution on the command line :-(
<jernej>
how did you determined that it's HW?
<jernej>
IIRC it also works that you force plug detection to always connected
apritzel has quit [Ping timeout: 480 seconds]
__ad has joined #linux-sunxi
PPAChao has joined #linux-sunxi
LordKalma1 has joined #linux-sunxi
milek7_ has joined #linux-sunxi
Nemo_bis_ has joined #linux-sunxi
Serge_ has joined #linux-sunxi
LordKalma has quit [reticulum.oftc.net helix.oftc.net]
bauen1 has quit [reticulum.oftc.net helix.oftc.net]
hallyn has quit [reticulum.oftc.net helix.oftc.net]
Hypfer has quit [reticulum.oftc.net helix.oftc.net]
Nemo_bis has quit [reticulum.oftc.net helix.oftc.net]
ats_ has joined #linux-sunxi
ad__ has quit [reticulum.oftc.net helix.oftc.net]
ynezz has quit [reticulum.oftc.net helix.oftc.net]
insep has quit [reticulum.oftc.net helix.oftc.net]
dittid[m] has quit [reticulum.oftc.net helix.oftc.net]
oliv3r[m][m] has quit [reticulum.oftc.net helix.oftc.net]
sajattack[m] has quit [reticulum.oftc.net helix.oftc.net]
Newbyte has quit [reticulum.oftc.net helix.oftc.net]
PPA has quit [reticulum.oftc.net helix.oftc.net]
igraltist has quit [reticulum.oftc.net helix.oftc.net]
milek7 has quit [reticulum.oftc.net helix.oftc.net]
ats has quit [reticulum.oftc.net helix.oftc.net]
cyrozap has quit [reticulum.oftc.net helix.oftc.net]
Hypfer has joined #linux-sunxi
insep has joined #linux-sunxi
sajattack[m] has joined #linux-sunxi
cyrozap has joined #linux-sunxi
bauen1 has joined #linux-sunxi
igraltist has joined #linux-sunxi
ynezz has joined #linux-sunxi
ynezz is now known as Guest1490
hlauer has joined #linux-sunxi
Guest1490 is now known as ynezz
apritzel_ has joined #linux-sunxi
JohnDoe_71Rus has quit []
oliv3r[m][m] has joined #linux-sunxi
dittid[m] has joined #linux-sunxi
ftg has joined #linux-sunxi
Skallwar has joined #linux-sunxi
SkallwarEstebanBlanc[m] has joined #linux-sunxi
Skallwar has quit [Remote host closed the connection]
Newbyte has joined #linux-sunxi
indy has quit [Ping timeout: 480 seconds]
rajkosto has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
indy has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
Daanct12 has quit [Remote host closed the connection]