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
<mraynal>
geertu: I just applied the renesas nandc series to nand/next and right before pushing it to korg I received Wolfram's renaming suggestion
<geertu>
mraynal: doh. sh*t happens
<mraynal>
geertu: I don't have the history around that IP, could you tell me what you think about his proposal
matthias_bgg has joined #armlinux
<mraynal>
I believe in any case I should create a second compatible, like "renesas,r-car-nand-controller"
<geertu>
mraynal: I've asked wsa to join the discussion here
wsa has joined #armlinux
<wsa>
hiya!
<geertu>
The R-Car Gen3 NANDC seems to be compatible to the RZ/N1 one.
<mraynal>
wsa: ha! I was searching what your pseudo could be :)
<geertu>
RZ/N1 does ONFI2.2, R-Car Gen3 only ONFI1.x
<wsa>
mraynal: :)
<geertu>
RZ/A1 has a different NANDC
<geertu>
RZ/A2 seems to have the same one as R-Car Gen3 again
<geertu>
mraynal: Usually we also don't know the history.
<geertu>
Renesas has different SoC lines, with different sets of peripherals.
<mraynal>
geertu: :)
<geertu>
Sometimes one line takes an IP core from another line. Both may be advanced independently.
<geertu>
Hence things like SCI -> SCIF, and SCIF -> SCIFA -> SCIFB, but also SCIF -> HSCIF
<geertu>
(for the UARTs)
<geertu>
But then the RZ/N people went with DW UART
<wsa>
but all the NANDCs are still close enough to be handled in one driver, so I think a generic name makes sense
<geertu>
Yes
<mraynal>
I suppose we should : pick a generic enough prefix to user everywhere (I'm open to suggestions) + create as many compatibles as we need to be on the safe side
<geertu>
For compatible value, that should become renesas,rcar-gen3-nand-controller or so
<geertu>
+ SoC-specific ones (e.g. renesas,r8a77951-nand-controller) in DT bindings and DTS
<mraynal>
So I propose to name the driver renesas-nand-controller.c so that it is generic no matter what we support inside
<mraynal>
any function/helper/structure could be prefixed with "rnandc_" as suggested by Wolfram
<geertu>
Yeah, and we may need a different one for RZ/A1, if that's ever gonna be supported.
<mraynal>
so we are good fropping the rzn1 compatible in favor of r9xxx ? (you wrote r8 btw)
<mraynal>
s/fropping/dropping/
<geertu>
R-Car Gen3 uses r8a...
<mraynal>
I will define a generic compatible being the rcar-gen3 you propose + at least the r9xxx which matches the SoC that I have in my hands. Then people can add other specific compatibles later if they need to. Agreed?
<geertu>
rzn1 would be the family-specific compatible value, please keep it.
<mraynal>
geertu: so this means using r8xxx + rzn1 in the different compatibles? Isn't that a bit strange?
<geertu>
No, R-Car Gen3 would use r8xxx + rcar-gen3
<geertu>
RZ/N1 would use r9xxx + rzn1
<geertu>
That's how we did it for other modules
<wsa>
geertu: I'd suggest "renesas,r8a77951-rnandc" because it is the name of the IP code and "nand-controller" might be too generic
<geertu>
wsa: RZ/N1 and RZ/A2 do not have the "r-" prefix
<wsa>
we also have "msiof" and friends instead of "spi"
<wsa>
I see
<geertu>
msiof can do much more than spi ;-)
<mraynal>
mmmh, that's gonna be a new yaml challenge
<wsa>
Then I suggest "nandc" because it is shorter :)
<geertu>
mraynal: Np, look at e.g. Documentation/devicetree/bindings/serial/renesas,scif.yaml
sudeepholla has quit [Ping timeout: 268 seconds]
<mraynal>
wsa: well, yes, but for a reason that I cannot explain I tried to enforce the -nand-controller suffix as much as I could (because it is very clear maybe?), but I recently switched from nfc to nandc in the code as geertu suggested because it was too similar to the Near Field Comm system :)
<mraynal>
geertu: thanks
<wsa>
but I also think "renesas,r8a77951-nandc" is better, but I am not strict here
<geertu>
I prefer the short form, too (despite of_device_id.compatible[128] ;-)
<mraynal>
mmmh, ok, I'm feeling outnumbered, I'll see what I can do ;)
<wsa>
lunch time
<wsa>
cya guys!
wsa has quit [Quit: ...]
<geertu>
mraynal: hmm, NAND FLASH is optional on rza2mevb, and not mounted on mine. Perhaps I should sodler one?
<geertu>
solder
<mraynal>
geertu: do you have the hardware for that??
<mraynal>
I don't think it's really necessary has rfs613 and myself already gave this driver a try but...
<geertu>
mraynal: yeah, I do have a soldering iron and hot air.
<geertu>
mraynal: Hmm, if I would mount a NAND chip on rza2mevb, I can no longer use Ethernet, so that's not really an option
<mraynal>
geertu: I wonder what happened in the brain of thoses people who chose to take the Ethernet pins, probably thinking that WiFi would certainly rule the world by that time?
<geertu>
mraynal: Actually there are two Ethernet ports. I lost the first one by enabling the 64 MiB DRAM on the board (8 MiB HyperRAM is a bit small)
<mraynal>
ah, ok :)
<geertu>
But I do agree not all pinmux options are great.
<geertu>
E.g. on R-Car M2-W, there are 4 pins that can be mapped to a normal or to a higher-performance serial port. Makes sense, until you realize the mappings (RXD/TXD/RTS/CTS) are not identical, so you need to rewire to switch ;-(
<mraynal>
haha, nice design
<mraynal>
geertu: how should I name the binding file? renesas-nandc.yaml? renesas,rcar-gen3-nandc.yaml? keep renesas,rzn1-nandc.yaml?
apritzel has joined #armlinux
<geertu>
mraynal: I'd go for renesas-nandc.yaml
<mraynal>
geertu: ack
nsaenz has joined #armlinux
nsaenz_ has quit [Ping timeout: 240 seconds]
leoy has joined #armlinux
prabhakarlad has joined #armlinux
leoy_ has joined #armlinux
leoy has quit [Ping timeout: 256 seconds]
<mraynal>
geertu: where did you find wsa in the first place?
<mraynal>
Now that I've trashed my series at the last moment and addressed all his remarks (hopefully) I'm gonna query a Reviewed-by tag before the holliday break ;-)
leoy_ has quit [Ping timeout: 240 seconds]
<arnd>
mripard_: the sunxi drivers branch looks like it contains only a single bugfix that should better go into 5.16 rather than 5.17
<arnd>
mripard_: can you confirm which branch I should merge it into?
leoy has joined #armlinux
<mripard_>
arnd: it didn't look like it was an urgent fix, but if you prefer to merge it as a fix it's fine by me
<arnd>
mripard_: it seems more valuable than some of the other patches I have in the arm/fixes branch, so I'll add it there as well, thanks for the quick reply
<arnd>
generally my feeling is that more things I get for the merge window should be fixes instead, but a lot of things could go either way
<mripard_>
arnd: ok, I'll keep that in mind in the future then, thanks :)
ardb has joined #armlinux
leoy has quit [Read error: Connection reset by peer]
leoy has joined #armlinux
<arnd>
tagr, shawnguo: I see you have stuff in linux-next that you haven't sent me pull requests for. Just as a reminder, I will only be taking pull requests for a few more days until I'm gone until the merge window, so it would be good if you could send those soon.
<tagr>
arnd: I'm in the middle of preparing pull requests
<arnd>
ok, perfect
<geertu>
mraynal: I was walking to him in another channel, where he had appeared to ask me a question ;)
<geertu>
s/walking/talking/
<mraynal>
geertu: ah, crap
leoy_ has joined #armlinux
leoy has quit [Read error: Connection reset by peer]
leoy_ has quit [Read error: Connection reset by peer]
leoy_ has joined #armlinux
russ has joined #armlinux
shailangsa has quit [Ping timeout: 260 seconds]
<tagr>
arnd: we've got one slight complication this cycle in the Tegra tree where we have a bunch of patches to prepare drivers for runtime PM and power domain support, but then it all needs to be enabled with a single, 4-line patch in the end
<tagr>
arnd: so I was wondering if we could, to keep things a bit simpler, defer the 4-line patch until after v5.17-rc1 because that allows us to avoid a circular dependency in the branches
<arnd>
tagr: how many branches are there that are needed before the final patch, and which trees are they merged through?
<arnd>
I expect we'll already have a 'late' branch this time, so maybe you can have one branch that merges the other ones as dependencies and adds the final bit on top
<arnd>
that way it could already be part of linux-next, but only get sent after the rest has made it into mainline
<tagr>
arnd: there's a drivers branch that will go through the Tegra tree and another part that will need to go through the drm/tegra tree
<tagr>
the drm/tegra part is the tricky one because it will be out of sync with the ARM-SoC tree
<arnd>
tagr: can't you have a stable branch that gets merged through the drm/tegra tree into mainline first, but that I can add as a dependency of the arm/late branch?
<arnd>
it would have multiple merge commits in the final 5.17-rc1, but at least the individual commits should be there only once
<tagr>
arnd: that drm/tegra branch would pull in quite a bit of stuff because the patches in question are fairly high at the top of that tree
<arnd>
tagr: I think that's ok, as long as the other commits are merged into mainline early enough and without any further rebases
<tagr>
but yeah, I could create a tag based on the drm/tegra PR that I sent out and apply the 4-line change on top of that for inclusion in the ARM-SoC late branch
<arnd>
ok, sounds good. We haven't done this kind of dependency much recently, but it used to be quite common in the past. If you run into a case like this again in the future, try to arrange it so that the patches for the other tree are fairly isolated though, e.g. merging a minimum set of dependencies into the drm/tegra tree rather than applying patches on top of unrelated work
<arnd>
(at least it sounds like this is not actually a long chain of interdependent patches in drm/tegra, just patches that are already applied that you rather not rebase)
<tagr>
yeah, I've already sent out a PR for DRM and there's already a bit of work in there which is rather old because for some reason it wasn't pulled last cycle
<tagr>
arnd: that's also the reason why I'm slightly reluctant to send out a tag for this for inclusion in ARM SoC, because if for whatever reason this doesn't end up in DRM, then you'll have all of it in ARM SoC
<tagr>
arnd: by when do you need that tag?
headless has joined #armlinux
<arnd>
tagr: Wednesday would be the last day for me.
<arnd>
I suppose we can always keep the backup plan of applying the single patch later on if it doesn't work out before then
<tagr>
arnd: this would be for the late branch, though, so wouldn't it be enough if this came in sometime during the merge window? by then I may know if the drm/tegra tree has been pulled into DRM for v5.17-rc1
<arnd>
The timing would work out, but I'd prefer to have the final patch in linux-next for as long as possible
<tagr>
okay, it's possible that this goes in before Wednesday and if it does I can send you another PR for that late branch
<arnd>
I suppose if you have a tree that is part of -next, you can also stick it in there, it doesnt have to be in the soc tree for thsi
<arnd>
Ok
<tagr>
drm/tegra feeds into linux-next, so yeah, I could prepare everything in there so we get a bit more coverage
<tagr>
or longer exposure, rather
vigneshr has joined #armlinux
<tagr>
but like you said, if all goes wrong we still have the backup option with the late patch
<tagr>
arnd: all ARM SoC pull requests are now out, I'll let you know how drm/tegra progresses
leoy_ has quit [Ping timeout: 256 seconds]
vigneshr has left #armlinux [#armlinux]
apritzel has quit [Ping timeout: 240 seconds]
shailangsa has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
nsaenz has quit [Read error: Connection reset by peer]