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
apritzel has quit [Ping timeout: 268 seconds]
shailangsa has quit [Ping timeout: 265 seconds]
mixfix41 has quit [Ping timeout: 240 seconds]
Nact has quit [Quit: Konversation terminated!]
Shailangsa_ has joined #armlinux
matthias_bgg has joined #armlinux
amitk has joined #armlinux
monstr has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
frieder has joined #armlinux
apritzel has joined #armlinux
guillaume_g has joined #armlinux
<geertu>
ukleinek: (about Sony) Yes I did
sszy has joined #armlinux
CrashTestDummy2 has joined #armlinux
wwilly has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 252 seconds]
<ukleinek>
marex: did you find your clk-hog? I think assigned-clocks and get_exclusive could do your trick.
<marex>
ukleinek: I know how to implement it, I just dont know whether there might already be something like that
<geertu>
marex: AFAIK there is nothing in DT for enabling clocks (intentionally), but there is ".flags = CLK_IS_CRITICAL" in driver code.
<geertu>
(clock driver)
<marex>
geertu: intentionally ? I can see how there is a usecase for enabling clock output of a SoC
<geertu>
marex: what's the consumer of the clock?
<marex>
geertu: CPLD
<geertu>
marex: So the CPLD needs a Linux driver that enables the clock?
<marex>
geertu: the CPLD does not have any other connection with the SoC, for the CPLD the SoC is just a more expensive xtal
<geertu>
Could be a simple "clk-hog" driver, that lists the compatible value of the CPLD in its match table, like we do for spidev
Pali has joined #armlinux
<geertu>
marex: I can argue the same about LEDs (the LED has no other connection with the SoC ;-)
<geertu>
What else is connected to the CPLD?
wwilly_ has joined #armlinux
wwilly has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 255 seconds]
<marex>
geertu: presumably the argument in your case would be "I need an always-on LED => I use GPIO hog"
<marex>
geertu: so, regarding clk-hog, that;s what this discussion was about ;-)
<geertu>
marex: while it's more flexible to describe the hardware in DT using gpio-leds in DT, and having a software policy using ledtrig-default-on
<geertu>
marex: yes, I did read the backlog
<geertu>
marex: so you add the CPLD to DT with compatible "<vendor>,<board>-cpld", and add that to a new clk-hog.c driver
<geertu>
makes sense?
apritzel has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
<marex>
geertu: except for this clock-always-on case, there is no software policy, the clock are just always on
<marex>
geertu: I dont think you want to track a list of compatibles like spidev does, that would be unmanageable
<marex>
geertu: I think you rather want something like gpio-hog, where you specify that a certain clock should be kept active
<marex>
possibly under the clock controller, like you have gpio-hog for gpio controllers
apritzel has quit [Ping timeout: 255 seconds]
apritzel has joined #armlinux
<geertu>
marex: I'm afraid that will lead to people adding lots of clock there, because they don't understand their clock topology, and have incomplete descriptions for other devices. That's BTW the reason behind "intentionally" above.
Pali has quit [Ping timeout: 268 seconds]
<mripard_>
marex: if that clock is just always on, then just model it as a fixed clock?
<mripard_>
I'm not sure what the critical flag is going to change here if it can't be disabled
<geertu>
mripard_: The SoC provides the clock
<marex>
geertu: I could argue the same applies to gpio-hog though
<geertu>
marex: Do yiu have an example of a gpio-hogs that is not controlling a mux on a dev board? ;-)
<marex>
geertu: I think there are a few
djrscally has joined #armlinux
<marex>
geertu: at least one board I know of uses split rs485 input/output control, so the input has to be hogged for example
Shailangsa_ has quit []
<geertu>
marex: Care to elaborate, or point me to the DTS?
CrashTestDummy2 has joined #armlinux
<marex>
geertu: arch/arm/boot/dts/vf610-zii-dev-rev-c.dts not the one I was looking for, but that looks like some strap config (i.e. not a mux)
<marex>
geertu: arch/arm/boot/dts/imx51-zii-rdu1.dts another not-a-mux
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
<geertu>
marex: vf610-zii-dev-rev-c.dts looks like a case where a GPIO defaults to output (or is programmed that way by the bootloader), and it is used as an interrupt. IIRC we have a similar issue on an RZ/G board.
<geertu>
request_irq() does not switch a GPIO to input mode :-(
<geertu>
marex: vf610-zii-dev-rev-c.dts looks like a workaround for a board design bug (or fature ;-)
<marex>
geertu: you can proceed with git grep and find many more examples :)
shailangsa has joined #armlinux
<abelloni>
geertu: if it is used as an interrupt, why don't you have a proper pinctrl entry for it in the node using that interrupt ?
tscherer has joined #armlinux
<geertu>
abelloni: The issue is not pinctrl, but GPIO. request_irq() does call pinctrl_gpio_request() through the GPIO driver's gpio_chip.request() callback.
<geertu>
But nothing configures the GPIO as input.
kristo has quit [Ping timeout: 255 seconds]
pg12 has quit [Ping timeout: 240 seconds]
kristo has joined #armlinux
wwilly_ has quit [Ping timeout: 246 seconds]
wwilly has joined #armlinux
wwilly_ has joined #armlinux
wwilly has quit [Ping timeout: 255 seconds]
pg12 has joined #armlinux
Nact has joined #armlinux
<mripard_>
geertu: but the gpio driver can definitely do that if it makes sense?