<javier__>
afaerber: thanks for the review, I guess my patch doesn't make sense for spring then if is not possible to open the case
<afaerber>
javier__, well, HP/Google might have some prototypes...
<javier__>
afaerber: yeah but they can set console=ttySAC3 then
<javier__>
there is no need to have a default if only a bunch of people have access to a serial console
<afaerber>
javier__, maybe (or even probably) there's a secret way to open the device, there just weren't any documented take-it-apart guides on the Internet last time I checked
<javier__>
afaerber: I see, your question about display is a good one. I wondered exactly the same but from a quick look I couldn't figure it so I left the bootargs
<javier__>
and even if there were, you have only one default so having both std-out set to the serial console and bootargs to the display allows people to choose
<javier__>
by enabling CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND or not
<afaerber>
I assume an alias would be needed at least
<afaerber>
heh, that kernel config option is not really a realistic choice for a distro kernel. the choice would rather be *which* bootargs to supply (leaving out console= to try the default)
<afaerber>
which they need to do anyway to specify the root=
<javier__>
afaerber: yeah, that was the other option and removing the bootargs but I didn't know if that would break some people workflows
<afaerber>
javier__, the point of having the minimal bootargs was to tell people what to use as sane default
<afaerber>
ttySAC3 wasn't, under the circumstances
<afaerber>
btw, do you get unsubscribed from the vger links frequently, too?
* afaerber
missed the last 1.5 weeks apparently, including my own submission
<afaerber>
linux-arm-kernel is much more reliable
<javier__>
afaerber: no I didn't afaict
<javier__>
afaerber: well the current bootargs is also not a sane default since you can't boot a system only with that
<javier__>
you need a root device, etc
<afaerber>
right, I meant you know what to specify to read errors such as missing root device
<javier__>
right
<sjoerd>
afaerber: no screws? not even under say rubber feet
<javier__>
afaerber: btw, did you see my patch that "fixes" display on Snow?
<afaerber>
javier__, no, I didn't - wasn't CC'ed apparently and didn't get linux-samsung-soc mails since Mar 02
<javier__>
afaerber: yeah sorry for not cc'ing you
<javier__>
I always try to do it if I think it will be relevant to you
<afaerber>
sjoerd, there's two huge blue rubber pads...
<javier__>
afaerber: probably that is just masking a bigger issue
<sjoerd>
afaerber, javier__: fwiw what i never tested is whether the chosen stdout overrides the normal default console to tty0 or whether it's additional
<javier__>
like if the power domain gets powered off and powered on before the FIMD is probed then that fails to do it correctly
<javier__>
sjoerd: it doesn't override, that is if you have a console= in your kenrel command line then that will be used
<javier__>
sjoerd: is only used as a default if you don't define anything
ssk has joined #linux-exynos
<javier__>
afaerber: so what I think that happens is this: the bootloder setups the DISP1 power domain correctly and the FIMD is initialized correctly, if the dp phy is made a consumer of the DISP1 power domain then the usage count is incremented
<javier__>
the probe is deferred and the DISP1 is powered off, then powered on when the exynos-drm driver is probed but that fails
<javier__>
so the fact that is working with my "fix" is only by luck
<javier__>
since I tested disabling the display and enabling it again and the display fails again
<javier__>
afaerber, sjoerd: but I think the patch is correct anyways given that the DP is not mentioned as a module in the DISP1 pd
<javier__>
but it seems there is something missing wit the PD like it was the case on exynos5420
* javier__
=> lunch, bbl
<sjoerd>
javier__: sure but if you don't define anything currently the kernel uses tty0 normally afik
<afaerber>
javier__, woohooo!
ssvb has quit [Ping timeout: 246 seconds]
ssk has quit [Ping timeout: 252 seconds]
<afaerber>
javier__, hm, after the screensaver kicked in and the screen went off, same problem as before :(
<javier__>
afaerber: yeah, that's what I meant by disabling the display and enabling the display again ^
<javier__>
afaerber: so, it was working before andrzej patch because the disp1 power domain was not defined
<javier__>
so the kernel didn't know about it and didn't attempt to turning it on and off
<javier__>
aferber: we have to figure out what is missing in the DISP1 definition or alternively we have to revert Andrzej's
<javier__>
2d2c9a8d0a4f ARM: dts: add display power domain for exynos5250
<javier__>
afaerber: I'll answer on the list
<afaerber>
javier__, there's no always-on property I guess? ;)
<javier__>
afaerber: you can boot with pd_ignore_unused
<javier__>
but I don't know if there is a way to mark it in the DT as always-on... maybe it should
<afaerber>
was just thinking that we do that with some regulators occasionally
<afaerber>
btw I had tested those PD patches to not make things worse, in the hopes that they might help ;)
<javier__>
afaerber: yes, I believe my patch is correct anyways if nothing else to better describe the hw
<javier__>
but I think that for now we should just revert andrzej's commit if even samsung folks don't know what is missing
aballier has joined #linux-exynos
ssk has joined #linux-exynos
<javier__>
afaerber: sjoerd is right, the kernel defaults to tty0 if you don't pass any console (neither in the cmd line nor DT)
<javier__>
sjoerd: but as you can see there the stdout-path overrides that
<afaerber>
sjoerd, what is tty0 actually? o.O
<javier__>
afaerber: current virtual console afaik
<afaerber>
well, for the display we need tty1, so tty0 must be really really virtual
<javier__>
afaerber: both are virtual but one is current
<javier__>
so if you are in tty1 and do $ echo foo > /dev/tty1
<javier__>
you will se the output and if you do echo foo > /dev/tty2 and change to tty2
<bgamari>
afaerber, how's it look?
<javier__>
will see it in tty2, now echo foo > /dev/tty0 will output in tty1 or tt2
<javier__>
afaerber: depending on what is your current ttyX
<javier__>
afaerber: that means that is safe to remove the bootargs in the spring dts since the kernel does the right thing on default
<javier__>
*by default
<afaerber>
javier__, still not clear to me as I have no ttySACx active afaik (no stdout-path, no other console=)
<afaerber>
javier__, how is that the right thing?
<afaerber>
bgamari, you mean ODROID-XU or the current discussion? ;) I sent out v4 last night and CC'ed you even
<javier__>
afaerber: I meant dropping my patch to add stdout-path *and* removing the bootargs
<javier__>
then the kernel won't get any console and will default to tty0 which will be tty1
<bgamari>
afaerber, hmm
<afaerber>
javier__, I've tried console=tty0 in the past and it didn't work, therefore my question
<afaerber>
bgamari, I also updated the Wiki page to point to that new submission (and linking v2 as well)
<bgamari>
ahh, indeed I got it
<bgamari>
thanks!
<afaerber>
the I2C still needed a bit of cleanup related to authorship/Sob and can't go in without the first series anyway
<bgamari>
afaerber, any sigh of life from USB?
<bgamari>
sign*
<afaerber>
bgamari, sure, with the stuff on my branch
<javier__>
afaerber: strange, on snow both using console=tty0 or not passing a console make the output go to the display
<sjoerd>
javier__, afaerber: tty0 is an alias for whatever your current tty is.. e.g. echo badger > /dev/tty0 will make it appear on the your screen regardless of the actaul tty you're on
<sjoerd>
javier__: So the one oddness is that if you define linux,stdout-path on the chromebooks is that the default kernel output will go to serial rather then the screen
<sjoerd>
As with most other boards defining that however, the chromebook serial console are slightly less accessible then random devboards
<sjoerd>
Otoh that default is better for my use-cases :p
<javier__>
sjoerd: hrmm, it is better for my use-case too but is true that it will break the default of showing in the display
<javier__>
which is probably what most users will use unless they solder a USB TTL cable to the UART pins
<javier__>
afaerber: answered on the list and asked andrzej if he knows what could be missing on DISP1 power on
<javier__>
otherwise we have to revert his patch to make the display work correctly again
* afaerber
is still compiling latest linux-next before trying pd_ignore_unused
<afaerber>
javier__, have you tried adding any asbN clocks? if it's about clocks, wouldn't clk_ignore_unused help? (tried with and without, I believe)
<javier__>
afaerber: Andrzej cover-letter said "Exynos chipsets since 542x have asynchronous bridges connecting different IPs"
<javier__>
afaerber: and even if his assumption is not correct and exynos5250 also have async bridges between IPs, I don't know which clocks should I define there
<javier__>
even in exynos5420 that is not well documented and exynos5250 does not mention at all
<javier__>
so I think that if no one really knows what are the DISP1 pd requirements, I think is better to just not make the kernel aware of it
<afaerber>
javier__, on the 542x devices, did one see the clocks in debugfs?
<bgamari>
afaerber, Could you push your latest bits to your github repo?
<afaerber>
bgamari, they should be...
<bgamari>
odroidxu was supposedly last updated four months ago
<bgamari>
and I don't see any new commits since yesterday
<bgamari>
-leds is ten months old
<bgamari>
take your time though
<bgamari>
doesn't need to happen right now
<bgamari>
I should get to work anyways
<javier__>
afaerber: yes, those were shown in debugfs
<javier__>
afaerber: but other devices were also consumers of the same clock so you always so them enabled
<javier__>
the problem was that were not enabled by the time it was needed
<bgamari>
ahh, indeed github is confused; it claims "Failed to load latest commit information." for me
<afaerber>
javier__, not sure what you're looking at, but odroidxu-leds was pushed publicly just last night
<afaerber>
err bgamari obviously
<bgamari>
never seen this before
<bgamari>
request fails witha 504 gateway timeout
<bgamari>
odd
<bgamari>
alright, I'll just pull then
<afaerber>
hmm, maybe because I was concurrently pushing Spring stuff...
<javier__>
afaerber: so in summary, I'm all for describin the DISP1 pd in the DTS
<javier__>
but I think we should revert now, rely on the bootloader and the kernel not touching it for now and once someone understand what is needed added again
<javier__>
*add it
<javier__>
rather than the current situation where only half ot it is described and breaks the display :)
<afaerber>
javier__, fully agree. I'm just less confident in the Samsung guys fixing things for old SoCs ;)
<afaerber>
as 5410 shows
<javier__>
nod, I've just too many things on my TODO to dig further to this issue so I will post a patch to revert if andrzej doesn't answer
<afaerber>
javier__, are you seeing i2c-cros-ec-tunnel.c build errors on today's linux-next?
<javier__>
afaerber: what is really weird is that both you and I tested the offending commit...
<afaerber>
yeah, I blame the drm refactorings to mess with timing...
<javier__>
afaerber: could be
<javier__>
afaerber: no, CC drivers/i2c//busses/i2c-cros-ec-tunnel.o
<javier__>
with exynos_defconfig?
<afaerber>
javier__, sorry, the i2c forwarding patch no longer applies now, some fields changed from pointer to array
<javier__>
afaerber: yes, 1b84f2a4cd4a mfd: cros_ec: Use fixed size arrays to transfer data with the EC
Tenkawa has joined #linux-exynos
Tenkawa has joined #linux-exynos
<javier__>
it is needed to prevent ioctl compat on arm64 systems since I was asked to make it 64-bit safe
<afaerber>
javier__, poweroff seems to work fine now :) Feel free to reply with my Tested-by
<afaerber>
nah, spoke to soon. instead of staying display-lit etc. everything went dark, but turning it on again didn't work, i.e. I had to hold the powerbutton before some time before I could turn it on again
<javier__>
afaerber: it seems you have a different issue then...
<afaerber>
I will try pd_ignore_unused next
<javier__>
ok
zombah has quit [Quit: Leaving]
gautam__ has joined #linux-exynos
LanDi has joined #linux-exynos
<afaerber>
javier__, pd_ignore_unused alone (without your DT patch) does not help
<afaerber>
reboot still works fine
<javier__>
afaerber: hrmm, I wonder if pd_ignore_unused only means not turning off unused DT
<javier__>
after a certain initcall level but still can be disabled at runtime
<javier__>
like clk_ignore_unused
<javier__>
afaerber: probably just having the disp pd but not having any consumer and pd_ignore_unused will work
<afaerber>
most specifically the display is never powered up in my case
<javier__>
afaerber: yeah, that's why I think that pd_ignore_unused means don't turn off unused power domains after boot
<javier__>
but does not mean that the pd won't be turned off if there is a consumer and its usage count reaches 0
<afaerber>
hm
<afaerber>
have you seen issues with the Atmel touchpad?
<javier__>
afaerber: what issues?
<afaerber>
it seems I have to click first before I can move around the cursor or something
<javier__>
hrmm, no but I don't usually test gfx
<afaerber>
now with display I can finally properly test Wifi, seems to be working - connecting fine
<javier__>
great
<javier__>
I'm having issues testing the clocks since the clk-exynos5250.c doesn't match the documentation I've
<afaerber>
heh
<javier__>
it's really frustrating...
<afaerber>
could be the problem then ;)
<javier__>
eh, let's seee
LanDi has quit [Quit: fui !]
<javier__>
afaerber: now I remember why the offending commit had both of our tested-by
<javier__>
because that patch was needed to have HDMI working and that is what we (well at least I) tested
<javier__>
and at the time it was posted ajay's display patches have not landed yet
<javier__>
afaerber: I could not make it to work, let's see if someone at samsung answer but if not I think we should revert that commit
<javier__>
afaerber: both display and HDMI are working without it anyways, the only advantage of defining in the DT is that the pd can be powered off