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
djrscally has quit [Ping timeout: 256 seconds]
nsaenz_ has joined #armlinux
Pali has quit [Ping timeout: 256 seconds]
nsaenz has quit [Ping timeout: 252 seconds]
Nact has joined #armlinux
robclark has quit [Ping timeout: 260 seconds]
robclark has joined #armlinux
mrlemke has joined #armlinux
Nact has quit [Quit: Konversation terminated!]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #armlinux
_jannau_ has quit [Ping timeout: 245 seconds]
ardb has joined #armlinux
_jannau_ has joined #armlinux
ravan has quit [Ping timeout: 256 seconds]
apritzel has joined #armlinux
iivanov has joined #armlinux
apritzel has quit [Ping timeout: 240 seconds]
djrscally has joined #armlinux
guillaume_g has joined #armlinux
ardb has quit [Quit: Leaving.]
sszy has joined #armlinux
Pali has joined #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]
nsaenz_ has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
russ has quit [Remote host closed the connection]
russ has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
Tokamak has quit [Quit: Textual IRC Client: www.textualapp.com]
apritzel has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Tokamak has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jlinton has quit [Quit: Client closed]
<shawnguo> arnd: yes, I will send PRs out today, thanks for the reminding!
ardb has quit [Quit: Leaving.]
ardb has joined #armlinux