<mripard_>
n01: keep in mind that you have to merge such an amount of patches only because you need the clocks
<mripard_>
once the clock will be there, you will be able to just use the last rc
<n01>
yep, at the moment what I need is a working kernel with dt support to test my patches
<mripard_>
then, take 3.9-rc1
<mripard_>
if you don't need the clocks, you don't need more
<n01>
yeah, yesterday in despair I worked on 3.9-rc5 and it seemed good :)
<mripard_>
well, yes, basicall every 3.9-rc would work :)
<oliv3r>
n01: doesn't the wdt require the clocks?
<oliv3r>
i actually found one example for the sid that setup some form of clocks, but I highly doubt any clocks are needed to read the registers i need to read
<oliv3r>
though i'm struggling mostly with sysfs atm :)
<oliv3r>
was reading chappter 14 of ldd3 (and boy is that a long chapter and tries to explain the innards)
slash_m_a_x has joined #linux-sunxi
<n01>
oliv3r: yes, I just assume that the clock is correctly configured even in 3.9-rcX
slash_m_a_x has quit [Client Quit]
hipboi has joined #linux-sunxi
<oliv3r>
n01: never assume anything :p
<oliv3r>
n01: but i don't know how dt, clocks and the wdt hang together. who inits the clocks, what does the wdt require; i don't know :(
<n01>
actually wdt requires OSC24M, I hope it is enabled :D anyway I'll check
<mripard_>
of course it's enabled :)
<mripard_>
and we're using the watchdog to reboot
<mripard_>
so I think you won't need anything fancy
<hipboi>
mripard_, how is the a31 kernel going now
<hipboi>
mripard_, i can test it
<mripard_>
hipboi: didn't have time to make progress on it, I'm sorry :(
<hipboi>
mripard_, it's ok, i will look at it
<mripard_>
If you know device tree, it should not be much complicated than creating a dumb dts that inherits from sun6i.dtsi
<mripard_>
that is already there
simosx_ has joined #linux-sunxi
simosx_ is now known as simosx
simosx has quit [Client Quit]
simosx has joined #linux-sunxi
simosx has joined #linux-sunxi
<Turl>
n01: that's the main oscillator :) if that's disabled either your board is off or you did some magical vodoo which is not yet implemented :p
<n01>
lol ok ok, I wasn't concerned about OSC not working _at all_, but eventually on its precision :D please be easy on me :P
<Turl>
n01: how's the watchdog driver going? :)
<n01>
Turl: it's finished actually but I have to test it
<Turl>
n01: you should be able to drop the pr_fmt macro
<n01>
yep, it needs cleanup
<n01>
:D but every comment is welcome
<mripard_>
n01: it looks good :)
<n01>
I'm not sure about reading the register before writing it again ... I always do that even though I don't know if it is really usefull or just waste of time
<n01>
mripard_: thank you :)))
<n01>
I need also to add hno in authors, sorry for that
<mripard_>
n01: also, add the licence on top
<n01>
ok
<Turl>
according to the docs, the control register has some reserved bits that are not zero, so reading it isn't that bad of an idea
<n01>
yeah I had the same thought
<Turl>
mode looks like you can write directly
<mripard_>
n01: I have a few comments, as usual, but I guess you can send it
<mripard_>
it's good enough now :)
<n01>
yes, I'll send it to ml
<n01>
ASAP I test it a bit
<Turl>
it's way more readable now that it's using the watchdog framework
<Turl>
way less boilerplate code
<Turl>
n01, mripard_: the compatible string should be sun4i now, shouldn't it?
<mripard_>
yep
<n01>
yes, but that code is based on 3.9-rc5 where IIRC it was still sunxi
<mripard_>
it doesn't really matter actually
<mripard_>
as long as it's the same in the dt node and in the driver, it just works
<mripard_>
aaah, but I was already using this compatible
<mripard_>
right
<mripard_>
nevermind :)
<Turl>
yeah the node is already mainlined :)
<Turl>
and I think you renamed it to sun4i with the arch rework
<mripard_>
yes, but it will be renamed in 3.10
<oliv3r>
what will be the final name?
<Turl>
oliv3r: allwinner,sun4i-wdt
<oliv3r>
ok, good
<oliv3r>
n01: also, PERSONALLY! (i think mripard_ doesn't care and says use whatever :p nofi) ioread*/iowrite* should be prefered over read*/write*. ioread DOES eventually call read* and write* anyway. See http://lxr.free-electrons.com/source/lib/iomap.c?a=arm#L112
<oliv3r>
the wdt, is that concidered a 'platform' device?
<mripard_>
oliv3r: it is
<oliv3r>
and a PCI device bus, would plug into the platform then aswell?
<oliv3r>
or is the PCI bus the 'top' next to the platform device?
<mripard_>
the pci bus master yes
<oliv3r>
what does platform fall under then?
<oliv3r>
or is that the top? (I would assume so)
<mripard_>
platform devices is basically every device that are directly mapped in memory
<oliv3r>
kk
<n01>
oliv3r: I agree even though I think in this case ioread*==read* ... But I'll change it
<oliv3r>
mripard_: btw lxr.free-electrons.com is your handywork? I've used it a LOT latly :)
<oliv3r>
n01: i think ioread does some checks before calling read or something
<oliv3r>
n01: i know nothing how the kernel interacts with watchdog devices etc, but can a user do anything with it? And how is that normally handled by others? E.g. if i want to change the wdt timeout value. Module paramter? Sysfs?
<mripard_>
oliv3r: it's just an instance that we host
<mripard_>
we don't develop lxr
<mripard_>
but we use it all the time, so we host one :
<mripard_>
oliv3r: usually, it's to the user to kick on a regular basis the watchdog
<mripard_>
and iirc, it's done using a device file
<oliv3r>
ah, google always puts yours ontop :)
<oliv3r>
mripard_: ah ok didn't see that in the code
<Turl>
usually you have an userspace daemon that arms it, configures the interval and then kicks it
<Turl>
busybox has an implementation you can use
<oliv3r>
yeah, I figured as much; so a userspace program constantly 'wakes' the watchdog (or resets it or something)
<oliv3r>
but didn't see anything in n01 's code. Just the heartbeat time, which will be the amount of time the watchdog has to be kicked
<oliv3r>
or does the 'watchdog framework' handle all that? that would actually make sense ;)
<oliv3r>
watchdog_register_device();
<oliv3r>
nevermind; i did nto say a thing
<oliv3r>
hmm, i still don't understand; the wdt is registered by watchdog_register, but it still is a platform_device?
<oliv3r>
a little confusing, but I guess I get it :p
<mripard_>
oliv3r: there's two thing to conider when writing a driver
<mripard_>
what type of device it is and what bus it's on
<mripard_>
platform_device states that it's on the "memory" bus
<mripard_>
while watchdog_register_device states that your driver is for a watchdog
<mripard_>
a watchdog over i2c would still call watchdog_register_device
<mripard_>
but it would be an i2c_device instead of a platform device
<oliv3r>
ah of course
<oliv3r>
just trying to put things together; still have to let chapter 14 sink in :)
<oliv3r>
just so much to learn and know :(
hipboi has quit [Quit: Leaving]
<oliv3r>
n01: mripard_ ok, if I understand the watchdog timer correctly (though this is a more general question), you define a pointer for iomap, that takes the exact same structure as the register layout. Thus when accessing the pointer, you are really accessing the registers directly. Rule is however, you can only read or write to them using the ioread*/iowrite* calls?
<oliv3r>
allthough that structure mapping need not be, its only to easy access to the registers.
<mripard_>
hmmm, there's several different things in your queestion
<mripard_>
iomap maps a physical address to a virtual one, so that you can access it
<mripard_>
you could very well access it using a volatile pointer
<oliv3r>
of_iomap(); i speak of
<oliv3r>
so if you have only 1 register, or a series of registers (continous) you could just map 1 volatile pointer to the first element
<mripard_>
except that is has several drawbacks, the main one being that you have to do all the barriers and such by yourself
<oliv3r>
and just use offsets to go through it
<oliv3r>
or, define a structure, to match the layout of the registers you are accessing, and thus have easy access to exactly where you want to be
<oliv3r>
e.g. wdt_reg
<mripard_>
this is also why you usually don't use a structure, because there's no way to specify a barrier, or an endianness conversion, etc.
<oliv3r>
mripard_: i don't follow
<oliv3r>
i see lots of structures mapping to the registers
<mripard_>
where?
<mripard_>
in allwinner code, yes
<mripard_>
in mainline, not so much
<oliv3r>
wdt_reg :p
<oliv3r>
do you have a nice example to follow in mainline?
tinti has joined #linux-sunxi
<mripard_>
hmmm, you're right, n01 did that wrong :)
<oliv3r>
oh, i quite liked his approach :p
<n01>
sorry I was at lunch
<oliv3r>
so pointer to register + offset is better
<oliv3r>
like I did before?
<mripard_>
he's accessing every pointer twice
<mripard_>
hmmm, no, revermind
<n01>
mripard_: sooo, no struct but base + offset?
<n01>
isn't it the same?
<mripard_>
in your case, it's not so different
<mripard_>
precisely because you use your struct only to store the addresses
<mripard_>
you never write directly to the struct
<mripard_>
which is good, but it makes no difference from using offsets :)
<n01>
I use the struct only to easily get the register _address_
<mripard_>
yes
<n01>
:) good
<mripard_>
well, that's what you currently do
rz2k has joined #linux-sunxi
<mripard_>
what i meant is, the structure in itself already defines the offset
<mripard_>
so it makes *no* difference with using defined offsets, we agree on that
<n01>
yes
<mripard_>
the only thing I'm concerned is that it's not really consistent with what every other driver makes in mainline
<mnemoc>
Tsvetan was just told by eva the A20 has gmac.... and after checking the a20-dev branch, there is both emac and gmac drivers with sun7i specific changes
<oliv3r>
mnemoc: what does that mean?
<oliv3r>
it doesn't have pins for both; but the pins (that I saw int he olimex stuff) clearly stated gmac (and no emac)
<oliv3r>
dual personality pins? emac and gmac? or maybe they made two drivers :p
<techn__>
Turl: havent tested that. But seems really good improvement :)
Undertasker has left #linux-sunxi [#linux-sunxi]
wingrime has joined #linux-sunxi
<wingrime>
possible buy cubie-board for btc
<wingrime>
?
<n01>
lol ok guys I have some small problem with the watchdog :DD it seems it needs a bit more testing :P
shineworld has quit [Quit: Leaving]
<wingrime>
?
<wingrime>
what problem?
<wingrime>
your wd have reset support?
<n01>
wingrime: I'm investigating but it seems my driver does not correctly set the timeout. start->set timeout = 5 s->first kick-> and after a couple of seconds -> reboot
san has quit [Quit: Leaving]
<mnemoc>
any comment regarding regressor/alexandr shutko's IR driver?
<vinifm>
because i saw something in cubieboard forum
<vinifm>
about IR support
<techn__>
those are same dribver
<techn__>
*driver
<techn__>
same base address
<techn__>
but other one uses rc_register_device and other input_register_device
tinti has quit [Quit: Leaving]
<n01>
gosh hipboi|cubie: the next cubie with a poweron/off button please :D
<mnemoc>
n01: the current has it too
<mnemoc>
but userspace is usually not configured to poweroff on simple press
<n01>
ok, I need to configure it then
<oliv3r>
my Dlink router has a (light) switch on the power line (after the wall wart) it loosk really funny, like turning a light on/off (it's always on)
paulk-desktop has quit [Quit: Ex-Chat]
<mnemoc>
n01: poweroff by command line and then you can turn it on by pressing the power button