Monday, 2013-03-25

*** biot <biot!~bert@2a01:7b8:2006:ea81::fce2> has quit IRC00:00
*** philips <philips!> has quit IRC00:01
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has joined #minnowboard00:03
*** neofob <neofob!~tuan@> has joined #minnowboard00:03
*** biot <biot!~bert@2a01:7b8:2006:ea81::fce2> has joined #minnowboard00:05
*** philips <philips!> has joined #minnowboard00:20
*** zeddii <zeddii!~ddez@> has quit IRC00:27
*** zeddii <zeddii!~ddez@> has joined #minnowboard00:30
*** neofob <neofob!~tuan@> has quit IRC00:36
*** neofob <neofob!~tuan@> has joined #minnowboard00:43
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC01:07
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard01:09
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC01:20
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has quit IRC01:26
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has joined #minnowboard01:31
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has quit IRC01:33
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard01:38
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC01:39
*** DevBot` <DevBot`!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has joined #minnowboard01:41
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard01:45
*** DevBot` <DevBot`!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has quit IRC02:02
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC02:02
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has joined #minnowboard02:10
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard02:14
*** DevBot <DevBot!~supybot@2001:6f8:12e0:0:2de:adff:febe:ef08> has quit IRC02:19
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC02:35
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard02:35
*** zedd_ <zedd_!~ddez@> has joined #minnowboard05:42
*** zeddii <zeddii!~ddez@> has quit IRC05:46
*** ds2 <ds2!> has joined #minnowboard06:47
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC08:40
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #minnowboard08:44
*** panto <panto!~panto@> has joined #minnowboard08:50
*** zedd_ is now known as zeddii12:24
*** mdp <mdp!> has left #minnowboard13:42
*** prpplague <prpplague!> has quit IRC14:42
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC15:24
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #minnowboard15:25
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC15:31
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #minnowboard15:35
*** prpplague <prpplague!> has joined #minnowboard15:37
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC15:40
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #minnowboard15:41
*** dvhart <dvhart!~dvhart@> has joined #minnowboard15:46
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC15:49
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #minnowboard15:51
*** zenlinux_ <zenlinux_!> has joined #minnowboard16:03
* prpplague hands zenlinux_ some coffee with rum16:10
zenlinux_I'm actually enjoying an aeropress of some Kenyan beans atm16:15
zenlinux_sans rum16:15
* dm8tbr takes the coffe from prpplague then :)16:15
prpplaguedm8tbr: hehe16:15
*** neofob <neofob!~tuan@> has left #minnowboard16:19
*** zenlinux_ <zenlinux_!> has quit IRC16:56
*** prpplague <prpplague!> has quit IRC17:13
*** prpplague <prpplague!> has joined #minnowboard17:14
*** dm8tbr <dm8tbr!> has quit IRC17:36
*** prp^2 <prp^2!> has joined #minnowboard17:40
*** prpplague <prpplague!> has quit IRC17:41
*** dm8tbr <dm8tbr!> has joined #minnowboard17:43
*** prp^2 is now known as prpplague17:45
*** neofob <neofob!~tuan@> has joined #minnowboard17:56
mranostayprpplague: #coffeeallthings!18:29
*** hieuduong <hieuduong!44584dab@gateway/web/freenode/ip.> has joined #minnowboard18:41
prpplaguedvhart: ping19:00
dvhartyes sir?19:00
prpplaguedvhart: any question/issues on the ethernet stuff for now?19:01
dvhartnope. I'm integrating the tx delay in the driver. But this really isn't an issue about the PAL not being used. These are debug registers on the AR8031 we're using and that isn't present in the existing phy device for the PAL. It is also not something you can do based just on the PHY ID.19:02
dvhartThis is really a board-specific requirement19:02
dvhartbecause we didn't do the delay in the trace routing19:02
dvhartso I'm having to switch on DMI_BOARD_NAME==Minnow19:02
dvhartand then IF PHY==AR803119:02
dvhartadded the register and value defines, building and testing now19:03
dvhartI have concerns about these being "debug" features.... but only due to the nomenclature in the datasheet19:03
prpplaguedvhart: that is mainly the naming scheme, a lot of PHYs support the option, just not in the spec'd IEEE registers19:04
prpplaguedvhart: pretty much all of the ARM based designs i sampled used the software based tx clock delay rather than hardware trace delays19:04
prpplaguedvhart: ok, so as long as we are moving forward on the stuff19:05
dvhartyes.... but I'm not thrilled about modeling IA drivers after anything done under arch/arm!19:05
prpplaguedvhart: my next item of work is the audio codec testing19:05
prpplaguedvhart: hehe19:06
dvhartalthough things have improved dramatically there19:06
* prpplague avoids a flame war,19:06
dvhartthat's actually the point19:06
dvhartI don't want to have to try and fight that fight on LKML19:06
prpplaguedvhart: ok, so i just wanted to make sure you didn't have any questions on the functionality and the board looked good19:07
dvhartbut I think I can do this in a more or less acceptable way19:07
dvhartyup, so far, so good.19:07
prpplaguedvhart: i tested the hdmi output with some framebuffer tests19:07
prpplaguedvhart: everything looked good on that board19:07
dvhartI would like to know what the effort/impact would be to do this layout though19:07
dvhartsomething to bringup at our next sync19:07
prpplaguedvhart: yea i have our layout guy looking into that19:07
dvhartis it another 4mm of trace? does it force another layer... etc19:07
dvhartright now I have no idea19:08
dvhartneed to compare that with the cost/maintenance of deviating from the norm19:08
prpplaguedvhart: the length depends on the board stackup and the thickness of the trace19:08
dvhartmakes sense19:08
dvhartjust not something I can answer :-)19:08
koendvhart: arm/mips/ppc/avr3219:08
koenanything resembling a soc is using phylib19:09
dvhartkoen, I just said arm as that was prpplague reference point19:09
dvhartbut yes, noted19:09
*** hieuduong_ <hieuduong_!44584dab@gateway/web/freenode/ip.> has joined #minnowboard19:09
* prpplague wanders off to find some food19:09
dvhartThe ability for a single image is particularly important to maintain for an IA board19:09
dvhartso having to recompile for IFDEFS or board platform files is to be avoided wherever possible19:10
* dvhart goes back to instrumenting all the io(read|write)32 calls for lee19:10
koentake my laptop as an example19:10
koenI have to modprobe snd-hda-intel model=foo to make it work19:11
dvhartthose laptop drivers are not to be modeled after19:11
dvhartkoen, that's a shame IMO19:11
dvhartalthough the model= is something that the pch_gbe maintainer can suggest I use instead of the DMI_BOARD_NAME check19:11
dvhartI'll leave that call up to them, easy to switch the mechanism19:11
*** hieuduong <hieuduong!44584dab@gateway/web/freenode/ip.> has quit IRC19:12
mranostaykoen: no PCI_QUIRK?19:12
koenon my soekris net6501 I have to compile out the pch_gbe19:12
koenotherwise it keeps spamming syslog about not being able to see the phy19:12
dvhartkoen, there are plenty of bad examples :-) that doesn't make them OK or to be followed19:12
koenI know19:12
dvhartkoen, on the net6501.... is that a pch_gbe_phy driver issue assuming a specific phy?19:13
dvhartkoen, would that benefit from me converting to PAL?19:13
koenit's not hooked up at all19:13
dvhartah :/19:13
dvharthey, handing SIGFOOD while building as well19:13
mranostaydvhart: i don't recall that in the Posix spec19:16
koenbreakfast burrito!19:18
ds2wow there is dutch breakfast burrito?19:22
* mranostay pictures what that would be19:29
mranostaywhat is dutch food?19:32
* mranostay pulls up the wiki page19:34
koends2: no, I saved a burrito from dinner19:34
koends2: but I wish I could get a breakfast burrito :)19:34
mranostay mmmm dutch apple pie19:35
prpplaguedvhart: agreed, we want to make sure it is bootable as possible on as many platforms20:02
dvhartmranostay, I need to explore PCI_QUIRKs, maybe that would be a better way to handle the PHY issue on Minnow20:53
prpplaguehehe i updated tracey's "mugshot"22:27
dvhartprpplague, hrm22:28
dvhartprpplague, having some issues with the means to detect the need for the TX delay22:29
dvhartprpplague, I *can* do it via DMI_BOARD_NAME, but it's rather frowned upon22:29
dvhartideally we would use a PCI sub id22:29
dvhartbut we don't have an EEPROM... which is where the MAC should be in the first place22:29
dvhartwhat would it take to get that EEPROM?22:29
dvhartwould provide for the subid and the mac22:29
prpplague"can device tree help here?"22:30
prpplaguedvhart: these are pretty typical dev board items22:30
dvhartprpplague, I could do something with acpi SSDTs I suppose22:30
prpplaguedvhart: most vendors who create board and don't provide MAC addresses generally just include a minnor patch to handle this22:31
prpplaguedvhart: the reason is two fold22:31
dvhartthat isn't true for x86 :-)22:31
prpplaguedvhart: one they want to highlight the fact that the design isnt intended for OEM inclusion22:31
dvhartI have only seen one x86 board without a MAC22:31
prpplaguedvhart: and two, to make sure the user is aware of this22:31
dvhartand the response to my patch making that board work was astonishment and a twinge of hate22:31
prpplaguedvhart: from who?22:32
dvhartdavid miller22:32
prpplaguedvhart: hehe yea, i would assume so22:32
dvharthe refused the use of the random_mac function22:33
dvhartso I had to accept just NOT disabling the device22:33
prpplaguedvhart: yea those are generally refused22:33
dvhartso I could fix it up from user space22:33
dvhartanyway, this is pretty non-standard for x86 boards22:33
dvhartand building on that platform is part of the value of minnow22:33
prpplaguedvhart: one sec phone22:34
prpplaguedvhart: yea, i know x86 world is generally different, but the key here is Minnow is reaching into the traditionally highly embedded areas that ARM has a stranglehold on22:38
prpplaguedvhart: i find it hard to believe that this is the very first case where a board specific fix is needed in an x86 kernel22:38
dvhartyes - but not by duplicating the ARM boards's strengths and weaknesses :-)22:38
prpplaguedvhart: argee22:39
dvhartprpplague, again, just because it's been done doesn't mean it should continue22:39
prpplaguedvhart: also agreed22:39
dvhartsince we have the chance to do something better, I want to explore that method :-)22:39
dvhartnow, the EEPROM isn't our only option22:39
dvhartjust one22:39
dvhartthe MAC can also go in nvram22:39
dvhartand that is fine, no need to bump the BOM and complexity by adding an EEPROM22:39
dvhartbut, I still need a good solution for identifying the need for the TX delay22:40
dvharta PCI Sub ID would be ideal22:40
dvhart and maybe I can do that via firmware22:40
dvhartI'm exploring that option too22:40
prpplaguedvhart: will Intel be purchasing/providing the MAC block?22:40
dvhartprpplague, something to bring up on the call tomorrow22:40
dvhartI don't know what has been decided there22:40
dvhartone of those details that hasn't been broached as we've been working on the more pressing immediate issues22:41
dvhartso yeah, let's bring this all up in the broader group tomorrow?22:41
prpplaguedvhart: yep will do22:41
dvhartI'll explore my options internally here re the pci id22:41
prpplaguedvhart: i'll have a look at the pci sub id blocks as well22:41
dvhartthe pch_uart driver also could benefit from this as it has the same issue with the PCH_UARTCLK22:42
dvhartcurrently switches on dmi strings22:42
prpplaguesurely the minnow can't be the first x86 board that requires board fixes-ups22:43
dvhartnope, but these are typically done with PCI sub ids22:43
dvhartPCI Quirks for example22:43
dvhartand the minnow is one of 5 doing this in pch_uart22:43
dvhartbut the pch is a weird beast to begin with22:44
dvhartfyi, that's where the driver phy fix stands for now22:46
dvhartprpplague, you OK with your attributions in that?22:47
mranostaydvhart: note the PCI_QUIRK stuff I did was for inte-hda ALSA drivers22:51
mranostaynot sure it applies elsewhere22:52
prpplaguedvhart: yep that is fine, generally no need to even give me any credit on it unless it is my patch unchanged22:52
prpplaguedvhart: we'll need to disable the hibernation mode as well22:52
dvhartmranostay, yeah, nothing wrong with PCI Quirks22:52
prpplaguedvhart: which reminds me22:52
prpplaguedvhart: another item that needs to be addressed on the ethernet driver22:52
prpplaguedvhart: during the pch_gbe driver init, a hardware reset is done on mac22:53
prpplaguedvhart: a corresponding hardware reset needs to be done on the phy22:53
dvhartI see phy reset code... do you mean we need to do it via the PHY_RESET line and not over RGMII ?22:54
prpplaguedvhart: correct22:55
dvhartwhy is that? (I mean, why do we need it but the other boards do not)22:55
prpplaguedvhart: because the AR8031 like many other low power PHY solutions supports a "hibernation" mode22:55
prpplaguedvhart: this means that if there is no cable plugged in when the system boots, it will be asleep by the time the driver tries to do the init22:56
prpplaguedvhart: in order to make sure that it is awake during the driver init, a hardware reset needs to occur before proceeding22:56
dvhartcan this be done in firmware?22:57
prpplaguedvhart: problem is the time frame22:57
prpplaguedvhart: you have less than 10 seconds after the hardware reset before it goes to sleep22:57
dvhartand what will wake it up?22:58
dvhartplugging in a cable?22:58
prpplaguedvhart: yep, but by then the pch_gbe driver has failed22:59
dvhartjust trying to understand the scope of the change22:59
dvhartbeing that's done over GPIO... ewe, going to be a little ugly23:00
dvhartbut doable23:00
dvhartI should be reserving that line for pch_gbe anyway I think23:00
dvhartagain, a pci sub id would be really great here.23:00
prpplaguedvhart: yea sounds so23:01
prpplaguedvhart: this stuff is pretty easily handled in ARM subsystems, which is why the AR8031 is pretty popular there. and since Rao had experience with the ARM stuff, he just cut-n-pasted this over assuming the functionalities would be the same23:02
prpplaguesurprise surprise surprise23:02
dvhartvery different approaches to device handling, so not really a surprise :-)23:03
dvhartbut this pch_gbe driver, as you have said, isn't particularly current23:03
dvhartOK, I'll be pushing the pch_gbe changes to the BSP shortly (one final test running)23:05
dvhartpch_gbe instrumentation will be in the BSP23:05
dvhartbut for now, it's spring break and time for me to go to my second job (parent duties and all that)23:06
dvhartmore later - thanks for the info on the phy prpplague , very helpful23:06
prpplaguedvhart: hehe np23:06
prpplaguedvhart: we'll get it worked out in a nice mainline kernel acceptable way23:06
*** prpplague <prpplague!> has quit IRC23:09
*** dvhart <dvhart!~dvhart@> has quit IRC23:19
*** panto <panto!~panto@> has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!