narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki - ml - Publicly Logged on
return0e has quit [Remote host closed the connection]
return0e has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #linux-amlogic
Barada has joined #linux-amlogic
vagrantc has joined #linux-amlogic
<The_Coolest> Hey guys, stupid question: How does one enable pullups on GPIO pins?
Barada has quit [Ping timeout: 260 seconds]
Barada1 has joined #linux-amlogic
Barada1 is now known as Barada
lissyx has joined #linux-amlogic
ldevulder has joined #linux-amlogic
<edcragg> The_Coolest: device tree?
nemunaire has quit [Ping timeout: 256 seconds]
nemunaire has joined #linux-amlogic
nemunaire has quit [Quit: quit]
vagrantc has quit [Quit: leaving]
nemunaire has joined #linux-amlogic
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-amlogic
Barada has quit [Quit: Barada]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-amlogic
afaerber has quit [Ping timeout: 268 seconds]
afaerber has joined #linux-amlogic
<The_Coolest> edcragg>> hmm, negative. I'm using a file based configuration.
<The_Coolest> Is it possible to do it from code?
<edcragg> where do you need to configure it from?
<The_Coolest> There is a config file the user has, in it there is a list of pins the driver will be using.
<The_Coolest> I'm doing sw bitbang i2c, and need to enable pullups on the pins
ldevulder_ has joined #linux-amlogic
<narmstrong> The_Coolest: debugfs offers you a config interface, but on amlogic 3.14 the ponctuel driver is very incomplete
<narmstrong> *pinctrl
ldevulder has quit [Ping timeout: 256 seconds]
ldevulder_ has quit [Ping timeout: 240 seconds]
ldevulder has joined #linux-amlogic
chewitt has joined #linux-amlogic
<chewitt> narmstrong: Artur (The_Coolest) is working on adapting his VFD driver to mainline not 3.14 .. afaik
<narmstrong> What is vfd ?
<chewitt> video fluorescent display
<chewitt> it works nicely on 3.14 but has gpio dependencies that need reworking
<The_Coolest> Hi chewitt
<The_Coolest> I haven't started with mainline yet. There's a user with a I2C vfd chip, and it needs pullups enabled on the pins.
<The_Coolest> Because the driver isn't working on his box
<The_Coolest> narmstrong>> I still can't understand whether I can use MMIO for this?
<narmstrong> The_Coolest: on the amlogic kernels you are to free to use whatever you want ! It’s open bar !
<The_Coolest> aha, ok. And on mainline I'll have to use API?
<narmstrong> But on mainline, please use the in-kernel bitbanging libraries et DT to setup the pins and driver data
<The_Coolest> DT = device tree? That won't work
<narmstrong> It will, it must, otherwise you can stick to the amlogic kernels
<The_Coolest> That would require maintaining a bunch of device trees for every device.
<narmstrong> Yep, it’s my work ;-)
<The_Coolest> Thanks
<The_Coolest> Well, we tried that. It lead to a lot of confusion for users.
<narmstrong> You only need to push support for, and make sure it does not break, the reste will be done by the community
<narmstrong> Most of these devices are very similar and you could factorize over the amlogic ref designs support
<The_Coolest> In addition, file configuration is simple and users can do that themselves. Building a DT per device would prove a lot more time consuming.
<narmstrong> So each device could need only a few lines of specific DT
<The_Coolest> Yes, I know.
<The_Coolest> One sec.
<narmstrong> In your POV, but it won’t last in time
<narmstrong> One day the 3.14 and 4.9 kernels won’t build anymore, and you will need to hack another kernel and redo your work
<narmstrong> This is the long term expectation to use a vendor kernel
<The_Coolest> I'll explain my POV. Since I'm working on a driver that targets mostly TV boxes, rather than SBCs, adding support for each individual box is a lot of work
<narmstrong> You won’t have long term support for your device
<The_Coolest> And adds a lot of overhead in support and upkeep
<narmstrong> Sure, but pushing for mainline is a different goal
<The_Coolest> I tried it, and eventually we found a way to get around this.
<The_Coolest> Yeah, I'm aware
<The_Coolest> Everything in the driver should be ready. If a configuration file is not there, it falls back to DT configuration.
afaerber has quit [Quit: Leaving]
<The_Coolest> I understand that mainline support mean standardizing everything.
<The_Coolest> means*
<The_Coolest> I was just wondering how do I turn on the pullups on some pins via code - if possible.
<The_Coolest> in 3.14
<steev> narmstrong: so, not sure why but now all i'm getting with the xorg driver is X segfaults, seems to occur right after the HW_cursor_init() but not really seeing what would cause it
<narmstrong> steev: weird, there is not hw cursor support in the kernel
trem has joined #linux-amlogic
afaerber has joined #linux-amlogic
<steev> narmstrong: i know, that's why i'm not seeing what would cause it; also... is the r7p0 mali driver actually r7p0? a diff of the r6p1 shows... no differences
<steev> i'm using the r6p1 mali so for now, but found that odd
<steev> is the Xorg.0.log bits with the error
<steev> it seems it's X itself that's crashing, and the only thing i can think maybe is that i'm using gcc 8 instead of gcc 7 when X was built with gcc 7 afaik
<steev> that's the full Xorg log
<The_Coolest> What I was looking for was gpio_set_pullup....
<The_Coolest> ...I hope
<steev> hm, apparently it's xorg itself that's the cause, not the driver
<steev> i'm trying an upstream patch, see if it works
lissyx has quit [Ping timeout: 256 seconds]
<steev> nope, that just moved the goal post, gotta focus on other stuff now though, sadly
indy has quit [Remote host closed the connection]
indy has joined #linux-amlogic
ldevulder has quit [Quit: Leaving]
<steev> narmstrong: re: the 1366x768 - apparently it's a hardware limitation because it's not divisible by 4
<steev> in the hdmi pll or some such
trem has quit [Quit: Leaving]
vagrantc has joined #linux-amlogic