mnemoc changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
woprr has joined #linux-sunxi
VargaD has quit [Ping timeout: 260 seconds]
VargaD has joined #linux-sunxi
bertrik has quit [Remote host closed the connection]
popolon has quit [Quit: Quitte]
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
xavia has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<woprr> A20 HDMI-Audio Offset: 0x048: Aud_Ctrl: AUD_LAYOUT: PCM/1-bit Audio layout selection 3 R/W 0 layout 0 (2 chan
<woprr> this is HDMI, not S/PDIF, want to try 8ch default , IEC60958
<woprr> where's driver development actually going on, https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-devel is months behind?
<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
wingrime1 has joined #linux-sunxi
wingrime has quit [Ping timeout: 256 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 256 seconds]
nicksydney has quit [Remote host closed the connection]
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<woprr> using sunxi-devel
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<wens> libv: use the names listed in 'clock-output-names'
egbert has quit [Disconnected by services]
wingrime has quit [Ping timeout: 255 seconds]
egbert has joined #linux-sunxi
<wens> libv: ok, not sure what you want to do here...
wingrime has joined #linux-sunxi
fredy_ has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
wingrime has joined #linux-sunxi
GeertJohan_ has joined #linux-sunxi
fredy has quit [Ping timeout: 240 seconds]
GeertJohan has quit [Ping timeout: 240 seconds]
ccaione has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<Turl> woprr: the sending patches wiki page is for 3.4 / uboot-sunxi / sunxi-tools / ...
<woprr> thx
<Turl> woprr: the git instructions are mostly the same everywhere, but the dev at linux-sunxi.org list is for those I mentioned
<woprr> k
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<woprr> whats git complaining here: huh! an iobase starting at xxxxFFFF ?
<woprr> - .end = SW_PA_NANDFLASHC_IO_BASE + 0x1000,
<woprr> + .end = SW_PA_NANDFLASHC_IO_BASE + 0x0FFF,
<libv> wens: the names in clock-output-names don't work
<woprr> are you sure this is right?
<woprr> uh ending,ok
<libv> the sun6i code, claiming "ahb1_sdram", that cannot work
<libv> but because of the lack of error message, no-one ever found out :(
<woprr> glad to see I'm not the only one nearly failed math basics at school :D
<Turl> libv: pretty sure wens was the one that noticed that and fixed it
<libv> oh, so it was fixed already?
<Turl> are you using an ancient tree?
<libv> linus
<libv> 2ds old
<Turl> master? weird hm
<Turl> let me check
<libv> was there an email?
<libv> anyway, if "ahb1_sdram" works on sun6i, my code should work, yet it doesn't
akaizen has joined #linux-sunxi
<Turl> libv: it's not in torvalds, but mike's tree has it
<libv> aaah :)
<libv> register :)
<libv> okies :)
<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
<libv> wens: look at the dtsi
<wens> clocks = <&ahb>;
<libv> wens: it's really tough to get the right symbolic name out of all of those ones
<wens> that's why all of them have clock-output-names defined
<libv> Turl: i know
<Turl> libv: what do you mean by symbolic?
<libv> Turl: but how do you reach that?
<Turl> libv: how do you reach what?
<libv> in the dts files, you state <&ahb_gates 16>
<Turl> libv: yes, so?
<libv> ahb_gates no longer exists at boot time
<Turl> libv: eh?
<wens> why doesn't it?
<libv> those labels have been resolved.
<libv> clocks have gotten phandles by then
fredy_ is now known as fredy
<wens> i think the dt compiler takes care of that
<Turl> libv: so?
<libv> at leat, that is my understanding
<libv> dt compiler?
<libv> when does the dt compiler run?
<Turl> libv: when you make dtbs
<wens> at kernel compile time
fredy is now known as Guest94173
<libv> wens: great.
<libv> wens: perfect for when i, in u-boot, add a whole new noced
<libv> node even
<Turl> libv: can't you just access stuff by path in uboot?
<libv> simple-framebuffer is a whole new node
<Turl> let me take a look
<libv> Turl: that is unbelievably contrived, and very very fragile
<libv> it is possible
<libv> but is not sane
<wens> Turl: i think libv means it's hard to add a clock phandle to something he cannot describe properly
<libv> try finding <&ahb-gating 16> from /proc/device-tree/
<libv> manualluy
<wens> the other choice would be to match by full name, "clk@01c20060"
<libv> exactly!
<libv> you need to know the full fucking name
<libv> why do you then even need dt?
<libv> symbolic clock names just do not work from this end
<libv> they work from the other
<Turl> libv: you're the 1% :)
<libv> but not from the u-boot or .dtb side
<libv> Turl: this is not impossible to solve
<wens> i suppose we should rename the clk nodes to XXX_clk then
<libv> but, like with everything i encounter in my life, nobody every bothered to finish the thought
<libv> which is why i always get mc-nultied
<Turl> aliases exist for that
<Turl> uboot already uses to eg find the eth interface and set the mac address
<libv> Turl: aliases? where is this described?
<wens> at the top of the DT, in the aliases section
<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> yup
<libv> otherwise the would be no logic whatsoever
<libv> s/the/there/
<wens> so, no better than lookup by name
<libv> ?
<Turl> # grep ahb-gates /proc/device-tree/clocks/ -r
<Turl> /proc/device-tree/clocks/clk@01c20060/compatible:allwinner,sun5i-a10s-ahb-gates-clk
<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> Turl: you are de_fe0
<libv> what is the clock that gives you your bus?
<Turl> ahb_de_fe0?
<libv> Turl: bingo.
<libv> Turl: how do you enable that?
<libv> "oh."
<Turl> clk = clk_get(..., "bus"); clk_prepare_enable(clk)
<wens> you either get by index (to the clocks tied to the node), or by name (and have clock-names defined for that node)
<wens> depends on what the dt binding is
<libv> Turl: what if the bit for ahb_de_fe0 is something else entirely on sun6 versus sun4i?
<libv> how would you deal with that?
<Turl> libv: then you just use the right value in the dt
<libv> how?
<libv> you describe every single clock bit in every node?
<Turl> by changing the clocks =... on your node
<libv> ok, so you need a full copy of the full display engine _every_ time?
<Turl> wat?
<libv> and each and every time you list <&ahb_gating whatever_bit_works_for_this_version_of_the_other_otherwise_unrelated_part_of_the_soc>
<libv> instead of stating "ahb_de_fe0"
<libv> _everywhere_
<wens> what happened to the dt writer has the datasheet to look at
<Turl> libv: what if a new shiny soc shows up with two display engines? you suddenly have ahb_de[01]_fe0 and need to change too
<libv> why do you even need to have clock-output-names?
<libv> Turl: sure
<Turl> libv: you don't, it's optional
<libv> Turl: so do you want to change this every 5 engine revisions?
<libv> or every single SoC version?
<libv> Turl: you mean s/optional/unsided, but otherwise useless/
<Turl> unsided?
<libv> onesided, sorry
<libv> clock-output-names is only used by clk-sunxi.c
<libv> where it is treated as fully unique
<libv> and very descriptive
ccaione has quit [*.net *.split]
<libv> but the .dts is not allowed to treat it like that, and as a result, the dtb and u-boot cannot treat it like that either
<libv> this is a serious unfinished though
<libv> thought
<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> that makes much more sense
<libv> now we have both.
<libv> clock references use <&label bit>
<libv> clocks themselves list names
<libv> clk-sunxi matches the names to the bits, but in such a way that the .dts list must match the bits in that exact order
<libv> change the dts, the matches break
<libv> chance the driver, the matches break
<libv> change even
<wens> Turl: maybe we should add clock-indices, even if the driver doesn't use it?
<libv> it's intuitively wrong
<wens> afaik of_clk_get_parent_name uses it, even though we don't use it on any of the gates
<libv> if you think it through, it just feels wrong
<libv> from ever angle
<libv> i am truly amazed that i have to defend this here
<libv> it reeks of wrongness
<libv> yet i seem isolated with that view
<Turl> wens: those are pretty hard on the eyes
<Turl> wens: and it kind of contradicts with the block before that said it was domain specific
<wens> Turl: that i agree, but they aren't for the eyes
<Gerwin_J> current bid on a80 board in auction is now 1799 yuan (291 usd)
<Turl> Gerwin_J: they can keep it :p
<libv> Turl: there is no way that anyone logical can keep on arguing against symbolic names for clocks
<wens> libv: i don't think the binding is going to change though :(
<Gerwin_J> WITS sell optimus board for 2000 yuan
<wens> the binding also states "Clock consumer nodes must never directly reference the provider's clock-output-names property." :|
<libv> wens: why not>
<wens> Gerwin_J: i'm not even going to look at it
<Turl> libv: they're a pain to maintain
<libv> wens: why is <&label bit> so much better?
<libv> what does <&label bit> gain anyone?
<wens> libv: i'm not saying it's better, i'm saying what Turl is saying
<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?
<Gerwin_J> Turl "This is the first launch of a large 8-core A80 OptimusBoard development board" http://mp.weixin.qq.com/s?__biz=MjM5MTc1NzI3MQ==&mid=204004428&idx=1&sn=8ae9961af9fc987a349bb4eb3e3bd048#rd auctions rules
<libv> Turl: it's clocks?
<libv> Turl: how often does one go and discover clocks?
<libv> Turl: but if one needs to speed it up, sure
<libv> Turl: it's still better.
<libv> especially since this is a low frequency operation
<Turl> libv: probe time
<libv> Turl: negligable
<Turl> libv: dt compile time
<Turl> uboot :)
<libv> even more negligable
<libv> uboot?
<libv> in the case of ahb_de_fe0?
<libv> inverse.
<Turl> the whole discussion steamed from it
<libv> do you have any idea how many lines of code i would have had to write in this case?
<libv> only to know that a single minute change would throw it all off?
<libv> and that i would need to first check a chip id before even attempting to find the right clk?
<libv> apb1_gates: clk@01c2006c {
<Turl> libv: like two lines, find node, update reg
<libv> compatible = "allwinner,sun7i-a20-apb1-gates-clk";
<Turl> you'll need the node anyway for kms
<Gerwin_J> but auction is now closed. highest bid by MR Leung, 2300 yuan (372 usd) for one A80 optimus board
<libv> err, wrong one
<libv> ahb_gates: clk@01c20060 {
<libv> compatible = "allwinner,sun7i-a20-ahb-gates-clk";
<libv> that's the one i would need to look for
<wens> how different are the ahb gates for de on sun4/5/7i anyway
<libv> wens: not at all
<libv> wens: but thanks to the wonders of dt...
<libv> they are different though
<wens> so it's just the difficulty of looking up the dt node
<libv> but not relevant for me
<libv> wens: how?
<libv> wens: by register address?
<wens> i meant for the uboot code you're writing
<libv> by checking every compatible section for "ahb-gates"
<wens> to update the dt
<libv> as a substring
<Turl> libv: pretty sure the gates are always in the same place for all the socs
<libv> and what if that compatible string changes?
<libv> Turl: they are
<Turl> so hunt for the node name
<libv> Turl: what node names?
<wens> clk@01c200XX
<libv> Turl: clk@addr?
<Turl> this is all moot though since you could've the node written already and let dtc handle all this
<Turl> libv: ya
<libv> really?
<libv> that's laughable
<libv> why even have dt?
<libv> why bother?
<libv> why not just program directly?
<libv> honestly, if you need to know register address and bit numbers all the time
<libv> why bother with dt?
<Turl> libv: these whole issue stems from you trying to insert a node that's not actually saying anything about the hardware in the first place
<Turl> it's not your fault though, it's simple-framebuffer's
<woprr> * sunxi-devel
<woprr> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sunxi_defconfig
<Turl> bbl, my food it's going to go all cold if I don't eat it
<woprr> $ grep -i stub .config
<woprr> $
nicksydney has joined #linux-sunxi
<woprr> grep SND_SUNXI_SOC_HDMIAUDIO .config
<woprr> $ grep -i HDMI .config
<woprr> CONFIG_SND_SOC_HDMI_CODEC=y
<woprr> ?
<woprr> this does not look like a sunxi kernel
<wens> you should use sunxi-3.4 for that
<woprr> ../stage ?
<wens> please explain what do you want to do?
<woprr> what is sunxi-next, integrators playground?
<wens> sunxi-next is whatever is going into the next mainline kernel release
<woprr> extending the hdmi audio driver for 8ch IEC60958
<wens> there is no hdmi audio driver for sunxi in mainline
<woprr> no
<woprr> where are new drivers/patches going?
<wens> mainline, i.e. 3.16, 3.17
rz2k has joined #linux-sunxi
<Turl> woprr: mainline mail lists, maintainer trees, linus torvalds
<wens> you can also send patches for sunxi-3.4
<woprr> this is a sunxi platform driver, mainline ?????
<wens> woprr: what did you base your work on?
<wens> Turl: aren't you eating? :p
<Turl> wens: reheating :p it was all cold
<woprr> how i can i base when i not know on what branch to base ?
<Turl> woprr: let's start again
<Turl> what are you trying to do?
<woprr> 3.4 running here
<woprr> extending the hdmi audio driver for 8ch IEC60958
<Turl> woprr: ok, so base on sunxi-3.4 from linux-sunxi
<wens> woprr: base your work on sunxi-3.4
<Turl> and submit patches following Submitting_patches wiki page
<wens> what Turl said
<woprr> are you sure? for tsc driver stage/sunxi-3.4 was advised by PL in 2013
Gerwin_J has quit [Quit: Gerwin_J]
<Turl> woprr: they are very close to each other
<Turl> use stage/sunxi-3.4 if you want
<woprr> not the question what i want, where do you want it
<libv> Turl: about inserting those nodes...
<woprr> ok using stage/sunxi-3.4
<libv> Turl: it wouldn't be a problem if clocks were referenced by name
<libv> Turl: also, .dts files would be more modular
<libv> you'd just change register range base addresses and sizes
<libv> and then list names for the dependencies
<libv> not <&label bit>
<libv> as those bits are very prone to moving
<libv> more than addresses
<Turl> you keep on saying label bit and I haven't corrected you yet :p
<Turl> there's like a handful of clocks using label bit only
<Turl> fingerful? whatever :)
<libv> every one that depends on ahb_
<libv> which is every engine
<libv> every engine has a bit
<Turl> anyway
<wens> are you supposed to tie all the engines to one driver instance?
<libv> grep "<&ahb_gates " arch/arm/boot/dts/sun7i-a20.dtsi | wc
<libv> 16!
<libv> today!
<libv> no mali, no cedar, no disp
<wens> no audio either
<libv> we need names there
<libv> not bit definitions
<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
<libv> Turl: and then i add an lcd with different timing?
<libv> and suddenly need 2 more clocks?
<Turl> an even better idea would be to have a chosen node specifying all this stuff, but well, rpi :p
<libv> rpi ignores all of this
<libv> Turl: it would work, if we had names for clock
<libv> it would be easy then
<libv> there is nothing that speaks against it
<libv> nothing that the dt compiler cannot easily catch
<Turl> libv: what happens with the lcd?
<libv> Turl: we would suddenly add a second simplefb
<libv> or....
<Turl> it's just a random binding I invented, a real one would probably look different, with subnodes for each output or stuff
<libv> we have the scaler handle things for us
<libv> and we suddenly have the same framebuffer memory location and layout
<Turl> you could have different subnodes compatible with simplefb and each with their own fb
<libv> just need 2 more ahb bits
<Turl> and then kms can take over them graciously
<libv> Turl: your original idea was to add some code to the simplfb driver
<Turl> libv: yes
<libv> to claim the clocks
<Turl> maybe I'm not making myself fully clear
<Turl> the idea would be to have the binding kms would use
<libv> uboot declares the clocks it used
<Turl> with all the resources
<libv> all of them?
<libv> even the ones you do not need?
<libv> the clocks that could be disabled?
<libv> how would you tell userspace which clocks are used and which aren't?
<Turl> why would userspace care?
<libv> it does
<libv> why else would i be messing with this?
<Turl> you mean kernelspace?
<libv> why not just leave all clocks on per default?
<libv> err. yes
<libv> kernelspace
<Turl> makes more sense now :)
wingrime has quit [Read error: Connection reset by peer]
<Turl> 1s
wingrime1 has joined #linux-sunxi
<libv> Turl: why is there this rule that clocks must be described as <&label bit>
<libv> Turl: why is kernelspace using "name" almost exclusively?
<libv> this is a pretty fundamental inconcistency
<libv> Turl: nope
<libv> Turl: scaler would hand out one fb
<Turl> libv: because it's easier to use the bit than dying counting names on a list
<libv> hdmi would scale it up from 800x480 to hdmi res
<Turl> libv: and no, the kernel hardly ever uses name. There's like 1 case of name usage, and it's the clock protection stuff
<libv> Turl: which we do
<libv> Turl: that's what i intuitively f-ed up first time round
<libv> bit masks
<libv> to match the list in the dtsi to the actual bits
<Turl> libv: you needn't look at the clock driver to use clocks
<Turl> you need to read the user manual
<libv> you need to look at the clock datasheet
<libv> and know which bit exactlty
<libv> Turl: so why have names at all?
* libv runs the same circle again
<libv> Turl: which this need to match a bit with a name?
<Turl> libv: you can tell I don't know anything about video engines looking at the crap binding I wrote, but you get the idea I hope
<libv> Turl: simplefb is just about describing a framebuffer
<Turl> libv: the names are just for debugging, cat debugfs/clk/clk_summary
<libv> a framebuffer is just some memory
<Turl> libv: a framebuffer is an extraneous concept in dt, as it's not hardware
<libv> we can show the same memory on any display "pipe"
<Turl> it'd be way more suitable in a chosen node
<libv> if the scaler(s), serializer(s_ and encoder(s) are all set up correctly
<Turl> (chosen nodes are the stuff used to pass configuration values from the bootloader, like cmdline)
<libv> we could show any mode using just ahb_de_be0, ahb_lcd0 and ahb_hdmi
<libv> but... in case we want 1024x768 on hdmi and 800x480 on lcd... we might need ahb_de_be0, ahb_lcd0, ahb_de_fe1, ahb_de_be1, ahb_lcd1, ahb_hdmi
<libv> and then probably some pwm stuff
<libv> simplefb shouldn't need to know more than that
<libv> fb layout, and a list of clocks (which we could also handle in the clk driver)
<libv> this list of clocks is pretty dynamic
<libv> and it depends on what the uboot display code thought it needed
<libv> all the other clocks need to be disabled
<Turl> you could mark them all IGNORE_UNUSED
<libv> since the driver lives in uboot, it is the entity that knows what is used and what is not
<Turl> so you won't end up with them always enabled, they'll just be left aside
<Turl> but it's as ugly a solution
<libv> the clean solution is to have sensible clock naming in devicetree
<libv> this solves a logical inconsistency with our clk-sunxi driver
<libv> and gives uboot an easy and logical time
<libv> and actually abstracts hardware in a sensible way!
<libv> clk driver needs to know about bits, everyone just needs to state that they need their bus turned on
<libv> everyone else even
<wens> imho the kernel should not depend on the bootloader doing stuff
<libv> wens: that means, no simplefb driver
<wens> i suppose so
<libv> Turl: what i propose is much much cleaner
<libv> and it makes more conceptual sense
<libv> 3.5h
<libv> honestly
<Turl> and I'm giving you a bandaid concept which is more power efficient than the bandaid you got yourself
wingrime has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
<Turl> libv: I got like half the story but missed your point :)
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<Turl> make that a :(
<Turl> libv: anyway, let's discuss with some rest and code in hand later tomorrow :)
<Turl> going in circles won't get us much
<Turl> someone beat me to it
HeHoPMaJIeH has joined #linux-sunxi
<Turl> gnite
sehraf has joined #linux-sunxi
sehraf has quit [Client Quit]
sehraf has joined #linux-sunxi
kivutar has joined #linux-sunxi
xavia has quit [Quit: Leaving.]
wingrime has quit [Ping timeout: 245 seconds]
ccaione has joined #linux-sunxi
ccaione has quit [Ping timeout: 245 seconds]
ccaione has quit [Changing host]
ccaione has joined #linux-sunxi
wingrime has joined #linux-sunxi
diego_r has joined #linux-sunxi
libcg has joined #linux-sunxi
ccaione has quit [Ping timeout: 245 seconds]
diego_r has quit [Ping timeout: 245 seconds]
diego_ has joined #linux-sunxi
diego_ is now known as diego_r
ccaione has joined #linux-sunxi
avsm has joined #linux-sunxi
avsm has quit [Client Quit]
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 272 seconds]
nicksydney has joined #linux-sunxi
nicksydney_ has quit [Ping timeout: 252 seconds]
benn` has joined #linux-sunxi
deasy has joined #linux-sunxi
Quarx has quit [Ping timeout: 250 seconds]
FR^2 has joined #linux-sunxi
Quarx has joined #linux-sunxi
<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]
nashwhat has joined #linux-sunxi
HeHoPMaJIeH has quit [Ping timeout: 255 seconds]
nashwhat_ has quit [Ping timeout: 264 seconds]
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
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…
akaizen has quit [Ping timeout: 240 seconds]
<libv> paulk-collins: this is what i ended up doing: http://linux-sunxi.org/User:Libv#Installation
<libv> to be able to replace linaro alip
<paulk-collins> yay
<paulk-collins> thanks a lot once again libv
<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]
nashwhat_ has quit [Ping timeout: 260 seconds]
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 245 seconds]
nashwhat_ has quit [Read error: Connection reset by peer]
nashwhat has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 264 seconds]
FR^2 has quit [Quit: Connection reset by peer]
Gerwin_J has joined #linux-sunxi
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 260 seconds]
notmart has quit [Quit: notmart terminated!]
<Turl> cool, gnome disks has a graphical dd :p
rz2k has quit []
nashwhat_ has joined #linux-sunxi
bgal has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
netlynx has joined #linux-sunxi
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 240 seconds]
nashwhat_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 250 seconds]
avsm has joined #linux-sunxi
nashwhat_ has quit [Read error: Connection reset by peer]
nashwhat has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<montjoie[home]> stress testing Security System... making 1024 update() of 1 byte
nashwhat_ has joined #linux-sunxi
avsm has quit [Quit: Leaving.]
nashwhat has quit [Ping timeout: 255 seconds]
ricardocrudo has quit [Ping timeout: 240 seconds]
bgal has quit [Remote host closed the connection]
nashwhat has joined #linux-sunxi
nashwhat_ has quit [Ping timeout: 256 seconds]
nashwhat_ has joined #linux-sunxi
issue_ has joined #linux-sunxi
nashwhat has quit [Ping timeout: 245 seconds]
ricardocrudo has joined #linux-sunxi
programtruck has joined #linux-sunxi
<programtruck> hi
<programtruck> I have a Question that if Allwinner A20 supports OpenMAX or not ?
<programtruck> Folks
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
ricardocrudo has quit [Remote host closed the connection]
leviathanch2 has quit [Ping timeout: 240 seconds]
avsm has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
programtruck has quit [Quit: Leaving]
ecelis has quit [Remote host closed the connection]
netlynx has quit [Quit: Leaving]
ecelis has joined #linux-sunxi
yann_s has quit [Quit: ZNC - http://znc.in]
sehraf has quit [Read error: Connection reset by peer]
paulk-collins has quit [Quit: Ex-Chat]
kivutar has quit [Quit: Ex-Chat]
avsm has quit [Quit: Leaving.]
nabblet has joined #linux-sunxi
boycottg00gle has joined #linux-sunxi
xavia has quit [Quit: Leaving.]
bonbons has quit [Quit: Leaving]
afaerber_ is now known as afaerber
avsm has joined #linux-sunxi
avsm has quit [Quit: Leaving.]
boycottg00gle has quit [Remote host closed the connection]
popolon has quit [Quit: Quitte]