<DocScrutinizer05>
btw this "effect" of somewhat relaxing design constraints due to the RE&libre-fremantle situation improving over time has already been anticipated from beginning, and it's considered to be of no relevance to the hw design
<DocScrutinizer05>
or rather we rely on it for the modem stuff, incl audio, since these are design details where we impossibly can stay 100% compatible. For the rest the evaluation resulted in us probably being able to keep compatibility on a hw level (sth that changed now for the wl1837 but this should be manageable on sw level)
jefrite has joined #neo900
<Wizzup_>
wpwrak: strongly agree regarding kernel
<DocScrutinizer05>
Wizzup_: however that's unrelated to how we build Neo900
Defiant has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
there's one simple rule: stay compatible to N900 as much as possible
<Wizzup_>
That's odd considering you ship a BSP and not freemantle
<Wizzup_>
And since it seems quite doable to run even fremantle now with mainline kernel, why would you go for some vendor specific vulnerable buggy kernel
<DocScrutinizer05>
that's not odd, that's the Neo900 fioundation consideration
<DocScrutinizer05>
I don't go for *any* kernel. As mention ed several times now, we are not interested in kernel or any other software at Neo900 UG. We build hardware and the design rules are derived from above simple guideline: stay as much compatible to N900 as possible
<DocScrutinizer05>
let me ask the counter-question: why should we change *now* any of the Neo900 design originally made to be compatible to N900
<Wizzup_>
Aiming for a more featureful and useful kernel with arguably less security bugs as supported kernel (which is one of the reasons all the mainlining work is done) is not changing any original design
<DocScrutinizer05>
note please that mainline kernel won't be blocked or hindered in *any* way by Neo900 compatibility to N900
<Wizzup_>
It just seems odd to not make that kernel a main goal/focus
<DocScrutinizer05>
and agian, we are NOT aiming at any kernel, we build hardware
<DocScrutinizer05>
I don't care about kernel
<DocScrutinizer05>
Neo900 is _defined_ as the N900 successor that ideally is capable to run unmodified maemo fremantle
<DocScrutinizer05>
this does _not_ block or hinder _any_ of the leete new stuff you suggest we "should focus on" (which is actually completely out of scope for the hw development)
Defiant has joined #neo900
<DocScrutinizer05>
evaluating which details of N900 "API" to the hardware we possibly _might_ change when in a pinch, since it's possible to fix that incompatibility with a patch to fremantle (kernel or userland) doesn't mean we should deliberately introduce such incompatibilities on hw level without any sound reason
<DocScrutinizer05>
there's not even a benefit for mainline kernels when we e.g. change GPIO_98 signal to an arbitrary other GPIO pin
<DocScrutinizer05>
or even to a IO-extender
<DocScrutinizer05>
as long as we can stay with the original N900 design, we should do that, no?
<DocScrutinizer05>
evidently fremantle can run now on that design even with mainline kernel, so why would we want to change that?
<DocScrutinizer05>
and when the DM3730 SoC partially isn't compatible to OMAP3430, that's still not anything we could cure by rearranging GPIO assignments
<DocScrutinizer05>
I really fail to understand the rationale behind all that noise
Pali has quit [Remote host closed the connection]
<DocScrutinizer05>
maybe it's a tad hard to understand what's going on without knowing what is the topic behind the scenes: assigning signals to GPIO-extenders. This is a hardware thing that only marginally is related to kernel. It however is basically identical with the design rule to keep maximum N900 compatibility. So yes, I agree it's highly desirable to have a working mainline kernel (as already stated several times. And who would disagree on that?)
<DocScrutinizer05>
but that's not in any way relevant for the GPIO assignments done on a hw level
<Wizzup_>
If you think the mainline kernel is fine, then I also don't see why noise needs to be made about tha
<Wizzup_>
t
<DocScrutinizer05>
exactly
<DocScrutinizer05>
the reasonable approach is to try keep the original N900 design and evaluate whether we might change some GPIO *only* when we run into a situation where we actually would *need* to do that
<DocScrutinizer05>
this is only related to any software considerations when we actually need to do such reassignment. But so far there is no need for that
mad_dev has joined #neo900
<DocScrutinizer05>
and in ourt closed channel I already tagged ~50% of the GPIO signals as "candidate for emergency reassignment" so we have a lot of choice already for signels to tackle to help us out of any pinch
<DocScrutinizer05>
it makes no sense to evaluate the remaining 50% _now_
mad_dev has quit [Quit: leaving]
xman has joined #neo900
<DocScrutinizer05>
in simple words: maemo stock kernel works on N900, mainline kernel works on N900. Neo900 will try to copy that as much as possible, so far no problems with that approach.
<DocScrutinizer05>
I really don't get the rationale behind >>no need to try to design hardware around a problem that's trivial to fix in software<< when the hw already IS compatible and no problem detected
<DocScrutinizer05>
it's rather we should not create problems in hw just because we found we can work around them in sw
<DocScrutinizer05>
there is no sound rationale for doing so
<DocScrutinizer05>
as if there weren't enough real problems we already need to tackle in sw since we can't avoid them by simply keeping what we got, on a hw level#
<DocScrutinizer05>
why to add to that workload just "because we can"?
enyc has quit [Ping timeout: 250 seconds]
<wpwrak>
but the hardware is not compatible with N900 in that way. to cover a significant part of the device's functionality, you inevitably need to change the kernel, even if you choose to start from an old kernel.
enyc has joined #neo900
<wpwrak>
and the reasons why i'm pushing towards not restricting GPIO assignment without need are that 1) anything on LOWER + BOB that can go to an IO expander won't need space on the connector, and 2) if we can assign more CPU GPIOs to UPPER, we can almost certainly avoid having yet another IO extender on UPPER (connecting to the CPU is cheap up there)
<wpwrak>
but i'm now actually more worried about the expectation that a N900 kernel would be able to do anything useful on Neo900. i mean, you could probably get it to start, talk to the display and such, maybe use a serial console, but that's already all it will do. it won't know where our keyboard is. it won't be able to talk to the modem, it won't know about WLAN and BT. and so on.
<wpwrak>
so in any case, you need a kernel that's configured for the board. and assigning GPIOs is just part of the configuration.
<wpwrak>
and i think what freemangordon tried to say regarding manpower is that nobody cares about dragging an obsolete kernel to new hardware. especially not after all the work of getting all the RX51 stuff into the current mainline kernel. so a modern kernel is a far better starting point than an old kernel.
<DocScrutinizer05>
the kbd issue is known. everything else is no problem since we handled identical stuff for other peripherals that need a kernel module. That's what KP is all about, and I don't buy the "we are starting to redesign the Neo900 now, just to prematurely optimize on GPIO while we don't even know if we run into any problems"
<DocScrutinizer05>
that's absolutely needless complication of both hw and sw development
<DocScrutinizer05>
and regarding kbd, I still wail to grok the deeper rationale why Nik insisted in an additional chip instead of exploiting the existing kbd scanner in twl4030
<DocScrutinizer05>
fail to see*
<DocScrutinizer05>
btw building and adding kernel modules doesn't count as "change the kernel" for me
<DocScrutinizer05>
we had all GPIO on SoC in N900, and our SoC has the pretty much same pin count, also for available GPIO. Any new signals may go to IO-extenders anyway. So I don't see how we possibly could get short on GPIO, unless some of them need to make space for a bus or whatever that we use on Neo900 but wasn't used in N900. In that case those GPIO could get reassigned to an IO-extender as well as to another primary GPIO (unless they are fast). So
<DocScrutinizer05>
the whole issue why we would want to mess with GPIO boils down to "reduce pincount on B2B conn between UPPER and LOWER, at the expense of adding IO-extender chips" - not a sound argument for doing such thing
<DocScrutinizer05>
we have a maybe 2 or 3 additional signals like ADCIN that were not used at all in N900, but those are no subject to GPIO-extending anyway. And we have a 120 lines on the B2B. Please let's just see how far that gets us, before we start messing with GPIO reassignment
<wpwrak>
we use two more USB interfaces, WLAN is SDIO instead of SPI, and so on. so yes, there are fewer pins available.
<DocScrutinizer05>
we have one more USB and one less McBSP
<DocScrutinizer05>
wild guessing doesn't get us anywhere here, as doesn't premature optimization
<DocScrutinizer05>
if the pinmux yields conflicts already, I'd love to hear about them
<DocScrutinizer05>
and worst case the B2B conns are not 'pinned' by any requirement either
<DocScrutinizer05>
so why would we want to reduce pincount there when that increases complexity of the design and doesn't even save us PCB real estate?
<DocScrutinizer05>
I'r ratgher tend to increase their pincount if needed
<wpwrak>
pinmux doesn't yield conflicts yet because we haven't assigned GPIOs yet :) but the number of unused pins is smaller than the number of GPIOs we need.
<DocScrutinizer05>
did that evaluation already take into account that we will use IO-extenders for all the new stuff?
paulk-nyan-big has joined #neo900
<DocScrutinizer05>
where "new" includes complete modem, freeing up GPIO formerly used by BB5 modem?
<wpwrak>
no, that was before IO extenders.
<wpwrak>
and you're one USB short: we have 1) OTG, 2) modem, and 3) HB.
<DocScrutinizer05>
yes, and modem will get compensated by McBSP
<DocScrutinizer05>
IOW we use a formerly not used USB function and free up a formerly used McBSP bus
<DocScrutinizer05>
we added HB USB after you said it's available
<wpwrak>
depend on how you count. ULPI is 12 signals, SSI is 8. and the formerly not used USB still removes twelve GPIOs
<wpwrak>
yes, the USB function block is available
<DocScrutinizer05>
it also needs to be available on balls
<wpwrak>
sure
<wpwrak>
that's what pinmux ensures
<DocScrutinizer05>
when we can't afford those 12 pins for ULPI, we will discard it
<DocScrutinizer05>
pinmux lacks the GPIO heritage from N900 aiui
<wpwrak>
finding the blob compatibility requirements is the purpose of this discussion ;-)
<wpwrak>
and as it turns out, there are none. so this is actually a very good result.
<DocScrutinizer05>
so please check if any of the USB ULPI pins needed by HB are already allocated to a N900 GPIO. If that's the case, we will look into those signals and see if they can get rearranged to IO-extenders
<DocScrutinizer05>
after all _that_ is the purpose of pinmux tool
<wpwrak>
it won't help much there because it doesn't know the n900 pins
<DocScrutinizer05>
since Neo900 schem doesn't have CPU/SoC yet, the pinmux should get based on N900 schematics
<DocScrutinizer05>
since that is what we try to implement, unless comletely unfeasible
<DocScrutinizer05>
pinmux is meant to tell us about any problems in implementing that
<wpwrak>
pinmux tells us about conflicts when using function blocks or at the level of individual pins (i.e., if using gpio and function of the same pin)
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
<DocScrutinizer05>
yes, exactly. Going through the N900 schematics ^F-searching for "GPIO_" will conveniently provide the pins already assigned to GPIO function. As soon as anything (e.g. HB ULPI) conflicts, we'll notice immediately
<DocScrutinizer05>
then we can decide if that's something to invest a few minutes pondering to move the GPIO function to somewhere else, or if we can't do that and need to drop or move the (e.g.) ULPI interface
<DocScrutinizer05>
usually I assume GPIO could move, since (as you elaborated) we basically have full control over all of them
<DocScrutinizer05>
but unless we run into such conflict, we generally should keep the legacy GPIO design and assignment
<DocScrutinizer05>
since failing to do so causes additional workload and cost on both EE and kernel dev department
<wpwrak>
naw, what helps with the EE workload is to decrease the number of requirements a little :) e.g., fewer things that need to go from UPPER-LOWER -> easier to find a suitable connector
<wpwrak>
but let's see what all the conflicts are ...
<DocScrutinizer05>
((what helps with the EE workload is to decrease the number of requirements a little)) a misconception, since those things already are done and no need to redo them again just because we invested more "useless" work elsewhere to make them easier than they been when we already accomplished them
<DocScrutinizer05>
I.E. we already *have* 120 pins B2B. we should use them and see how far that gets us, instead of trying to 'simplify' stuff here
<wpwrak>
where 120 so far is just a wild guess of how much we'll need. so until we have at least a tentative assignment, this fits only a very special definition of "done" ;-)
<DocScrutinizer05>
((first try)) the "...is already in use by LCD:mcspi3_*" sound pretty strange, since we didn't assign anything LCD to any new interface
<wpwrak>
anyway, see above for the list of conflicts between N900 GPIOs and Neo900 function blocks
<wpwrak>
LCD had to move from SPI#1 to SPI#3, due to a conflict
<wpwrak>
i think it was some MMC that pushed it there
<DocScrutinizer05>
so whe have conflicts on HB.USB:hsusb2*, and Modem.UART*, and
<wpwrak>
well, that pushed it away
<DocScrutinizer05>
HB.USB conflicts are nasty
<DocScrutinizer05>
ECI, HEADPH_IND, ACCEL_INT1|2, the first 2 are trouble
<DocScrutinizer05>
I guess fixing ACCEL_INT should be easy
<DocScrutinizer05>
for fixing the fist 2 (audio related) we again need to look into the notorious nokia_av.ko and rx51.ko
<DocScrutinizer05>
first*
<DocScrutinizer05>
BTRSTX should also be fixable
<DocScrutinizer05>
when I say "fixable" I mean on sw level
<DocScrutinizer05>
ACCEL_INT is prolly MCE related
<DocScrutinizer05>
so as far as I'm concerned, this has lower relevance for me than the powerkernel stuff
<DocScrutinizer05>
it's completely unclear if mainline kernel actually provides a working audio implementation for N900
<wpwrak>
also appears at a bunch of other places. e.g., Documentation/devicetree/bindings/sound/nokia,rx51.txt, arch/arm/mach-omap2/board-rx51-peripherals.c, and arch/arm/mach-omap2/pdata-quirks.c
<DocScrutinizer05>
is free to join that effort and contribute to patching fremantle so it runs on 4.6 kernel
<DocScrutinizer05>
but that's considered step #2 of the Neo900+maemo project, step #1 being to make a plain 2.6 kernel with unaltered fremantle work on the device
<DocScrutinizer05>
I don't think those 2 steps are any mutually exclusive
<DocScrutinizer05>
nobody said we'll get fremantle compatibility for free, but I estimate the effort to get powerkernel to work and possibly backport a few drivers much lower than the effort to port all the closed blobs in fremantle to new kernel api as in e.g. 4.6
<DocScrutinizer05>
and the effort will be the lower, the less GPIO reassignments and similar stuff we introduce, that need handling in kernel
<DocScrutinizer05>
makes some sense now?
<wpwrak>
kernel-user space APIs tend to be fairly stable. internal APIs change all the time. so backports are usually no fun, especially not over large distances
<DocScrutinizer05>
yes I know
<wpwrak>
but i guess this is a question best answered by freemangordon and/or Pali
<DocScrutinizer05>
alas even the kernel-user API changed massively
<wpwrak>
after all, they should know what they got to work and what not ;-)
<DocScrutinizer05>
yep, of course. I'm only suggesting here, I'm only the EE that builds the hw
<DocScrutinizer05>
for the wl18xx backport we have a huge advantage: both wl12xx 2.6 kernel driver, and wl12xx and wl18xx driver for 4.x kernel do exist
<DocScrutinizer05>
and wl12xx and wl18xx supposedly at least somewhat similar
<DocScrutinizer05>
so backporting the diffs between wl12xx and wl18xx driver for 4.x to a wl12xx 2.6 kernel driver should be a tad simpler than writing this thing completely anew
<DocScrutinizer05>
I dunno, maybe even a wl18xx driver for 2.6 kernel exists already, I never searched for it
<DocScrutinizer05>
TI guys on LKML/linux-USB recently assured me in private mail about their dedication to OpenSource. Maybe worth asking them
<DocScrutinizer05>
maybe also worth asking them about PVR?
<DocScrutinizer05>
I guess with an NDA we might even get access to the source for PVR maybe
<luke-jr>
otoh, PVR guys on #Dragonbox-Pyra recently informed us they even go out of the way to sue infringers :/
<luke-jr>
so probably only so much TI can do
<DocScrutinizer05>
please rephrase
<DocScrutinizer05>
what exactly happened?
<luke-jr>
DocScrutinizer05: just discussion of PVR's position on IP more or less
<DocScrutinizer05>
yeah, TI can't make FOSS from PVR, but they for sure can share the sourcecode under NDA
<luke-jr>
someone asked hypothetically if Pyra used the leaked code, would PVR sue, and the answer was affirmative
<DocScrutinizer05>
well, not for sure, but maybe
<DocScrutinizer05>
yes, sure. They don't want to see leaked code get used
<luke-jr>
ie, the asker was probably hoping for a "we're look the other way"
<luke-jr>
we'd*
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
that's not how stuff works in industry
<luke-jr>
I also asked how much $ we'd have to crowdfund for a free license to the code, and basically got a non-answer
<DocScrutinizer05>
at OM we had access to the glamochip and partial calypso sourcecode under NDA
<DocScrutinizer05>
imagination doesn't want to FOSS that code, it seems (though there been also other statements at times), but they obviously need to grant access to the code under NDA when they want their stuff to sell
<luke-jr>
apparently they threw $ at some contractor to write them a FOSS replacement a while back, but terminated the project because it didn't perform :/
<DocScrutinizer05>
so if Neo900 UG could do that (hiring a developer), we probably should consider to actually follow that path
<DocScrutinizer05>
as long as we have to use that closed proprietary stuff anyway, I'm not averse to give it the best possible support, even when that means signing a NDA
<DocScrutinizer05>
I'm rather pragmatic about that sort of stuff, even while I very much prefer FOSS over any proprietary cr*p
<DocScrutinizer05>
but we have a PVR for gfx in OMAP and nothing we could do about that. So I think it there's _any_ possibility to provide the best possible support for it to our customers, we should consider doing that
<DocScrutinizer05>
s/it there/if there/
<DocScrutinizer05>
I don't mind having 5 showers a day to feel semi-clean again ;-)
<DocScrutinizer05>
(glamo chip) for the docs which were several 100 pages, we had full permission to use all the info, write FOSS drivers based on that, even create our own docs as comprehensive as we want, even up to publishing our own several 100 pages of complete glamo docs. The *only* thing strictly forbidden was quoting the original glamo docs
<DocScrutinizer05>
it's a tad hard to understand what's industry's concerns about that 'sekrit stuff', usually it's about patent trolls etc
<DocScrutinizer05>
and the worst thing as soon as it comes to this topic: lawyers get involved
<ds2>
wonder what would it take to have a license forbiding lawyers ;)
<DocScrutinizer05>
lawyers even still think you could copyright-protect schematics. You can't, but try to educate them on this fact, it's futile
<ds2>
"License be solely interperted as understood by the majority of 12 non legally educated individuals."
<DocScrutinizer05>
you can copyright-protect the mere artwork of a particular schematic paper, but you can't protect the circuit it shows
<DocScrutinizer05>
even when the circuit is patented, still the representation of the circuit in a schematic is not illegal. Only literally copying a schematic document is protected under copyright
<DocScrutinizer05>
at least that's been the situation last time I evaluated it
<freemangordon>
wpwrak: what is APESLEEPX in terms of Neo900?
<freemangordon>
ok, there are 3 or 4 more to be removed from the equation, used by bb5
<DocScrutinizer05>
it's related to the R&D mode kbd blinking and I doubtr we will implement it
<freemangordon>
hmm, no
<freemangordon>
oh, wait
<DocScrutinizer05>
ooh is it BB5?
<freemangordon>
I think so
<DocScrutinizer05>
I could be wrong
<freemangordon>
the other one is SLEEP_IND IIRC
<DocScrutinizer05>
anyway it's not considered relevant for Neo900
<DocScrutinizer05>
yep, you're right
<DocScrutinizer05>
SLEEP_IND, NSLEEP1 and SYS_CLKREQ
<DocScrutinizer05>
where sleep_ind is a GPIO
<freemangordon>
:nod:
<DocScrutinizer05>
so APESLEEPX is _suspected_ to be part of a watchdog implemented inside BB5
<DocScrutinizer05>
that controls and possobly resets the APE CPU
<freemangordon>
DocScrutinizer05: re KP and mainline - believe me, KP/stock is a nogo for Neo900, we simply won;t be able to make it work reliably on Neo900, given the manpower, lack of support from the mainline devs and the original omap1 devs
<DocScrutinizer05>
please list the differences to OMAP3430
<freemangordon>
If I have 5 full-time kernel devs to distribute tasks to, then *maybe* it should have been possible
<freemangordon>
it is not only the omap, backporting wifi/bt drivers is not a fun task, give how much the kernel API has changed since 2.6.28
<freemangordon>
etc
<DocScrutinizer05>
there are working DM3730 kernels, so any constants etc must exist for that SoC, to build a working kernel for it, based on what we got in KP
<freemangordon>
define "working"
<freemangordon>
as "booting to console" is not working in my book
<DocScrutinizer05>
it boots, it does proper powermanagement on the CPU and RAM, it is able to open a shell on console
<DocScrutinizer05>
it even will run fremantkle
<DocScrutinizer05>
I see possoble issues with PVR
<DocScrutinizer05>
the rest of the SOC is sufficently identical for all I know
<freemangordon>
toldya, it is not that similar.
<DocScrutinizer05>
I'm _not_ talking about drivers for the new WLAN or modem
<freemangordon>
I mean 3430<->3730
<freemangordon>
but you should to
<freemangordon>
because if we have to backport 2-3 drivers the size of wifi driver, then we simply won;t be able to do it
<freemangordon>
see, the difference between 2.6 and 4.6 is not only DT
<DocScrutinizer05>
before we moan about that not being feasibe, we first should check if there's maybe an existing driver already, or how much work it actually is to backport the TI sources which claim to be kernel version agnostic afaik
<freemangordon>
afaik wl18xx is upstreamed and I don;t see how that is kernel agnostic
<freemangordon>
if you mean wireless-compat, well...
<DocScrutinizer05>
I only know that there is some stuff TI considers sufficient to get the module working on whatever kernel
<DocScrutinizer05>
unless I missed something in there
<freemangordon>
DocScrutinizer05: again, we don;t have the manpower to check *all* the drivers and to port them
<DocScrutinizer05>
well, that's your problem
<DocScrutinizer05>
I'm not involved into sw development
<freemangordon>
and the solution to it is mainline kernel :)
<freemangordon>
not to say that, afaik, we share lots in common with gta04. is that assumtion correct?
<DocScrutinizer05>
I just think it's a tad strange to refuse cjhecking the source with the argument "we don't have enough manpower for that" and rather try to mess with modding & REing fremantle to the max, to make it work with new kernel
<DocScrutinizer05>
no, from a sw side that assumption is completely misleading
<freemangordon>
we already *have* fremantle 80% working with mainline
<freemangordon>
including PVR
<freemangordon>
includeing DSP
<freemangordon>
and we are in process of upstreaming camera drivers and the surrounding stuff, I expect 4.9
<DocScrutinizer05>
well, then that's great news, I hope you will manage to get the remaining 20% working as well
<freemangordon>
I guess we'll be able
<DocScrutinizer05>
it however doesn't change anything for Neo900
<freemangordon>
it changes a lot, because fremantle will already know about all the new kernel interfaces
<DocScrutinizer05>
for our customers it's great news however, since most of them want a working maemo on the device, no matter which kernel
<freemangordon>
so what will be needed is a couple of relatively simple drivers for some exotic HW in neo900 and a board DTS
<DocScrutinizer05>
:nod:
<freemangordon>
(not sure what exotic HW there is :) )
<DocScrutinizer05>
well, the monitoring stuff comes to mind
<freemangordon>
some GPIOs?
<DocScrutinizer05>
:nod: - plus ADCIN
<freemangordon>
or is it ADC?
<DocScrutinizer05>
and I2C
<freemangordon>
already have support for that, writing iio ADC driver is a couple of days using the iio framework
<freemangordon>
another good think about mainline kernel is that API has evolvet to a stage when you already have FW support form most of the devices one can imagine
<DocScrutinizer05>
basically we have IRQs that need to do some ADCIN or other simple tasks in worker thread
<freemangordon>
*thing
<freemangordon>
so basically you just use a couple of macros and you have a working driver implementing the stable kernel API
<DocScrutinizer05>
fine
<freemangordon>
which is not the case with 2.6
<DocScrutinizer05>
yep, I guess that's true
* DocScrutinizer05
idly wonders if AV-jack detection and type sensing works in mainline
<freemangordon>
last time I checked it, yes
<DocScrutinizer05>
wow
<DocScrutinizer05>
please test with watch -d -n1 'for f in /sys/devices/platform/nokia-av/type /sys/devices/platform/nokia-av/detect /sys/devices/platform/nokia-av/autodetect /sys/devices/platform/nokia-av/eci* /sys/devices/platform/soc-audio/eci_mode /sys/devices/platform/nokia-av/madc; do echo "$f: `cat $f`"; done'
<freemangordon>
but it was a while since I did that. However, if it doesn;t work, we simply spit on the guy who broke it and he has to fix it :)
<freemangordon>
don;t have time now
<DocScrutinizer05>
not now :-) eventually
<freemangordon>
ok
<DocScrutinizer05>
I'm honestly a tad lost in analyzing how that stuff actually works
<freemangordon>
I have to do more stuff, (like resending i4-rx51 driver patches, fixing et8ek8 patch etc), unfortunately my spare time is a bit limited lately
<DocScrutinizer05>
madc is important for sure
<freemangordon>
DocScrutinizer05: asking again as I had to reboot my PV yesterday - what is going to be used for PM - twl4030?
<freemangordon>
*PC
<DocScrutinizer05>
yep
<freemangordon>
is it still available? wow
<DocScrutinizer05>
exactly like N900
<DocScrutinizer05>
that stuff is "in TI's catalog" I've been told, which seems to mean they have LTS for it
<freemangordon>
ok
<DocScrutinizer05>
not even announced to go EOL yet
* freemangordon
is back to playing HL2ep1 :), bbl
<DocScrutinizer05>
have fun
* DocScrutinizer05
takes a short nap
silviof has quit [Ping timeout: 272 seconds]
silviof has joined #neo900
jonsger has joined #neo900
bredebid has joined #neo900
Pali has joined #neo900
SylvieLorxu has joined #neo900
galiven_ has joined #neo900
galiven has quit [Ping timeout: 260 seconds]
Xiaoman has quit [Read error: Connection reset by peer]
Xiaoman has joined #neo900
xray256 has quit [Ping timeout: 250 seconds]
xray256 has joined #neo900
trx has quit [Ping timeout: 272 seconds]
trx has joined #neo900
saper has quit [Remote host closed the connection]
l_bratch has quit [Quit: Leaving]
l_bratch has joined #neo900
<wpwrak>
freemangordon: thanks for confirming the 2.6 vs. 4.6+ situation ! that's pretty much what i expected. it's always like that - sticking with an old kernel may be tempting at some point, but it quickly turns into an uphill battle.
<wpwrak>
furthermore, since you can't "keep up" anyway, the focus will then shift to maintaining functionality but not fixing bugs that don't visibly affect functionality. e.g., security issues.
saper has joined #neo900
<wpwrak>
and of course, you'll probably miss any security fixes that aren't clearly flagged as such, especially those that result from fixing / changing something else.
mad_dev has joined #neo900
<MonkeyofDoom>
old kernels are the worst
<wpwrak>
perfect summary ;-)
vakkov has quit [Ping timeout: 260 seconds]
chomwitt has joined #neo900
<chomwitt>
hi from greece
vakkov has joined #neo900
<mad_dev>
chomwitt: Hello from the other side
enyc has quit [Ping timeout: 260 seconds]
enyc has joined #neo900
mad_dev has quit [Ping timeout: 252 seconds]
mad_dev has joined #neo900
jonsger has quit [Quit: jonsger]
<DocScrutinizer05>
the kernel lock in is maemo's biggest problem from beginning. Well, together with the closed blobs that are closely related
<DocScrutinizer05>
Nokia built a basically monolithic block made of kernel and a deb metapackage consisting the complete system and threw that over the wall. It never been meant to be maintainable
<DocScrutinizer05>
Nokia always considered maemo their property
<DocScrutinizer05>
seems to me jolla did almost same, in exactly same or even worse spirit
<MonkeyofDoom>
Tizen is the same
<MonkeyofDoom>
with Samsung
<DocScrutinizer05>
prolly, yes
<MonkeyofDoom>
I have a Z3 :)
<MonkeyofDoom>
the 3.10 kernel shipped on it has available sources, but I don't know if they're fully complete
<MonkeyofDoom>
and there's a lot of undocumented closed-source userspace nonsense
<MonkeyofDoom>
running a 4.x kernel with ofono on *something* is the eventual dream...
<DocScrutinizer05>
as long as it's not tivoized by a signature-checking bootloader...
<MonkeyofDoom>
I don't think it is
<DocScrutinizer05>
but yeah, a proprietary linux stays a proprietary linux
<DocScrutinizer05>
until some smart guys RE all the closed blobs
<MonkeyofDoom>
*most* of the kernel stuff for the Z3 is proprietary but has source in the GPL dump
<MonkeyofDoom>
proprietary in the sense that it doesn't use kernel code style or kernel device interfaces
<DocScrutinizer05>
yeah, nasty
<MonkeyofDoom>
weird "/dev/sprd_sensor" crap instead of /dev/inputN or proper sysfs nodes, so on... and Mali GPU, which is a big blob
herpderphurr has quit [Ping timeout: 250 seconds]
bredebid has quit [Ping timeout: 244 seconds]
herpderphurr has joined #neo900
<wpwrak>
oh, i thought mali was kinda open ?
<Sicelo>
MonkeyofDoom: nice to hear from a Tizen user .. as i will likely move there when both my N900 die :-/
xman has joined #neo900
<MonkeyofDoom>
Sicelo: yep...
<Sicelo>
otherwise, besides the other issues you mention .. how easy/difficult is it to port a regular linux application to Tizen?
<MonkeyofDoom>
you can run command-line stuff trivially... X11 stuff will *run* but for reasons I haven't figured out entirely will not actually be *visible*
<MonkeyofDoom>
(though it does accept input events and so on
<MonkeyofDoom>
)
<MonkeyofDoom>
you can get EFL apps to play nicely without too much trouble