Xiaoman has quit [Read error: Connection reset by peer]
Xiaoman has joined #neo900
SylvieLorxu has quit [Client Quit]
SylvieLorxu has joined #neo900
herpderphurr has joined #neo900
illwieckz has quit [Ping timeout: 240 seconds]
illwieckz has joined #neo900
silviof has quit [Ping timeout: 272 seconds]
illwieckz has quit [Remote host closed the connection]
xman1 has joined #neo900
xman1 has quit [Client Quit]
xman has quit [Ping timeout: 252 seconds]
saper_ is now known as saper
xman has joined #neo900
louisdk has quit [Ping timeout: 250 seconds]
enyc has quit [Ping timeout: 260 seconds]
enyc has joined #neo900
<wpwrak>
Pali, freemangordon: i have a question about GPIOs we need to retain for compatibility with non-open N900 software: i discussed such pins with joerg, and i get the impression that nokia actually did some quite clean abstraction, with the part that actually knows there a certain signal is, being part of (open) kernel code
<wpwrak>
in other words: it seems to me that there are few if any signals that would actually have to be at the same pin for compatibility, given that the kernel needs some amount of adaptation anyway.
<wpwrak>
would you concur with this interpretation ? or are there some nasties i haven't thought of ?
lobito has joined #neo900
jonsger has joined #neo900
<freemangordon>
wpwrak: well, Nokia did the so-called gpio-switch driver which isn't upstream and won;t be
<freemangordon>
the "modern" way to do stuff is to use gpio-keys driver, which has board-dependent configuration
<freemangordon>
so, in that regard, gpio numbers does not really matter, just be careful to not use a pin assigned for other function
<wpwrak>
even gpio-switch looks pretty friendly. nice maps in arch/arm/mach-omap2/board-rx51-peripherals.c and arch/arm/mach-omap2/pdata-quirks.c :)
<wpwrak>
freemangordon: yup, it's the sort of question where it is better to not act already on the first response ;-)
<DocScrutinizer05>
givern we talk about KP, I don't see which are the changes needed in kernel
<DocScrutinizer05>
we *might* need a new bootloader and actually I'm pretty sure we want a new and free one, but kernel?
<freemangordon>
DocScrutinizer05: KP?
<wpwrak>
DocScrutinizer05: device tree at least. and i'm sure there's some glue stuff that won't fit, drivers that may need small improvements, etc. standard stuff, basically. also, won't we switch to a more modern kernel ?
<freemangordon>
also, i don;t see why not use 4.7 and above
<DocScrutinizer05>
freemangordon: why?
<DocScrutinizer05>
sure we can use 4.7
<freemangordon>
because n900 has almost everything upstreamed
<DocScrutinizer05>
but I don't see why we *need* a new kernel
<freemangordon>
because of 3730
<DocScrutinizer05>
so? that's supposed to be compatible to 3530, no?
<freemangordon>
no
<DocScrutinizer05>
what differs?
<wpwrak>
(new kernel) because we're not identical to n900 ? :) we need new drivers (and won't need some old ones) and so on
<freemangordon>
for example ISP is totally different
<DocScrutinizer05>
ISP?
<freemangordon>
there are other major differences as well
<freemangordon>
image signal processor, aka cameras
<DocScrutinizer05>
wow, you might be right
<freemangordon>
I am, I am struggling with cameras on n900 for the last 3 months or some
<DocScrutinizer05>
I know :-)
<freemangordon>
which involves ISP driver code as well
<DocScrutinizer05>
:nod:
<wpwrak>
ah, ISP sounds interesting. will this break the old cam blob ? or does that one sit on "portable" interfaces ? (v4l, etc.)
<DocScrutinizer05>
i'm aware we have no HS device, but that shouldn't matter. I always was under the impression all other IP was backward compatible to 34xx in 36xx/37xx (where xx = xx)
<freemangordon>
well, it is tricky, there is omap3camd which uses some proprietary (but foss) interface to v4l (iirc), we will have to reomplement that
<freemangordon>
DocScrutinizer05: no, there is no 100% compatibility
<DocScrutinizer05>
there's a TI porting from 34 to 36 guide IIRC
<freemangordon>
good, but I prefer to have support from the kernel devs than struggle with porting KP by myself
<DocScrutinizer05>
sure
<freemangordon>
that is why upstream is the viable option
<DocScrutinizer05>
DT is broken by concept, in my book
<wpwrak>
and i bet we'll find some things where existing abstractions don't quite fit, or where the driver doesn't use the chip the way we want to. especially if it's drivers for some older "compatible" chip.
<freemangordon>
wpwrak: there'll be no problem to have one and the same kernel for n900 and Neo900, with different attached .dtb
<wpwrak>
freemangordon: oh, sure. i wasn't proposing we'd need a fork ;-))
silviof has joined #neo900
<DocScrutinizer05>
I was assuming we *could* run even original kernel, and until we tested that I don't believe in too many incompatibilities, particularly none that couldn't get patched in original kernel
<freemangordon>
see, right now, in 4.7-rc we have everything but ISP/cameras and DSP working(if I am not missing something) . And that includes cpufreq, PM, etc
<freemangordon>
there are still problems with PM, but the framework is there
<DocScrutinizer05>
I'm not saying we can't use 4.7+
<DocScrutinizer05>
I just say I can't believe and didn't know so gar that Nokia did invompatible changes in register addresses or semantics from 3430 to 3730
<DocScrutinizer05>
so far*
<wpwrak>
original kernel wouldn't make sense. we have lots of differences already in peripherals. even if you could get it to boot somehow, it wouldn't be useful. not even for development, since you'd never quite know if problems would be caused by confused drivers and such.
<freemangordon>
:nod:
<DocScrutinizer05>
no, we don't have that many diffs in peripherals
<wpwrak>
besides, then you'd have to preserve pretty much all gpio-pin associations, which would be a little nightmare of its own
<DocScrutinizer05>
actually for those peripherals we had in N900 there should be zilch diff
<DocScrutinizer05>
yes we have new peripherals, that's no reason why we need a new kernel
<freemangordon>
it is, because we don;t have the manpower to support the old one
<DocScrutinizer05>
yes, that is the idea to preserve as many GPIO as possible
<freemangordon>
DocScrutinizer05: what will be the PM controller? twl4030?
<Pali>
why do you care about GPIO numbers and it compatibility?
<Pali>
IIRC cssu-devel userspace use it only for cellular modem
<wpwrak>
what good would a kernel do that doesn't even have keyboard, no connectivity at all (i.e., no USB), ... ? that just doesn't make sense
<Pali>
all other stuff in cssu-devel was converted to proper kernel layers
<freemangordon>
Pali: what about different switches?
<Pali>
which switches?
<freemangordon>
kbd, power, etc
<freemangordon>
Pali: BTW, wpwrak is asking :)
<Pali>
isnot mce using /dev/input layer (which comes from gpio-keys)?
<DocScrutinizer05>
don't get me wrong, I'm not saying we don't need any patches to make maemo work on Neo900, but that's no reason to now abandon the concept of keeping maximal compatibility to N900
<wpwrak>
Pali: i'm trying to correctly describe the compatibility needs for GPIOs. DocScrutinizer05 always said that there was a lot of non-open user space code that depended on 1:1 compatibility
<Pali>
only sscd daemon for cellular modem needs that GPIO switches in userspace
<wpwrak>
Pali: but now it seems that this isn't really an issue
<freemangordon>
Pali: yes, iirc, I ported that, but I guess wpwrak doesn;t have the time needed to dig into mce code
<DocScrutinizer05>
wpwrak: the compatibility needs are described in ~fptf #1 #2
<DocScrutinizer05>
wpwrak: we won't introduce new GPIO pin number just because we can, now
<freemangordon>
DocScrutinizer05: well, afaik the concept is to keep neo900 compatible with Maemo
<Pali>
I think there will not be compatbility for bb5 cellular chip, right?
<DocScrutinizer05>
first we try to fix the fremantle core system foss bits to match the new hw platform.
<DocScrutinizer05>
if that can't be done we try to patch the kernel device drivers so the new device looks like the the N900 one to userland
<DocScrutinizer05>
if that can't be done we try to RE userland blobs or binary-patch them or write bridging-adapters from one ABI to the other
<DocScrutinizer05>
if that can't be done we need to adapt the hw platform to more closely resemble the N900.
<wpwrak>
it seems that "first" is easily covered. no need to try to design hardware around a problem that's trivial to fix in software ;-)
<Pali>
yes
<DocScrutinizer05>
I won't take that for given until POC exists
<DocScrutinizer05>
my problem is I work that list bottom up
freemangordon has quit [Remote host closed the connection]
<wpwrak>
any in any case, if you want a usable system you can't use the old kernel binaries. and in any case you really don't want to be stuck with a kernel based on some ancient mainline.
<DocScrutinizer05>
that's why I asked SERVERAL TIMES to make a port of maemo to a BB-xN
<DocScrutinizer05>
to see what actually can get patched easily
<DocScrutinizer05>
wpwrak: proof needed
<DocScrutinizer05>
the 2nd half of that sentence is irrelevant to me, since that's the devel's business
<DocScrutinizer05>
the first half is unsupported by any proof
<wpwrak>
how do you expect to, say, use the keyboard if you don't have a driver for it ? also, does a wl1837 (wlan) driver even exist for that ancient kernel ?
<DocScrutinizer05>
I'm still pretty sure we could boot into KP5x and modprobe a few new modules, and done as far as kernel is concerned
<DocScrutinizer05>
a wl1837 driver can get built for stock nokia kernel like it can get built for 4.7 kernel
<wpwrak>
you could probably create an out-of-tree build to add some drivers. then backport others. etc. but why would you want to do that ? if you go to the pub, do you take a route that crosses antarctica ? ;-)
<DocScrutinizer05>
because of compatibility, heck!!!
<DocScrutinizer05>
and we WILL NOT go do weird reassigns of GPIO just because we can, and becuse you _assume_ it doesn't matter anyway
<DocScrutinizer05>
we are NOT going to rebuilt the complete system for a new target hw platform, the platform still is supposed to be compatible
<DocScrutinizer05>
to the point where in theory you could flash the original fiasco and then install a Neo900 compatibility metapackage from HAM
tsuggs has quit [Ping timeout: 250 seconds]
xman has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
you are the kernel devel guys, you tell me where the build differences are between OMAP35xx and OMAP37xx target, which #DEFINEs kick in and spoil stuff
SylvieLorxu has quit [Remote host closed the connection]
<DocScrutinizer05>
until you show me that a certain GPIO number is OMAP35xx specific and needs patches in 37xx anyway, I'll assume we stay compatible on a hw level and sw devels won't even need to think about it
SylvieLorxu has joined #neo900
<DocScrutinizer05>
heck, users pondered, even *tried*, to replace the SoC in **N900** by a DM3730, and all evaluations so far came to the result that it mostly should "just work"
<wpwrak>
seems that we "kernel devel guys" already have broad agreement that the best way forward is to stay close to today's mainline, and that gpios and such can be easily reassigned. and some changes to mainline will be needed anyway. or rather, it is strongly desirable to make these changes in mainline instead of having a bunch of local hacks that would have to be ported along.
<DocScrutinizer05>
I will ignore that
<DocScrutinizer05>
sorry
<DocScrutinizer05>
that's not a part of Neo900 design rules
<DocScrutinizer05>
you're drifting away on the "we can do it in software so we don't worry about it in hw" path
<DocScrutinizer05>
this approach always been a big NOGO for Neo900
<DocScrutinizer05>
agauin: as long as we can stay compatible with N900 on a hw level, WE WILL DO SO. period
<DocScrutinizer05>
I already elaborated on the few excemptions of that rule I consider tolerable, in private channel, this noon
<DocScrutinizer05>
they are basically all those switches and (hall-)sensors that show up as GPIO-switch in sysfs
<DocScrutinizer05>
except those who are closely entangled with blobs
enyc has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
just because we _got_ IO-extenders now, doesn't mean we will use them for everything and reassign _all_ GPIO from SoC to extenders just because we can
enyc has joined #neo900
<DocScrutinizer05>
IO-Extenders are a last resort
<DocScrutinizer05>
and a fine means for signals we didn't even have in N900 anyway
<DocScrutinizer05>
the rest stays untouched!
<DocScrutinizer05>
let me be very clear on that: we WILL NOT assign every possible IO signal on lower to a IO-Extender, and in the end of the day celebrate that we have 37 unisued pins on the 2 B2B conns between LOWEr and UPPER thanks to that
<DocScrutinizer05>
unused*
<DocScrutinizer05>
au contraire we will try to assign / route every IO signal in system to its legacy pin on SoC and only when we run into issues we can't solve we resort to IO-extenders
<DocScrutinizer05>
this doesn't apply to all-new signals like the whole modem (monitoring) stuff
<DocScrutinizer05>
this applies all the more when we hear freemangordon claim that we don't have manpower to maintain the old kernel. So we ned to design the hardware in a way so it is maximum useful with unmaintained kernel
<DocScrutinizer05>
to avoid ambiguities and misconceptions: I will ignore what kernel devel guys agree upon as best way forward (despite I wholeheartedly agree with you on it) simply because it's irrelevant for how we design the Neo900 hardware
<DocScrutinizer05>
so as long as the way Neo900 is designed will not be a *roadblock* to that best approach you and me agree upon, there's no impact from that on the Neo900 design. I don't see any such possible roadblock in keeping maximum compatibility to N900