Keziolio has quit [Read error: Connection reset by peer]
DonkeyHotei has quit [Quit: This is a /quit message.]
DonkeyHotei has joined #linux-sunxi
sunshavi has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<wens>
[TheBug]: if the intended target is mainline, then you should send it to mainline MLs, specifying where/what it applies to (even inflight patches are ok)
diego71 has quit [Ping timeout: 240 seconds]
ninolein has quit [Ping timeout: 265 seconds]
ninolein has joined #linux-sunxi
ech0_42 has joined #linux-sunxi
junnie_ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 240 seconds]
leviathancn has quit [Ping timeout: 255 seconds]
nuuuciano has joined #linux-sunxi
<willmore>
MicroJoe, you could put the code up on a GIST so that it could be found if you go missing.
cnxsoft has quit [Read error: Connection reset by peer]
<swiftgeek>
is any DT modification required?
<swiftgeek>
( for uboot )
cnxsoft has joined #linux-sunxi
f0xx has joined #linux-sunxi
<swiftgeek>
oh i see
<swiftgeek>
mmc2_pins* is missing on a33
IgorPec has joined #linux-sunxi
junnie_ has quit [Ping timeout: 240 seconds]
junnie_ has joined #linux-sunxi
<swiftgeek>
just to clarify - device has bga169 pads
tllim has quit [Read error: Connection reset by peer]
tllim has joined #linux-sunxi
<swiftgeek>
so mmc2 and mmc2_clk is missing too
valkyr1e has joined #linux-sunxi
<swiftgeek>
not sure what reg = <0x01c11000 0x1000>; and similar for mmc2_clk is A31 example
<swiftgeek>
ah value from memory mapping
scream has joined #linux-sunxi
<swiftgeek>
ok so mmc@01c11000 doesn't change for A33
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 252 seconds]
diego_ has joined #linux-sunxi
diego_ is now known as diego71
dave0x6d has quit [Quit: Connection closed for inactivity]
Mr__Anderson has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
tl_lim has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
tl_lim has quit [Read error: Connection reset by peer]
guest11111 has joined #linux-sunxi
<guest11111>
hi
<guest11111>
I'm trying to write ethernet gmac driver and I'm wondering how can I determine two things in GMAC_MII_CMD register
<guest11111>
first one - what clock divide ratio should I ust for MDC clock generation
<guest11111>
second one - how to determine physical address of ethernet PHY in R40?
<wens>
look at the schematic? or try all addresses and see which one responds?
jonkerj_ has quit [Read error: Connection reset by peer]
jonkerj has joined #linux-sunxi
<guest11111>
ok, I could try all the addresses but first I need to set proper clock divide ratio I think
<guest11111>
I just don't know what is the frequency of AHB clock
test has joined #linux-sunxi
test is now known as Guest40181
jonkerj has quit [Quit: recolocating~]
Andy-D has joined #linux-sunxi
ernestask has joined #linux-sunxi
muvlon_ has joined #linux-sunxi
DullTube has joined #linux-sunxi
msimpson has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
<apritzel>
guest11111: why do you want to create a new MAC driver in the first place?
<apritzel>
guest11111: and /sys/kernel/debug/clk/clk_summary is your friend when it comes to learning frequencies of clocks
<apritzel>
guest11111: given you are doing this on a recent Linux, otherwise you would need to read the respective PLL register and decode it yourself
dlan has quit [Ping timeout: 252 seconds]
<wens>
maybe it's for non-Linux OS :)
JohnDoe_71Rus has joined #linux-sunxi
dlan has joined #linux-sunxi
dlan has quit [Changing host]
dlan has joined #linux-sunxi
<guest11111>
apritzel: I want to write it just for achieving some new experience in low-level programming area
jonkerj has joined #linux-sunxi
<guest11111>
apritzel: ok, thanks for suggestions
elros_ has joined #linux-sunxi
lemonzest has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
Guest40181 has quit [Ping timeout: 260 seconds]
Andy-D has quit [Ping timeout: 248 seconds]
muvlon_ has quit [Quit: Leaving]
guest11111 has quit [Quit: Page closed]
junnie_ has quit [Ping timeout: 248 seconds]
yann has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 240 seconds]
leviathancn has joined #linux-sunxi
enrico_ has joined #linux-sunxi
delwin_ has joined #linux-sunxi
<delwin_>
heya folks. anyone familiar with the AllWinner A64 (A53 core) device and SPI interface?
<delwin_>
it's giving me a run for my money
pgreco has joined #linux-sunxi
mossroy has joined #linux-sunxi
pgreco has quit [Quit: Leaving.]
NiteHawk has quit [Ping timeout: 240 seconds]
pgreco has joined #linux-sunxi
<beeble>
delwin_: being a bit more specific usually helps due the async nature of discussion here
NiteHawk has joined #linux-sunxi
<apritzel>
delwin_: as beeble said: what's the exact issue?
<delwin_>
sure. I'm having trouble with the AllWinner A64 chip on the BananPi M64 board. The BSP comes with a spidev module which provides a /dev/spidev1.0 device. I'm not seeing a /dev/spi0 device which I've seen on older boards. My understanding is the spidev is a SPI device interface. So my question is: Is spidev1.0 both a device and master interface. Or am I missing my master interface.
<delwin_>
I've loaded spi_sunxi in an effort to see if it addresses this. No change.
<delwin_>
Ultimately I'd like to get a raspberryPi TFT SPI screen going on the board. First step is SPI
reinforce has joined #linux-sunxi
<beeble>
spidev is the linux userspace abi for spi. you want to have video output on the tft (as in framebuffer)?
<delwin_>
yeah
<beeble>
in that case you want a kerneldriver for the display that is using the spi kernel driver. spidev is not used at all in that setup
cnxsoft has quit [Quit: cnxsoft]
<icenowy[m]>
KotCzarny: it seems interesting that now the BSP cpufreq driver will match the dvfs table from the soc bin
<delwin_>
I see. thanks beeble. I have a fbtft_device kernel driver which loads the driver for my display (fb_ili9486.ko). When I try and load this, I get an SPI err in dmesg: spidev spi1.0 50000kHz 8 bits mode=0x00; spi_busnum_to_master(0) returned NULL
<KotCzarny>
icenowy: now? for h6 or some new source code?
<beeble>
delwin_: drivers/staging/fbtft
<icenowy[m]>
and for H6 the "slow bin" will need 1.16V to reach 1800MHz, but other two bins only 1.1V
<beeble>
delwin_: ok, so you figured that already out
<delwin_>
yeah. whats up with spi1.0 ?
<KotCzarny>
icenowy: i wonder if h2/h3/h5 also has bin info encoded, care to ask aw?
<delwin_>
I figured from this error msg that it's trying to use spi1.0. I'm still trouble shooting bu thought I'd turn to irc to ask if my understanding is correct before I continue down this rabbit hole.
<beeble>
delwin_: i guess it tries to bind it to a nonexisting spi interface. did you configure your dts? (enable spi, having the display as node of the spi controller)
<delwin_>
no, I have not. TBH I've not worked with DTS much and am just wrapping my head around it. Do you know of a spi dts for this device?
<beeble>
delwin_: also, which kernel version?
<delwin_>
Kernel: 3.10.105-BPI-M64-Kernel
mail__ has joined #linux-sunxi
mail__ has left #linux-sunxi [#linux-sunxi]
delwin_ has left #linux-sunxi [#linux-sunxi]
delwin_ has joined #linux-sunxi
The_Loko has joined #linux-sunxi
lemonzest has quit [Quit: Quitting]
<zoobab>
pong
sr-digitronic has joined #linux-sunxi
<MicroJoe>
hello, my target is not mainline but sunxi tree. Can you check this mailing list problem so I can send you a patch?
<MicroJoe>
Message from delivery system : We're writing to let you know that the group you tried to contact (linux-sunxi) may not exist, or you may not have permission to post messages to the group.
<beeble>
delwin_: no idea about the 3.10 bpi kernel tree. you should first check if spi is enabled at all. do you have the devicetree at hand?
<icenowy[m]>
Kc: seems no
<icenowy[m]>
for H2+/H3, H2+ is just the low bin of H3 ;-)
strfry has joined #linux-sunxi
<KotCzarny>
;)
<KotCzarny>
still, i assume their production is affected by the same rules as ones with bins in source code, would be interesting to confirm
TheSeven has joined #linux-sunxi
<icenowy[m]>
wink says no bin info on H3/5...
<KotCzarny>
ahm, thanks
<KotCzarny>
can you ask him if and how emac can access sram a1/a2 ?
<wens>
what?
<wens>
it does?
<wens>
finally got smp code for a80 that _doesn't_ use mcpm
* wens
head hurts
<KotCzarny>
wens, that 'it does' is about my question?
<BenG83>
icenowy[m], does A64 have binning info?
lurchi_ is now known as lurchi__
hipboi_ has joined #linux-sunxi
<delwin_>
@beeble: Thanks for the pointers, let me follow up on SPI enabled and then dtb first. appreciate the help
The_Loko has quit [Quit: Leaving]
<icenowy[m]>
KotCzarny: if emac can access them then it will be the normal way
<icenowy[m]>
it it cannot access it it just cannot
<icenowy[m]>
so no need to ask
<KotCzarny>
problem is that it might be some undocumented bit to set
<KotCzarny>
that's why i'm asking
<KotCzarny>
and unless someone smarter than me could confirm or deny the possibility, it's unknown
<icenowy[m]>
there's no
<icenowy[m]>
as there's no such usage in normal state by AW
<apritzel>
KotCzarny: what are you after, actually?
<KotCzarny>
apritzel: wake-on-lan from arisc
<KotCzarny>
for h3/h5
<KotCzarny>
i've already done powerdown for the most of the soc
<icenowy[m]>
oh the thermal become a big problem on H6...
<KotCzarny>
and wrote basic eth driver, but it hangs on access to sram a1/a2
<icenowy[m]>
KotCzarny: it's only from the view of CPU that the SRAM's are there
<icenowy[m]>
from the view of other blocks the SRAM might be not mapped at all
<icenowy[m]>
remember SRAM A2 is differently mapped on CPUx and ARISC
<KotCzarny>
i would be happy with either a1 or a2 working, at this moment hangs the same
<KotCzarny>
and it's not a problem for arisc to access the sram but emac
<icenowy[m]>
according to the bus tree of H6
<KotCzarny>
since it uses own dma engine to read
<icenowy[m]>
emac can only access dram
<icenowy[m]>
no sram is accessible from emac
f0xx has quit []
<KotCzarny>
what about h3/h5?
f0xx has joined #linux-sunxi
<icenowy[m]>
should be the same
<icenowy[m]>
although the accessibility between external blocks and DRAM is not drawn on H3/5 manual
<wens>
KotCzarny: yes
<icenowy[m]>
so you must find some way to bypass the DMA
<icenowy[m]>
as it's only "DDA" Direct DRAM Access
<KotCzarny>
darn, would suck if it's that way
<KotCzarny>
wens: so you think it's possible for emac to access sram?
<icenowy[m]>
and it's also possible that the way does not exist
<wens>
KotCzarny: no, I meant I was suprised that it did, not that I know it does
<apritzel>
in the H6 manual there is obvious direct connection between the EMAC and the DRAM, which hints at the the EMAC DMA only works to DRAM
<apritzel>
but the A64 and H3 manuals don't show this
<KotCzarny>
darn.
<icenowy[m]>
P.S. some PHYs are capable of WOL
<KotCzarny>
but i guess i can add option to keep dram powered as runtime option for a workaround
<apritzel>
KotCzarny: I wonder if there is way to directly access the 16K RX FIFO the EMAC description talks about
<strfry>
Hello, can someone tell me what's the current legacy branch for a V40 (on a Bpi-M2Berry)?
<KotCzarny>
hmm
<apritzel>
maybe that's a question Allwinner could answer
<apritzel>
KotCzarny: or you check for that in other Designware MACs
<wens>
strfry: there is none
BenG83 has quit [Quit: Leaving]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
BenG83 has joined #linux-sunxi
jemk has quit [Quit: Lost terminal]
junnie_ has joined #linux-sunxi
antony1 has quit [Quit: Leaving.]
delwin_ has quit [Quit: Leaving]
DullTube has quit [Quit: Leaving]
cnxsoft has joined #linux-sunxi
basxto has quit [Remote host closed the connection]
strfry has quit [Read error: Connection reset by peer]
strfry has joined #linux-sunxi
basxto has joined #linux-sunxi
fkluknav has joined #linux-sunxi
antony has joined #linux-sunxi
Ntemis has joined #linux-sunxi
jemk has joined #linux-sunxi
return0e has quit [Read error: Connection reset by peer]
msimpson_ has joined #linux-sunxi
return0e has joined #linux-sunxi
IgorPec has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
msimpson has quit [Ping timeout: 248 seconds]
leviathancn has quit [Ping timeout: 252 seconds]
<smaeul>
apritzel: looking at the GIC interrupt list I realized that R_INTC interrupts are just mapped to IRQ 64-95 in the table
<smaeul>
I know from aw arisc blob that ther's >16 and ≤32 IRQs on R_INTC, and the four known ones (NMI, TIMER0, TIMER1, and MSGBOX) all match up
<smaeul>
unfortunately, if true this means it's impossible to get thermal sensor interrupts on the arisc. of all the things they could use the management CPU for, you'd think the sensor would be one of them...
<apritzel>
smaeul: ah, thanks, good info
<apritzel>
smaeul: yeah, the temperature sensors is lacking, it also can't be made secure
<apritzel>
smaeul: so non-secure could turn it off
<apritzel>
smaeul: which actually already happens with the THS clock, when you boot Linux
<smaeul>
well, since I'll have to poll anyway, I can just turn it back on every time ;)
<icenowy[m]>
wens: ^
<wens>
?
cnxsoft has quit [Quit: cnxsoft]
<icenowy[m]>
for R_INTC
<wens>
oh
<wens>
put it on the wiki? :)
afaerber has quit [Quit: Leaving]
jbrown has joined #linux-sunxi
dh1tw has joined #linux-sunxi
diego_r has joined #linux-sunxi
afaerber has joined #linux-sunxi
Putti has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 248 seconds]
nuuuciano has joined #linux-sunxi
<beeble>
can me someone help with translating this chinese comment (not sure if correct since the encoding of the file was broken and i just assumed it should be gb18030)?
<BenG83>
as far as I understand, if you have a board with short routes it may be necessary to enable that fixed 2ns delay
<BenG83>
(short wrt RGMII I/O sampling points)
<BenG83>
but only used if the delays are not set in the MAC
junnie_ has joined #linux-sunxi
<BenG83>
which we don't do in the mainline dts/driver it seems?
<icenowy[m]>
in fact I don't precisely know what happened on the PHY
<icenowy[m]>
it's why the mainline do not accept it now
<BenG83>
me neither
<BenG83>
over time I learned a bit more about the delays
<BenG83>
and that it really depends on the board layout which approach you need
<icenowy[m]>
maybe I should name it a meaningless property, like "realtek,hack-for-pine64"? ;-)
<BenG83>
if the length are within the tolerance window, and short, you need the fixed 2ns phy delay
junnie_ has quit [Ping timeout: 240 seconds]
<BenG83>
if the lenght is in tolerance window and longer, you might not neeed the phy delay
<icenowy[m]>
now the problem seems to be not the fixed delay with short path
<BenG83>
if the length are outside the tolerance window
<BenG83>
you have to do the fine tuning on the MAC side
<BenG83>
where you have more control over the delay
<BenG83>
but you should never use both sides
<BenG83>
unless you are really bad and your length is so far off that you need an additional offset ;P
<BenG83>
I will re-enable the fixed phy tx delay and see if that fixes clusterboard
<icenowy[m]>
maybe I should try to make a patch to disable UAS of broken Norelsys NS1068 chips now?
<BenG83>
where is that used?
<icenowy[m]>
(I got USB3 working on my Pine H64 now)
<BenG83>
oh nice
<beeble>
BenG83: you _always_ need the delay. rgmii specification requires it. now you have different ways to implement it, way in the past it was done on the pcb design with longer traces for the clock. nowadays you have digital delay elements. usually you have the delay in one direction set on the phy and the other direction on the mac
<beeble>
but you can change that if it fits your application
<icenowy[m]>
NS1068 is a cheap but weird USB-SATA bridge
<icenowy[m]>
USB3-capable
<icenowy[m]>
claims to be UAS-capable, however breaks on both my Pine H64 and Rock64
<icenowy[m]>
(according to some report also break on Amlogic platforms
<icenowy[m]>
(strange thing is that it doesn't break on my IVB laptop ;-)