<hozer>
hey at least with the linux kernel we get to see all the bad code. No such chance will all the damn firmware for various hardware devices
rz2k has quit [Read error: Connection reset by peer]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #qi-hardware
nicksydney has quit [Remote host closed the connection]
wej_ has joined #qi-hardware
wej has quit [Ping timeout: 250 seconds]
BlackGyver_ has joined #qi-hardware
<BlackGyver_>
eggcelent
<BlackGyver_>
Good morning everyone
<BlackGyver_>
I'm a bit of a newb when it comes to hardware
<BlackGyver_>
I was looking to know what kind of performance increases (and in which kind of applications) I would get by having my RAM's clock speed higher than what my CPU asks for
<BlackGyver_>
ie. grabbing 2133Mhz RAM on a processor asking for 1333/1600
<BlackGyver_>
oh I don't think I'm actually on a good channel for that kind of questions, am I
<BlackGyver_>
whoops
<BlackGyver_>
Well, feel free to answer anyway if you have an idea
BlackGyver_ is now known as BlackGyver
<DocScrutinizer05>
BlackGyver: for the channel it's maybe a tad off topic, but anyway faster RAM will do nothing when your CPU doesn't use faster speed.
<DocScrutinizer05>
clock speed of RAM bus even
<DocScrutinizer05>
it's like with your car engine: it doesn't get more horsepower when your fuel has higher octane
<DocScrutinizer05>
fuel needs suppicient octane for the compression of your engine, and RAM needs to be fast enough for the RAM bus clock speed of your CPU. Using more than "sufficient" doesn't bring any benefit
<ysionneau>
well ram is not only about bus speed
<ysionneau>
it's also about switching from one bank to another speed
<ysionneau>
switching from read to write speed
<ysionneau>
etc
<ysionneau>
so "speed" of RAM matters (for DRAM I mean)
<DocScrutinizer05>
of course there are car engines that dynamically optimize the ignition point, and there are CPU memory controllers that "dynamically" adapt memory bus clock speed
<DocScrutinizer05>
ysionneau: well, yes. There are more parameters than only mere clock speed. There's stuff like RAS timing etc. But all that are parameters of the memory controller and unless the memory controller adjusts them, no increased speed of the RAM you use will change the system performance
<BlackGyver>
Alright! Thanks a bunch
<BlackGyver>
Sorry for the confusion about the channel
<BlackGyver>
Cheers! Have a good day!
<ysionneau>
these are parameter of the RAM, but indeed the memory controller needs to "know" them and use them
<DocScrutinizer05>
for PC architecture (x86) it's usual that CPU reads the parameters out of a config ROM in RAM and adjusts parameters of mem controller
<ysionneau>
yes
BlackGyver has left #qi-hardware ["Bangarang, motherfucker."]
<DocScrutinizer05>
but often you need to set them manually in BIOS
<ysionneau>
but then, if your memory controller is clever and know how to adapt, the limiting factor is the speed of your RAM
<ysionneau>
if your memory controller is stupid then indeed you don't care about RAM parameters
<ysionneau>
you just access it slowly, in a non pipelined way etc
<DocScrutinizer05>
there's no such thing like stupid memory controllers nowadays in all but the most stupid CPUs which only come with embedded RAM
<DocScrutinizer05>
usually RAM sticks have a small serially attached (EP)ROM with the parameters of the RAM on that stick, and the BIOS of your PC reads that out and sets memory controller parameters accordingly
<DocScrutinizer05>
some RAM sticks come with bogus or broken info in that ROM, and then you need to config RAM parameters in BIOS setup manually
<DocScrutinizer05>
there's no mem controller that can really autodetect speed of RAM
<DocScrutinizer05>
since there's no physical parameter on the signal lines that tells mem controller if RAM can cope with the speed
<DocScrutinizer05>
and RAM access is not async, i.e. there's no data-ready or other ACK feedback from RAM to controller
<DocScrutinizer05>
afaik
<DocScrutinizer05>
and re >><BlackGyver_> ie. grabbing 2133Mhz RAM on a processor asking for 1333/1600<< I doubt there are CPUs out there that "ask for" 1333/1600 but could go as fast as 2133
<DocScrutinizer05>
usually the SPI data has not even parameters for RAS/CAS etc on other than max clock speed of RAM
<DocScrutinizer05>
so when the RAM is saying 2133;3CAS;5RAS then a CPU running the RAM at 1333 nevertheless will use 5 CAS clock cycles and 3 RAS. So no speed increase at all, unless you calculate CAS/RAS etc manually and config it in BIOS setup manually. --- disclaimer AFAIK
<DocScrutinizer05>
and even that isn't worth it, the speed increase is rather marginal
<apelete>
Hi larsc
<apelete>
yesterday I was testing my mmc async requests patches against 3.16-rc5, and I hit a dma-jz4740 related bug: http://paste.debian.net/110350/
<apelete>
this is the one solved by these two patches:
<larsc>
well, thats a /dev/input/eventX driver, but not upstream material
<DocScrutinizer05>
nfc what I accepted ;-P
<DocScrutinizer05>
yup, guessed that much. Does it look useful though?
Textmode has quit [Quit: "It was one dev, naked in a room with a carton of cigarettes, a thermos full of coffee and bourbon, and all his summoned angels."]
<DocScrutinizer05>
IOW could some kernel hacker easily build an upstream compliant driver from it?
<larsc>
it doesn't look to complex
<DocScrutinizer05>
I'm asking you since I have no idea about "easily"
<DocScrutinizer05>
fine \o/ :-D
<DocScrutinizer05>
thanks a megaton!
* apelete
was thinking about hacking on JZ4770 kernel support for GCW0 soon, maybe he'll have to manage workload on both qi-kernel and gcw-kernel
<apelete>
nights are going to get ever shorter...
<DocScrutinizer05>
longer ;-)
<DocScrutinizer05>
and the days are endless then
<larsc>
I have a at least somewhat working gcw board now
<apelete>
haha, good point
<apelete>
larsc: oh, you're working on gcw0 already ?
<larsc>
no
<larsc>
but I have the board
<larsc>
I could work on it if I had time
<larsc>
I think they were looking on switching to the jz4740 mmc driver
jow_lapt1p is now known as jow_laptop
<apelete>
yes, I'll talk with pcercueil and mth about that
<DocScrutinizer05>
I don't like vox too much, but those sites sound not too much biased and unfair
<whitequark>
ugh
xiangfu_ has joined #qi-hardware
xiangfu has quit [Ping timeout: 250 seconds]
jekhor has joined #qi-hardware
pcercuei has joined #qi-hardware
jekhor_ has joined #qi-hardware
jekhor has quit [Ping timeout: 240 seconds]
wej_ has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
xiangfu_ has quit [Remote host closed the connection]
jekhor has joined #qi-hardware
jekhor_ has quit [Ping timeout: 240 seconds]
jekhor_ has joined #qi-hardware
jekhor has quit [Ping timeout: 264 seconds]
jekhor_ has quit [Ping timeout: 250 seconds]
jekhor__ has joined #qi-hardware
jekhor has joined #qi-hardware
jekhor__ has quit [Ping timeout: 240 seconds]
jekhor_ has joined #qi-hardware
dos1 has quit [Quit: Kabum!]
jekhor has quit [Ping timeout: 240 seconds]
dos1 has joined #qi-hardware
qwebirc13105 has joined #qi-hardware
qwebirc13105 is now known as rjeffries
<rjeffries>
wpwrak: suggest you add "anelok password device" to list of what channel covers
dos1 has quit [Quit: Kabum!]
dos1 has joined #qi-hardware
<kyak>
we can't discuss it without adding it to the list? :)
rjeffries has quit [Ping timeout: 246 seconds]
<wpwrak>
DocScrutinizer05: (license) hmm, i guess it depends on what you want to do
<wpwrak>
e.g., "to use, only as part of, or integrated within, Authorized Systems" and ""Authorized System" means the hardware system(s) or software program(s) marketed by you which contains an i.MX"
<wpwrak>
also, it only allows you to distribute object code, no source
<wpwrak>
so i'd heed nancy reagan's wide advice and "just say no" :)
<wpwrak>
"The included patches were created based on" sounds like derivative work. if the work it was derived from in under that license, then it may even be in violation to that license.
<wpwrak>
general rule: if some piece of hardware doesn't come with sufficient documentation to let you write your own complete firmware, but instead requires something provided by the vendor, then this almost always means that you can't use it for Free Software
<DocScrutinizer05>
sorry, I can't follow. We have a .c fule with a GPLv2 license and we have a datasheet that for sure has all needed info to write whatever you want
<DocScrutinizer05>
file*
<DocScrutinizer05>
I don't give a **** which way that .c file got created
<DocScrutinizer05>
the chip manufacturer provided c code with a GPL and in my book that GPL can't be overridden by any random general license that obviously is a standard disclaimer used for all code that manuf provides
<wpwrak>
ah, so freescale released source under GPL ? and added a non-GPL license ? nice organization :)
<DocScrutinizer05>
btw this is kinda ECHAN
<wpwrak>
i was just commenting on the license, since you asked for opinions on it
<DocScrutinizer05>
I honestly wonder what you refer to when you haven't seen the original