<woprr>
currently using olimex A20 debian image as restarting point, Linux version 3.4.67+ (root@debian) (gcc version 4.7.1 (Debian 4.7.1-7) ) #6 SMP PREEMPT Fri Nov 1 17:32:40 EET 2013
<libv>
that's pretty nasty for the case where "hdmi" gets renamed to "hdmi0" though
<libv>
but workable
<libv>
but first food, sobering up, and then sleep ;p
<libv>
ooh, this is generic ahb gates setup
<libv>
add this patch and my stuff should work
<woprr>
I've some news on the TS controller from a prof.equipment manufacturer,looks like the TSC can't passthru the full mpegt-ts or lack of docs, project suspended
<libv>
yes!
<libv>
Turl: that was bang on
<libv>
Turl: it works :)
<libv>
all of it finally, somewhat, fits together
<libv>
yay!
<libv>
patches in 6-10h ;)
<Turl>
libv: :)
<libv>
seems i might have met the u-boot deadline as well
<libv>
Turl: beer on you and turl ;)
<libv>
err, wens
<libv>
pfff, it's bad when you go out on the day the bar owner has a birthday ;)
<libv>
i never get this drunk until we shut down the next 2 bars ;)
<wens>
Turl: the fix is queued for 3.17
<wens>
Turl: btw, your audio related clk patches don't do clkdev_register?
ricardocrudo has quit [Remote host closed the connection]
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<libv>
wens: this clock stuff really needs work
<libv>
the fact that these bitmasks depend on a list defined in a dtsi file... that's just asking for trouble
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<wens>
the other alternative is to use the clock-indices properties
<libv>
and that's before what you fixed here
<libv>
why not reproduce the names and the bit indexes again in clk-sunxi.c ?
<libv>
that gives much more certainty to which names are which bits
<libv>
it keeps the lot in one place
<libv>
everything else is asking for trouble
<libv>
it's just more typing
Andy-D has joined #linux-sunxi
<libv>
but that's the thing about typing, you only have to do it once, whereas unintuitive stuff, that you will fall into more often
<wens>
the DT part of the clk stuff requires them :/
<wens>
clock-output-names that is
<libv>
who requires clock output names?
<Turl>
libv: lol
<libv>
<&clock bit> is all that i see
<libv>
which i find totally perverse
<libv>
<&clocklabel bit>
<libv>
even
<libv>
which never, at runtime, leads to anything useful
<wens>
libv: you require the parent's name (a string) when you register a clk
<libv>
which string?
<wens>
which you get from the dt by looking up the phandle, then getting the node's name or it's clock-output-name
<libv>
wens: try to set, from u-boot, ahb_de_fe0
<wens>
see of_clk_get_parent_name()
<libv>
that's really up a creek without a paddle
<libv>
what parent?
<libv>
clk@register_addr
<libv>
why bother if you need to know the exact register address?
<wens>
for the plls, it would be osc24M
<libv>
wens: but for these ahb bits?
<wens>
libv: the ahb clock
<libv>
which one?
<Turl>
libv: the one on clocks = <...> on the gate node
<wens>
all the gates have the ahb clock as their parent
<wens>
though I don't think it would help in this situation
<libv>
Turl: and should it really be necessary for me to use something else entirely, when the individual bits already have a symbolic name, described in clock-output-names?
<Turl>
here's a thought
<Turl>
have a node that's pretty much complete, sans the fb address
<libv>
my view is, clock-output-names should be unique
<Turl>
find fb0 on uboot using aliases
<Turl>
fill the reg
<Turl>
tada
<libv>
Turl: no.
<libv>
Turl: because that means that the simple-framebuffer compatible section must _always_ be present in every dt
<wens>
libv: the names are unique, otherwise they wouldn't register with the clk framework. I think you mean something else?
<wens>
lookup-able perhaps?
<libv>
it does not allow u-boot or any other player to add something like that at boot time or any other time
<Turl>
libv: and so should the simplefb driver?
<libv>
wens: yeah, you cannot create a clk entry from the name
<libv>
nobody ever finished that thought
<libv>
instead, everyone just described <&label bit>
<libv>
which is broken
<libv>
dts files should label clock dependencies by name
<libv>
as the bits will shift from soc to soc
<wens>
and that's why you have different dts and drivers for different socs
<libv>
clks are the only ones which seem to be very special here
<libv>
clks are always described as <&label bit>
<libv>
never by name
<wens>
there's also resets, phys
<libv>
it feels wrong, and that's before you start to try to solve shit like simple-framebuffer
<libv>
wens: it's wrong
<libv>
one part of the soc just needs to know that it needs the hdmi ahb bus enabled
<wens>
but if you reference by name, you'd do a lookup everytime?
<libv>
wherever that bit lives, it shouldn't care
<libv>
wens: why not?
<Turl>
libv: that part of the soc has a clocks = <&ahb bit> on its node
<libv>
it's barely any more overhead than looking up a phandle
<libv>
Turl: in the dts, yes
<Turl>
the driver only needs to get "bus" and enable it
<libv>
Turl: but not in the dtb
<libv>
it is resolved in the dtb
<Turl>
libv: then decompile it and recompile it? :)
<libv>
&label no longer exists
<libv>
Turl: sure. that is logical.
<wens>
&label becomes what? a link to the actual node?
<libv>
why not just look up a clock by name?
<libv>
an integer
<libv>
check /proc/device-tree/.
<libv>
try finding ahb-gating in /proc/device-tree/
<libv>
try finding ahb_de_fe0
<libv>
in a proper world, clk-sunxi needs to match name through soc to actual ahb gating bit
<wens>
i guess the integer matches the value in "phandle" in the referenced node?
<libv>
Turl: how many lines of code would you need from u-boot to achieve that?
<libv>
Turl: and what happens if you are on a20 instead of on a13?
<wens>
libv: i mean, you still have to grep through the dtb to find the matching one?
<wens>
or does the dtb have some index
TheSeven has quit [Read error: Connection reset by peer]
<libv>
even though the ahb_de_fe0 bit still is supposed to have the same name?
<libv>
Turl: you will have to look for the sun7i-a20-ahb-gates-clk compatible node first
<libv>
but that means that you first need _very_ exact knowledge about the SoC you are running on
<libv>
and then you need to pray that the compatible string did not change
TheSeven has joined #linux-sunxi
<wens>
they are still different in sun6i/sun8i
<libv>
wens: sure, but that's a serious step up already
<libv>
and i, as a graphics driver, would have to really care for sun6i/sun8i
<Turl>
libv: one call to fdt_node_offset_by_compatible(...) (assuming uboot has libfdt, which the doc seems to imply)
<libv>
whereas i do not need to care for sun4i/5i/7i
<libv>
but due to some stupidity in device-tree, i suddenly do
<libv>
wens: infrastructure should never impose artificial limitations
<libv>
there is no way to argue against it
<libv>
referencing clocks as <&label bit> is fundamentally broken
<Turl>
libv: there's always a practical limit to things
<libv>
Turl: this is not a practical limit
<Turl>
referencing clocks by only name is bound to collisions and bad performance
<libv>
this is just an unfinished thought
<libv>
ahb_de_fe0 is pretty unique
<Turl>
besides that's it's not compile time verifiable by dtc
<libv>
ahb.de_fe0 would be just as unique
<libv>
then why even have clock-output-names?
<libv>
why bother?
<Turl>
the names are just a convenience for debugging
<libv>
no
<libv>
as otherwise i couldn't do what i just did
<libv>
otherwise what wens just fixed never would work
<libv>
i truly am amazed that my 1+promille still can make an argument like that
<libv>
i am mcnulty
<Turl>
libv: you could make names like "clk@0xdeadbeef.5"
<wens>
Turl: the output-names are used when you register the clock with the framework
<Turl>
always guaranteed unique
<libv>
wens: why wouldn't you register the clock names?
<Turl>
wens: there's no real use for the names other than the clkdev (ab)use
<wens>
if you don't specify them, normally you default to using the node name
<Turl>
it's just nice to name the things with descriptive names
<libv>
wens: the final lines of clk-sunxi.c say it all
<libv>
this will never work without unique clock names
<wens>
Turl: you can still lookup the names in clk_get
<Turl>
wens: not if you don't register them with clkdev
<wens>
which is why you should register them i suppose
<wens>
why on earth is clkdev separate from clk anyway
<libv>
why does one need to register them?
<Turl>
clkdev goes unused in the dt world
<libv>
they are in the dts
<Turl>
libv: one doesn't if you're using dt
<libv>
what use is that?
<Turl>
libv: we tried to kill the clkdev registrations
<Turl>
we then realized we were using it in the clk protection stuff
<wens>
libv: for old platform code i guess
<Turl>
as we don't have a nicer solution it's staying in place for now
<libv>
Turl: oh, so you tried to get rid of the fact that you need to know which clocks need to be enabled at certain times, but then it was realized that this might have been kind of crucial?
<Turl>
libv: no
<Turl>
libv: we tried to get rid of the legacy "name to clk*" mapping (as we are using dt)
<Turl>
but then realized that code you see in the footer was there and used it
<libv>
Turl: by replacing it with <&label bit>
<libv>
i am pretty sure that naming was better.
<libv>
naming provides this thing...
<libv>
whatsitsname...
<libv>
oh
<libv>
abstraction!
<Turl>
libv: so does the phandle with specifier
<libv>
no
<libv>
not when phandle is a number
<libv>
which can only be found by clk@register_address
<Turl>
which is like...
<Turl>
never for the people writing dt
<libv>
yes, until one tries thinking outside of the box for a single second
<libv>
and then suddenly the failure to abstract thing comes back to bite everyone in the ass
<libv>
ahb_de_f0
<libv>
err,
<libv>
ahb_de_fe0
<libv>
that's pretty fing unique
<libv>
or do you want to see it as ahb.de_fe0
<libv>
if you have two of those in an SoC
<libv>
then i think that clashing clock names is the least of your troubles
<wens>
ePAPR doesn't specify clocks... hmm...
<Turl>
libv: and how do you want to reference it? by clocks = "ahb.de_fe0"?
<wingrime>
De_fb is ugly name itself
<libv>
Turl: sure
<Turl>
wingrime: display engine, frontend
<libv>
Turl: it works from the clk-sunxi.c code
<libv>
but it never works the other way around
<wingrime>
Not explain anything , for any one who see it first time
<libv>
the other way around can only be described as <&ahb_gating 14>
<Turl>
wingrime: yeah, it's not the best name, but well
<libv>
with &ahb_gating getting resolved to some integer
<libv>
so why does it work from the kernel
<wingrime>
Turl: why not sunxi_vbe sunxi_vfe
<libv>
and why is it never supposed to work from .dts, or, by hacking a .dtb directly?
<libv>
why do you have to state <&label bit> in a dts?
<libv>
why?
<libv>
it works from the other end
<libv>
why is it artificially moronified from this end?
<wens>
wingrime: the names follow whatever was in the datasheet it seems
<wingrime>
wens: sure
<Turl>
libv: because you write the dt with datasheet in hand
<Turl>
and there's numbers there
<libv>
Turl: ok, let's try this differently
<wingrime>
wens: also, cedarx was not video engine name, just video player in melis it self
<libv>
Turl: mmc1: mmc@01c10000
<libv>
which of the ahb bit does it use?
<libv>
Turl: we both could intuitively state "ahb_mmc1", and we could, if we were inside the linux kernel
<libv>
Turl: but what is described inside the dts?
<libv>
<&ahb_gates 9>
<libv>
what if another soc came along, which was 99.999999% the same
<libv>
but just had this one bit at 10 instead of 9?
<libv>
why would you need a totally new dtsi file for that?
<Turl>
you just include and override?
<libv>
why couldn't clk-sunxi.c know which bit was the ahb bit for mmc1 on this particular soc?
TheSeven has quit [Ping timeout: 250 seconds]
<libv>
Turl: surely the fact that the list of names is defined in the .dtsi, and the actual bits, in fully respective order, are defined in clk-sunxi.c should tell you that something is fundamentally wrong?
<Turl>
libv: why should clk-sunxi care what the gate does?
<libv>
?
<Turl>
it should care that it's a gate
<Turl>
and that's about it
<libv>
what?
<libv>
it _does_
<libv>
it full does
<libv>
but the data is spread all over the place
TheSeven has joined #linux-sunxi
<libv>
am i really hearing this?
<libv>
last night i posted a link where i directly edited a mask
<wens>
i think it's the framework that cares, not the individual drivers
<libv>
no
<libv>
the driver cares in this case, big time
<libv>
those masks i changed
<libv>
that was matching names with bits
<Turl>
libv: the driver just cares about where they are
<libv>
but the names are in .dtsi
<Turl>
the dt cares about what they do
<libv>
yet the bits are in clk-sunxi.c
<wens>
so let's get rid of the masks then
<libv>
wens: how?
<libv>
Turl: heh?
<libv>
Turl: so you want to further detach the names from the bits?
<libv>
Turl: how?
<wens>
libv: move the bits to the dt
<libv>
Turl: solar flares?
<libv>
wens: and that will gain us, what?
<Turl>
libv: there's no use for the names themselves
<wens>
albeit this is going to break the whole dt
<libv>
wens: more nodes?
<Turl>
they could be randomly generated unique strings
<wens>
libv: just another property
<libv>
wens: ?
<wens>
let me fish out my original sun8i clk patch
<libv>
wens: so we will describe every bit in every register in every soc in the device tree?
<wens>
libv: just for the gates
<Turl>
the compatible is there to encode what the hardware is
<libv>
wens: why?
<wens>
i guess it's a dumb approach :|
<libv>
wens: why not give the gates unique names and let clk-sunxi deal with the rest?
<libv>
why not have the logical solution?
<libv>
clk-sunxi should know how to deal with its own bits, for each SoC
<libv>
dt is there to abstract the different drivers from eachother
<Turl>
libv: it already does?
<libv>
not to abstract every driver
<libv>
from the actual hw
<libv>
Turl: yes, badly
<Turl>
libv: dt is there to describe the hardware and how it interconnects
<libv>
clearly.
<libv>
Turl: no
<libv>
dt is there to describe how the hardware interconnects
<Turl>
describe the hardware present*
<libv>
it is not there to describe every detail of the hardware
<Turl>
ie, what is it that it's there
<Turl>
yeah, that
<libv>
<&label bit> is not abstracting how hardware interconnects
<libv>
"ahb_de_fe0" is
Andy-D has quit [Ping timeout: 272 seconds]
maksimlin has joined #linux-sunxi
<libv>
"ahb_de_fe0" is prettty unique and reasonably universal
<Turl>
libv: what about reg = ?
<Turl>
why not use "address of the mmc1 controller registers" then?
<libv>
<&label bit> is pretty direct and needs to be changed everytime the one doing the verilog coughs
<libv>
Turl: this is an address
<libv>
Turl: this reg stuff describes where the mmc1 registers live
<libv>
Turl: not how every single bit of the mmc1 engine reacts
<Turl>
and the <&phandle> stuff describes what gate the mmc needs
<Turl>
or clock, or whatever
<libv>
Turl: through 5 redirections
<libv>
unnecessary redirections
<libv>
unstable redirections
<Turl>
libv: which the driver doesn't care about, and the dt writer finds convenient
<libv>
either by register range address
<libv>
or by compat string, "allwinner,sun5i-a13-mmc"
<libv>
why not just have a unique clock name?
<wens>
I suppose you would want the interrupt numbers as strings?
<Turl>
that too
<libv>
if that makes sense, why not
<libv>
but for clks it definitely makes sense
<libv>
which is why people use them that way inside the kerne;
<Turl>
libv: people don't use that way inside the kernel
<libv>
this is what i am complaining about
<libv>
clearly they do
<Turl>
they use the way of "gimme my bus clock"
<libv>
Turl: otherwise wens his fix wouldn't be needed
<Turl>
and the bus clock appeared
<libv>
Turl: what is "gimme my bus clock" if you are called de_fe0?
<wens>
libv: that was the special case of using system clocks, as no device was tied to the call
<libv>
Turl: what do you call for then?
<Turl>
libv: clk_get(..., "bus") on your device probe
<libv>
Turl: really, answer that and you will see what i mean
<libv>
Turl: what bus?
<Turl>
clocks = <&ahb... n>; clock-names = "bus" on dt
<libv>
if the dts should have anything, it should describe which names match which bits at one point, and then the rest of the dts should use the name, not the bit
<libv>
Turl: yeah, unfinished thought
<libv>
<&label bit> is just wrong
<libv>
label: clk@....
<Turl>
s/wrong/not helpful when I am manipulating dt in uboot/
<libv>
clock-output-names= "name", "name", "name"
<libv>
with actual bits decided either earlier in that same clock description or inside the clk-sunxi.c driver
<libv>
you can discover discrepancies while compiling the dt
<libv>
if "name" does not resolve, you can complain
<wens>
libv: and what about the dts already living out there?
<libv>
with <&label bit> you can never
<libv>
wens: that's a lie anyway
<libv>
wens: i just went from some mripard tree version, to linus 3.16rcX
<libv>
and it gained m,c
<libv>
mmc
<Gerwin_J>
Yes price is high... I paid 5555 yuan (870usd) for my Pioneer 50" 4k TV some months ago
<libv>
no way was i getting anyway with the older dtb
<libv>
anywhere
<Turl>
libv: sure, but sunxi is not marvell.
<libv>
anyone who kids himself that a dtb is independent should be committed
<libv>
Turl: good luck with that thinking
<libv>
Turl: even stable platforms will change
<Turl>
libv: you can boot linux with the factory dtb on marvell hw
<libv>
but...
<libv>
if you have the sunxi display engine work off of clk_names
<libv>
you can get pretty far
<libv>
if you however need to know clk@offset:ahb_reg:bit
<Turl>
you can already get pretty far
<Turl>
it only hurts in uboot
<libv>
but you can get further
<libv>
Turl: it hurts while writing the dtb
<libv>
err, dts
<libv>
display is hugely complex
<Turl>
libv: do i need to paste the screenshot again? :)
<libv>
with many many clocks and many ahb bits, and 4 sdram bits
<libv>
if any one of those changes location, you get to copy past the lot
<Turl>
talking about sdram bits, I have to forward port those again
<Turl>
they're going to bitrot otherwise
<libv>
if they all are names...
<libv>
they never need to change
<libv>
they would be the same for all allwinner A generations
<Turl>
libv: but you need to change the name to bit mapping somewhere else
<Turl>
you still need to do stuff...
<libv>
Turl: sure, that's what the clock driver is for
<Gerwin_J>
current bid is 2000 yuan... it start yesterday at 8 yuan
<libv>
clk-sunxi.c is not called clk-marvell.c for a reason
<wens>
Turl: about clock-indices, i think it's a good mapping for whomever needs to do lookup through the dtb
<Turl>
Gerwin_J: is it going for charity or something?
<libv>
Turl: the point is, the display driver should never care where its ahb bits actually live
<Turl>
libv: worry not, it won't
<libv>
Turl: the display driver just need to state that it needs the specific ahb bus enabled
<libv>
Turl: it _does_
<Turl>
libv: it doesn't
<libv>
Turl: dts describes the exact bit\
<Gerwin_J>
i don't know... it's today some a80 launch day thing
<Turl>
libv: dts is not the display driver
<libv>
in the display driver bits
<libv>
Turl: which is wrong
<wens>
libv: but the driver code doesn't care
<libv>
wens: but it should care even less.
<wens>
libv: it just needs to do clk_get(dev, [0-n])
<libv>
the display section of the dtb shouldn't care then
<wens>
slightly off topic, but are the frontend and backend drivers separate?
<libv>
the display section should just list the names
<Turl>
libv: you're just pushing the responsibility up, do you want code in firmware giving you a list of names and letting you toggle and tune them? :)
<libv>
it should not care about which exact bit in the ahb_gating register it is
<libv>
Turl: it's simple
<libv>
Turl: the display driver section in devicetree does not need to list <&ahb_gating bit>
<libv>
Turl: either the ahb_gating clock description in dt has the full description, or the clk driver knows how to map this
<libv>
the display driver section in device tree would just state "ahb_de_fe0"
<libv>
everything else gets resolved for it
<libv>
as the other bits not only are smart enough to handle that, they fundamentally need to be smart enough to handle that
<Turl>
libv: so to parse dt now you need to generate a hash table to discover clocks?
<Turl>
I was going to send another set of dma driver patches (which, gasp! use <&dma endpoint>) but I think I'm going to sleep earlier
<libv>
Turl: this becomes a secondary issue
<Turl>
libv: would you be happier with "names"?
<libv>
Turl: but this is nonetheless valid
<libv>
labels are only for dts
<libv>
not for dtb
<wens>
&dma is also a label
<libv>
the amount of data in a devicetree is overseeable and pretty limited
<libv>
and is not needed every second
<libv>
it usually is needed once
<libv>
making it harder to lookup, but more descriptive and abstract, that pays
<libv>
the amount of labour you need to look it up from a name, instead of a slight shortcut, is not relevant
<libv>
the expressive power going way up, that's what's the really timesaver
<libv>
s/really/real/
<Turl>
libv: you'd need to ensure the expressive power does not make you take twice as long to write a dt for a new SoC
<libv>
Turl: it definitely won't
<libv>
Turl: as part of this lookup would, in this case, be handled in the clock driver
<libv>
you will need to look up the bits once
<libv>
not many times.
<libv>
once in the driver, for the changed clk block in the new soc (if it changed at all)
<libv>
if the clk block didn't change, but other bits didn't, then the clk part stays absolutely the same
<libv>
so you save having to alter <&label bit> everywhere in case the clk block changes
<Turl>
which is just a find/replace
<libv>
if the name matches, nothing but the clk driver needs to change
<libv>
but that needs to change anyway
<libv>
if the bits in the clk block change
<libv>
no find/replace in the dts needed at all
<libv>
at least not for the unrelated engines
<libv>
Turl: make changes in one place, or make changes all over the place
<libv>
i thought dt was there to help abstraction
<libv>
not to push a lack of abstraction to another level
<Turl>
libv: if your SoC changed you got a new dtsi
<libv>
Turl: if the arm core changed, you'd have no need to change the display engine
<libv>
today, if the clk ahb bits move...
<libv>
you're stuffed
<libv>
even it if it is a33 version 1 version a33 version 3
<Turl>
you'd still be writing a new dtsi
<Turl>
and copying your engine block
<Turl>
modifying it is not much hassle
<libv>
what is the i in dtsi?
<libv>
include perhaps?
<Turl>
include, for when you have a machine and include the soc :)
<libv>
why does there only get to be a single include?
<Turl>
it doesn't
<libv>
why do i have to describe the display engine in every sun*i file?
<libv>
sounds like a lot of trouble
<libv>
i'd prefer to have 2 display dtsi's
<Turl>
libv: probably, yeah. some don't have hdmi or vga output capabilities
<Turl>
so your muxing will be different
<libv>
1 for a the first full pipe, a second for the scond
<Turl>
(is there muxing for video?)
<libv>
Turl: the secret there is, hdmi block is there on A13
<libv>
it responds
<Turl>
but it's unusable
<libv>
and?
<libv>
it says "nothing on hpd"
<libv>
when asked
<Turl>
at the very least be considerate and leave it disabled :p
<libv>
why?
<libv>
it could be an a10s
<Turl>
poor trapped hdmi block who wanted to play movies
<libv>
this is what i do on uboot
<libv>
i check for hpd
<Turl>
libv: a13 and a10s have different dtsi
<libv>
no hpd, fine, all clocks get disabled again
<libv>
no matter whether it is an a13, a10s or a20
<libv>
i do not lose much
<libv>
a few ms
<libv>
saves a whole lot of logic which could easily go wrong
<Turl>
you can &display { hdmi { status = "disabled" } } and you needn't even bother
<wens>
Turl: lcd pins have muxes, hdmi doesn't
<Turl>
or whatever the binding is (usually it's the other way round)
<libv>
sure, or not include a hdmi dtsi
<libv>
Turl: the thing is, bits move, very very easily
<libv>
.dt should not occupy itself with just bits
<libv>
addresses are important for dt\
<libv>
engines move addresses all the time, you really do need to know where they live since this is not pc world and you do not have pci
<Turl>
libv: the gates don't move
<libv>
but individual bits?
<Turl>
they just (dis)appear and leave holes
<wens>
personally i think if the vendor tweaks the bits in later revisions, it's kinda screwing the customer one way or the other
<libv>
Turl: a register bit is just a typo in verilog away
<Turl>
libv: on the verilog they just copy and paste
<libv>
Turl: de_be lives at 0x800 in its designated register range
<Turl>
that's why we have pata clocks and stuff
<libv>
Turl: de_be needs to have its registers memset(0) after ahb enable
<libv>
that's a rather serious typo right there
<libv>
so far, this was kept
<libv>
but someone soon will fix this
<Turl>
libv: there's a pll that comes out of range out of reset
<Turl>
:)
<libv>
and this is the most serious idiocy i have seen so far
<libv>
a bit is much much easier to typo
<wens>
libv: and the de_be doesn't have a proper soft reset?
<libv>
wens: yup
<libv>
wens: 0x800 :)
<libv>
something really stupid went wrong there
<libv>
and this influenced more than one thing
<libv>
really, an f-ed up bit it much much easier
<libv>
names help hide that
<libv>
clk-sunxi would know about it
<libv>
sunxi_drm or .dtb wouldn't have to care
<libv>
radeonhd dvi code
<libv>
difference between r5xx and r600 and rv610
<libv>
halfway the shared tmds/lvds register range, another register was added, everything above that register was shifted by 4 bytes
<libv>
ati couldn't care less about this big hw design nono
<libv>
as "atombios" was supposed to magically hide all that
<libv>
and the 3-4 bits in that new register, we couldn't use them anyway as they were some hdcp or somesuch
* wens
looks at the watchdog changes between sun4/5/7i and sun6/8i
<libv>
we just needed to add another abstraction to properly have us write the exact same values to a +4bytes register
<libv>
bits are easy to shift
<libv>
display does not need to know about shifted bits in the clk block unless really necessary (like there not being a second de_fe in a13/a10s)
<libv>
but it really would be easy
<Turl>
libv: how many times would you need to write the dt?
<libv>
if the display driver tries to request "ahb_de_fe1" and it doesn't work, then it could just not init de_fe1
<Turl>
you can do that today
<libv>
Turl: less than one would have to type <&ahb_gating bit>
<libv>
Turl: clocks = "ahb_de_fe0"
<libv>
versuse
<libv>
clocks = <&ahb_gating bit>
<Turl>
they're both O(1)
<libv>
one is generic and flexible (with minimally increased lookup time), other is fixed
<libv>
other gets translated to 0x00000012 0x00000bit
<Turl>
which, as a driver author or dt author, don't really care about
<libv>
until you try something slightly more specialized
<libv>
again, unfinished thought
<libv>
you do not lose any epressivity when using names
<libv>
expressivity even
<Turl>
you gain on complexity
<libv>
the whole mode would make more sense
<libv>
no
<Turl>
for no net benefit for the majority
<libv>
especially not in our case
ccaione has joined #linux-sunxi
<libv>
our clock code is pretty sick with the clk bit masks
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
<libv>
we have names in the dts, which can only be matched by bit masks in the driver
<libv>
and then we reference only bits in the dts
<libv>
that's asking for problems
<Turl>
because the names are just a convenience. /me waits for libv to say they're not
<Turl>
we're just cycling over the same over and over
<libv>
oh yeah, i have only covered every point 5 times so far
<Turl>
I think I'll break; and get some sleep :)
<libv>
Turl: the clock description in the .dts describes what?
<libv>
Turl: a register address, and the size of the registers
<libv>
and then a list of names
<Turl>
libv: what kind of clock there is
<Turl>
who their upstream is
Quarx has joined #linux-sunxi
<libv>
so, intrinsically, this list of names is something for the clock driver to resolve
<Turl>
libv: and it's documented as such
<libv>
ok
<Turl>
"domain specific", iirc the wording
<libv>
but all those referencing the clock....
<Turl>
and "clients should not use those names"
<libv>
they need to use the label and an actual bit
<libv>
offset
<libv>
an actual bit offset
<libv>
not even the count of the enabled bit in the mask
<libv>
which is something one could expect to be possible as well
<Turl>
libv: would you rather look at the number staring at you on the datasheet, or count the names in a list 3 times because your sight is not that good or you lost count, only to find out they added a new one and it broke?
<libv>
Turl: you just made my point
<libv>
Turl: the clk code should have a full match of name versus bit
<libv>
1-1
<libv>
not names in one list in the dts, and bits in a mask in the clk code
<libv>
names versus bits in one table in the clk code is what is needed
<Turl>
libv: they're not separate though
<Turl>
they're glued together with a compatible string
<libv>
they could be more widely compatible
<libv>
moving bits is cheap
<libv>
and as i said, trying to match "allwinner,sun7i-a20-ahb-gates-clk" versus "allwinner,sun4i-a10-ahb-gates-clk" just to get to "ahb_de_fe", that's sick
montjoie[home] has quit [Ping timeout: 256 seconds]
<libv>
if "ahb_de_fe" is unique inside the linux kernel
<libv>
why can it not be unique in the dt, or from uboot?
<libv>
i think that that is the 6th time i made that point
<libv>
mcnultied...
montjoie[home] has joined #linux-sunxi
<Turl>
libv: and again, you just &ahb_gates, needn't worry about the compatible, but you're going through hell because you're doing this in uboot etc etc :p
<libv>
Turl: the solution i had to concoct now is fundamentally wrong
<libv>
Turl: what if i decide to throw in the lcd in u-boot?
<libv>
Turl: what if i need a totally new mode for that, incompatible with hdmi
<libv>
i would need to enable 2 more engines
<libv>
how do i tell userspace about that?
<libv>
err, kernelspace
<Turl>
the other problem stems from simple-fb not describing hw... deja vu
<libv>
no
<libv>
even if simple-fb had a clock property
<libv>
how would i add clocks?
<Turl>
libv: you'd have a proper description of the video blocks
<libv>
....
<libv>
how?
<Turl>
which would have all the correct clocks, because it's a good description of the video blocks
<libv>
Turl: where would i describe those?
<libv>
Turl: in the kernel dtb?
<Turl>
libv: in the dtsi
<libv>
err, dts?
<Turl>
yeah
<libv>
ok, so how would uboot deal with this?
<libv>
u-boot, being the actual driver
<libv>
being the bit that knows what is on and what is off
<Turl>
uboot would find &hdmidisplay with the help of an alias, and fill in the reg of the fb
<Turl>
just like it's done for eth and mac addresses
<libv>
Turl: what if you try to boot a slightly older kernel?
<libv>
or a dtb file which does not have this yet?
<libv>
both could happen
<Turl>
you'd get no display
<Turl>
so?
<libv>
how would you know?
<Turl>
how would you know what?
<libv>
how would the kernel complain?
<libv>
lcd is on, hdmi failed
<libv>
good luck debugging that one
<Turl>
why would the kernel complain? you just said it was old and didn't support this
<libv>
maybe the dtb was old?
<libv>
Turl: if i had the ability to state: simple-fb, memory here, size here, pitch here, clocks used :x,y,z
<Turl>
you'd look at the log and see no mention of the framebuffer
<libv>
Turl: all i need to have is "ahb_de_be0", "ahb_de_lcd0" "ahb_de_hdmi"
<libv>
i just need to describe 3 clocks
<libv>
if i get to describe them by unique names, everyone is happy
<libv>
but i don't, because dt clk descriptors need <&label bit>
<libv>
it's just a nobrainer.
<libv>
&label does not resolve after compilation
<libv>
bits shift easily
<libv>
&label needs to be resolved to phandle, which is a random integer depending on the order of devicetree listing
<libv>
if they'd add parents, things would be even better
<libv>
ahb.de_fe0
<libv>
or ahb_gate.de_fe0
<libv>
nobody cannot deny that that is unique
<libv>
Turl: clk descriptions as <&label bit>, that's broken, and it goes in against the base idea of device tree
<Turl>
<&label bit> is as unique and it's linked
<Turl>
you can get the clock node easily
<libv>
the clk driver needs to know about name <-> bit
<libv>
the dt needs to know just names
<libv>
Turl: i invite you to write the uboot code to implement this
<libv>
Turl: and i also hope that you maintain that code in future
<libv>
it's just a nightmare
<libv>
i had no other option but to handle it from the kernel side
<libv>
because that is the only thing that made sense
<libv>
anyway, you'll see the code in a few h, after both of us have had some shuteye
<mripard_>
libv: claiming that "one string I just made up is unique!" is just shortsighted, wrong, and doesn't work
<mripard_>
I'd suggest to sober up, learn your shit, read some doc, and then think more about it.
prahal_ has joined #linux-sunxi
prahal_ has quit [Client Quit]
paulk-collins has joined #linux-sunxi
Andy-D has joined #linux-sunxi
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 260 seconds]
bertrik has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
hramrach has quit [Remote host closed the connection]
Andy-D has quit [Remote host closed the connection]
hramrach has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Andy-D has quit [Remote host closed the connection]
popolon has joined #linux-sunxi
maksimlin has quit [Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140715215003]]
notmart has joined #linux-sunxi
ccaione has quit [*.net *.split]
ccaione has joined #linux-sunxi
|JohnDoe71Rus| has quit [Quit: KVIrc Insomnia 4.0.2, revision: 402, sources date: 20100627, built on: 2010-08-02 17:44:33 UTC 402 http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Changing host]
JohnDoe_71Rus has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
ccaione has quit [*.net *.split]
ccaione has joined #linux-sunxi
benn` has quit [Read error: Connection reset by peer]
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 255 seconds]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 264 seconds]
HeHoPMaJIeH has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
nashwhat has joined #linux-sunxi
HeHoPMaJIeH has quit [Quit: Leaving]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 255 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
wingrime has quit [Read error: Connection reset by peer]
kivutar has quit [Ping timeout: 264 seconds]
<woprr>
http://linux-sunxi.org/Toolchain#Linaro_toolchain: "WARNING: Do not use the 4.8 gcc versions of the linaro toolchain" , what "issues"? arm-toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux build kernel 3.4.91-00267-g6ce48b3-dirty runs fine here.
nashwhat has joined #linux-sunxi
<woprr>
with debian wheezy armhf
wingrime has joined #linux-sunxi
<wens>
random crashes, etc.
nashwhat_ has quit [Ping timeout: 244 seconds]
<libv>
mripard_: which doc clearly describes the advantage of <&label bit> versus "name"?
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
kivutar has joined #linux-sunxi
<mripard_>
this one is called common sense
<mripard_>
but the libfdt, the ePAPR, and dtc shows in great lenght how phandle works.
<wens>
typo in sun6i dma commit by vinod: 92e4a3b dmaengine: sun6i: Remove
<mripard_>
wens: yeah, I saw that, but it's too late I guess
wingrime has joined #linux-sunxi
<wens>
:|
nashwhat_ has joined #linux-sunxi
<libv>
mripard_: so how do you feel about the _gates_data masks in clk-sunxi.c?
wingrime1 has quit [Ping timeout: 264 seconds]
<libv>
those bits are supposed to be a 1-1 match to something defined in a dtsi somewhere
nashwhat has quit [Ping timeout: 244 seconds]
<libv>
why should this and the -names entry exist, if <&label bit> is the only true way?
<mripard_>
what?
<mripard_>
clock-output-names is only here to provide sensible names, but in no way mandatory
<mripard_>
clock-names is here to identify which clock is which, with a local range
ricardocrudo has joined #linux-sunxi
<mripard_>
and the bitfields are just here to make clock-output-names work, and provide a safety net
<mripard_>
so that if the DT has a bogus value, we catch it instead of using it
<libv>
remove or add a name in between...
<mripard_>
and you have to modify the bitfield, but really, it's not related to clocks using clocks at all.
<mripard_>
we could just remove clock-output-names and the bitfields altogether
<mripard_>
but then you would probably go in a cluless rant about how we don't have shiny clock names and don't double check the clock ids we pass
<libv>
at least that would be a clear one-sided solution
<mripard_>
anyway, all that is not related at all to clocks using phandles, so I don't really know what's your point.
<libv>
it's a symptom that something is out of place
<mripard_>
hey, you know what? these patches have been posted, reviewed, and ended up merged
<mripard_>
where were you?
<mripard_>
I'm pretty happy with the current clocks bindings, it's consistent with pretty much every platforms, and other similar properties in the DT, so no, we're not going to chnage that, unless you have some real technical issues with it
<mripard_>
and no "phandles are hard" isn't one, neither is "I have to modify two files"
Andy-D has joined #linux-sunxi
<libv>
as i stated, there are a few ways to find these ahb clocking bits from within u-boot
<libv>
first is knowning clk@register_offset
<libv>
another is the compatibility string, which requires a chip id every time
<libv>
or strstr
<libv>
and yet another is taking every single nodes clock-output-names and search for the name of the necessary clock
nashwhat has joined #linux-sunxi
<mripard_>
yeah, and we surely don't have the chip id in u-boot...
<mripard_>
you don't need the clk@address, at all
<mripard_>
search by compatible, using libfdt
<mripard_>
lookup its phandle there
<mripard_>
put the phandle in your node
<mripard_>
job done.
<mripard_>
a single switch, 4 libfdt calls.
<mripard_>
definitely something bloated...
nashwhat_ has quit [Ping timeout: 264 seconds]
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<libv>
mripard_: all that so i can insert phandle, bit
<libv>
google is really not being helpful when looking for "device-tree clocks labels bits"
<libv>
anyway, let me send in patches as they are now, with our clk-driver deciding which clk bits to enable
<libv>
and then i'll go write up the uboot driven version, and see whether anyone likes that one better, or whether any alarm bells will start going of instead
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 245 seconds]
<libv>
i like that
<libv>
in a few years time, when this <&label bit> stuff is finally changed, there will be a nasty bit of code in u-boot that would need changing as well
Quarx has joined #linux-sunxi
enrico_ has joined #linux-sunxi
<mripard_>
libv: no, all that so that you can have a generic enough solution to cover all use-cases.
<mripard_>
and that won't change
<libv>
time will tell :)
<mripard_>
does that mean that I will also have the right to brag about how you were wrong in a few years?
nashwhat_ has quit [Ping timeout: 240 seconds]
nashwhat has joined #linux-sunxi
kz1 has joined #linux-sunxi
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
<libv>
mripard_: atomic modesetting is proving me right today, 9-10ys afterwards
<libv>
but yeah, feel free
<libv>
i am used to that
<kz1>
./fel reboot ????
<kz1>
possible?
nashwhat has quit [Ping timeout: 244 seconds]
nashwhat has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 244 seconds]
Quarx has quit [Remote host closed the connection]
Quarx has joined #linux-sunxi
Quarx has quit [Client Quit]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 264 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 240 seconds]
afaerber_ has joined #linux-sunxi
issue_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 272 seconds]
sehraf has quit [Ping timeout: 250 seconds]
Quarx has joined #linux-sunxi
notmart has quit [Quit: notmart terminated!]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 255 seconds]
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
sehraf has joined #linux-sunxi
FDCX has quit [Read error: Connection reset by peer]
ccaione has joined #linux-sunxi
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 255 seconds]
Andy-D has quit [Ping timeout: 256 seconds]
FDCX has joined #linux-sunxi
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 255 seconds]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
<paulk-collins>
god, is there a clean source to get ubuntu images? everything I see is on some free hosting websites…
<libv>
it's a faff, but it gets a simple desktop going
<paulk-collins>
regarding my discussion regarding media center hardware, I'll go with a cubox (imx6q) since it's upstream and is more likely to get GPU support soon (no offense libv)
<libv>
alip was really what we needed for most of our simple/testing use cases
<paulk-collins>
alip?
nashwhat_ has joined #linux-sunxi
<libv>
some linaro pre-built image with xfce
<paulk-collins>
ok
nashwhat has quit [Ping timeout: 244 seconds]
akaizen has joined #linux-sunxi
HeHoPMaJIeH has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
nashwhat has joined #linux-sunxi
akaizen has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 256 seconds]
akaizen has quit [Ping timeout: 240 seconds]
xavia has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 260 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 244 seconds]
deasy has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
nashwhat has quit [Ping timeout: 240 seconds]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 256 seconds]
libcg has quit [Ping timeout: 240 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 255 seconds]
heffer has quit [Read error: Connection reset by peer]
heffer has joined #linux-sunxi
heffer has quit [Changing host]
heffer has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 255 seconds]
bonbons has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
notmart has joined #linux-sunxi
nashwhat has joined #linux-sunxi
Andy-D has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 250 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 240 seconds]
diego_r has quit [Quit: Konversation terminated!]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 240 seconds]
bertrik has quit [Remote host closed the connection]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 240 seconds]
Andy-D has quit [Ping timeout: 255 seconds]
nashwhat has joined #linux-sunxi
issue_ has quit [Remote host closed the connection]