C47 has quit [Quit: Leaving]
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 248 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
[X-Scale] has quit [Ping timeout: 248 seconds]
digshadow has quit [Ping timeout: 265 seconds]
digshadow has joined ##openfpga
X-Scale has joined ##openfpga
tecepe has quit [Remote host closed the connection]
<azonenberg> Welp, back in town and ready to do more hacking on the DAC stuff
* azonenberg pulls FIB out of pocket
<azonenberg> whitequark: you managed to replicate my findings on the greenpak DAC having slightly different outputs right?
<azonenberg> i'm going to try and replicate in the GUI
<azonenberg> See if it's just me or what
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
talsit has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
tecepe has joined ##openfpga
C47 has joined ##openfpga
C47 has quit [Quit: Leaving]
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/virRq
<openfpga-github> openfpga/master b6d8af7 Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/openfpga
<openfpga-github> openfpga/master 115ecb8 Andrew Zonenberg: doc: added .gitattributes so github doesn't incorrectly flag the project as mostly KiCAD
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 3075c27 to 9bea049: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 9bea049 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#84 (master - b6d8af7 : Andrew Zonenberg): The build is still failing.
<azonenberg> whitequark: so, little bit of a problem with the DAC stuff
<azonenberg> According to the docs
<azonenberg> the dacs have different ranges, lol
<azonenberg> Nominally, DAC1 will output one LSB higher value than DAC0
<azonenberg> Possible idea for handling the issue: Require you to implicitly specify which DAC you are using
<azonenberg> by creating two GP_VREF's
<azonenberg> one at 1000 mV and one at 1050 mV
<azonenberg> and drive the DACs with one or the other
<azonenberg> Thoughts?
cosmobird has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!]
doomlord has joined ##openfpga
amclain has quit [Quit: Leaving]
C47 has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
cr1901_modern has quit [Read error: Connection reset by peer]
doomlord has joined ##openfpga
doomlord has quit [Client Quit]
doomlord has joined ##openfpga
doomlord has quit [Client Quit]
<whitequark> yeah, that sounds about right
<whitequark> lolsob
<azonenberg> Welp, one more little quirk
<azonenberg> EDA seems all about dirty quirks and corner cases sometimes :(
<azonenberg> Lol
digshadow has joined ##openfpga
Bike has quit [Quit: death]
C47 has quit [Quit: Leaving]
cr1901_modern has joined ##openfpga
doomlord has joined ##openfpga
cosmobird has quit [Ping timeout: 265 seconds]
cosmobird has joined ##openfpga
<DocScrutinizer05> basically the reason why I don't think DeviceTree will ever really work
<DocScrutinizer05> reality is more complex than any formal language, and when you think your language is complete, the next quirk is right around the corner
<DocScrutinizer05> even a language like electronic schematics isn't complete and needs text notes for some stuff
X-Scale has joined ##openfpga
cosmobird has quit [Remote host closed the connection]
firebird has joined ##openfpga
firebird is now known as Guest82332
Guest82332 has quit [Remote host closed the connection]
Bike has joined ##openfpga
jn__ has quit [Ping timeout: 265 seconds]
jn__ has joined ##openfpga
m_w has joined ##openfpga
amclain has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<azonenberg> DocScrutinizer05: well a lot of this isn't reality so much as design quirks
<azonenberg> iow, if people designed their stuff to not have these issues in the first place... :P
<azonenberg> as in there is no physical reason why they have to do it
<DocScrutinizer05> possibly true in a lot of cases
<DocScrutinizer05> but I can tell you for OAMP phone platforms there are hw requirements no DT syntax can cope with
<azonenberg> Like, i can understand having half of an FPGA IP core mirrored
<azonenberg> if you have the same cell mirrored physically about a central bus
m_w has quit [Quit: leaving]
<azonenberg> it makes sense to flip the config bits
<DocScrutinizer05> in real life you *have* layering violations
m_w has joined ##openfpga
<DocScrutinizer05> when I got two camera modules sharing same CSI interface with a mux, there's simply no DT syntax to handle that
<azonenberg> That sounds like a fundamental flaw, then
<DocScrutinizer05> in DT, yes
<azonenberg> Shared logic is going to happen
<azonenberg> esp in say MCUs
<azonenberg> or SoCs in general
<azonenberg> that is actually one of the things i need to fight in openfpga before i proceed much further (I can do the DACs without it, but not much more)
<azonenberg> There are different ip blocks sharing the same config
<azonenberg> bits
<azonenberg> with a selector to say which does what
<DocScrutinizer05> all kernel modules expect to initialize peripherals on module load. But when you mux to the secondary cam module, the primary module losses the init
<azonenberg> Yeah, makes sense
<azonenberg> Is that the SoC or the camera module's fault?
<DocScrutinizer05> design
<azonenberg> as in where is the mux
<DocScrutinizer05> the mux is discrete
<azonenberg> Oh, ok
<DocScrutinizer05> and platform specific
<azonenberg> So it's not the SoC's fault
<azonenberg> its the pcb design
<DocScrutinizer05> no
<DocScrutinizer05> well, the PCB design is fine
<DocScrutinizer05> it's just real life, not what sw devels think life should look like
<azonenberg> In general i think the majority of problems in OS and EDA development
<azonenberg> are caused by hw and sw devs not being the same people
<azonenberg> or, often, not even talking
<azonenberg> Neither one knows what the other needs
<azonenberg> or even what the reality is
<DocScrutinizer05> yep, my main job description is "ambassador between the two groups"
<azonenberg> This is actually one of the things i am going to try to write as an FPGA core in the near future
<azonenberg> A standardized interface for muxed I2C peripherals
<DocScrutinizer05> I'm a mediocre sw devel and a semi-decent hw devel, and I have an understanding of both worlds
<azonenberg> have say a 2-byte address or something, with the mux block abstracting the actual switching of the buses
<azonenberg> such that you can pretend they're all on one shared bus
<DocScrutinizer05> hehe, won't fly for CSI
<DocScrutinizer05> basically the problem is: there's no kernel driver module for the mux
<azonenberg> Makes sense
<DocScrutinizer05> since it's so unique
<azonenberg> But there should be a generic framework for muxed peripherals sharing one bus (be it PCIe, I2C, or whatever)
<azonenberg> basically you have the kernel bus driver for the bus controller
<azonenberg> then MITM that with a black box that also provides an ioctl for swapping to one sub-bus or another
<azonenberg> then have the normal host device driver talk to that middle layer
<azonenberg> And have the middle driver provide hotplug events when the mux switches
<azonenberg> (unless it's something like i2c where you can just pretend they're all on the same bus or something)
<DocScrutinizer05> CSI isn't a bus, it's an interface not meant for sharing
azonenberg_work has joined ##openfpga
<DocScrutinizer05> the whole point of the mux
<DocScrutinizer05> I guess you run into similar problems in a lot of designs, e.g. hot standby PSUs
<cr1901_modern> azonenberg: (unless it's something like i2c where you can just pretend they're all on the same bus or something) Can you elaborate? Wouldn't a mux in and of itself solve this problem of "multiple separate buses"?
<azonenberg> cr1901_modern: If you extend the I2C bus driver to use (say) 16-bit device addresses instead of 8 bit addresses
<azonenberg> You can simply use the high 8 bits of the address as a mux selector
<azonenberg> then send the low out to that particular sub-bus
<azonenberg> Which lets you pretend that the tree-shaped bus is actually one big linear bus
<azonenberg> as long as the drivers can be modified to use 16-bit device addresses instead of 8
<DocScrutinizer05> nah, that introduces a new peripheral I'd cal a 'hub'
<DocScrutinizer05> which is actually you mux
<azonenberg> DocScrutinizer05: There's two ways of thinking about it
<azonenberg> #1, an explicit mux you switch back and forth
<cr1901_modern> Ahhh... and why wouldn't this apply to all the other buses?
<azonenberg> Which generates hot-plug events
<azonenberg> and you pretend you have only one or the other connected at a time
<azonenberg> This is sane for, say, two cameras
<cr1901_modern> "azonenberg: But there should be a generic framework for muxed peripherals sharing one bus (be it PCIe, I2C, or whatever)"
<azonenberg> #2, an implicit mux with in-band addressing
<azonenberg> Where you pretend that *every* device is simultaneously addressible
<azonenberg> and switch the mux before every packet as required
<azonenberg> Which is sane for, say, two SFP modules connected to a single host
<azonenberg> (mux required b/c hard coded single bus address)
<azonenberg> Depending on the peripheral type and use case one or the other may be appropriate
<azonenberg> in general i'd say #1 is sane for things you switch between, like cell modem or wifi network when you don't intend to support both at once
<azonenberg> or front/rear cameras on a phone
<DocScrutinizer05> my case ... :-)
<azonenberg> #2 is sane for things that need fine-grained access where you're potentially going to have handles open to both devices at once
<azonenberg> DocScrutinizer05: anyway what i'm saying is, the logical solution would be for toggling the mux to trigger a hot-plug event
<azonenberg> basically unload and reload the driver
<DocScrutinizer05> yes, I think that's how it's done in maemo5
<azonenberg> have the device tree pretend it's one camera
<azonenberg> you dont even have to strictly un/reload
<azonenberg> if the driver can completely reset itself on command
<DocScrutinizer05> well, maemo5 api has *two* V4L devices though
<DocScrutinizer05> mux gets operated depending on which you open
LeelooMinai has quit [Ping timeout: 260 seconds]
<DocScrutinizer05> so DT pretending it was just one cam is a bit awkward
LeelooMinai has joined ##openfpga
<DocScrutinizer05> basically you need a dedicated special kernel driver that exports TWO devices at once
<DocScrutinizer05> though I'm not aware of details how they implemented it. Maybe they used more screwed interlock between two single-device drivers
<DocScrutinizer05> I _think_ they exploitr a sort of deferred init that happens on /dev/device open()
<DocScrutinizer05> anyway I seem to recall they had *lots* of fun with that stuff in DT
<azonenberg> DocScrutinizer05: my question is, why would you do that
<azonenberg> vs just having one v4l "camera" device that you can keep open indefinitely
<azonenberg> and an ioctl or something for switching
<DocScrutinizer05> hmm, dunno, maybe because you don't want to mess with device API?
<azonenberg> It seems to make more sense
<DocScrutinizer05> the two devices are pretty plain V4L camera devices that just work
<azonenberg> Yeah what i mean is
<azonenberg> you have a streaming webcam call
<azonenberg> swap from one camera to the other
<azonenberg> you dont want to close and reopen the stream, initialize everything again, etc in your app
<azonenberg> you just want to poke the mux
<azonenberg> And have the kernel driver copy your settings to the other cam
<azonenberg> Right?
<DocScrutinizer05> err
<DocScrutinizer05> I want a gstreamer chain to just work
<azonenberg> As in, why not pretend it's one camera with a PTZ
<azonenberg> have a separate device for the PTZ / mux
<azonenberg> then have the rest of the system think it's one camera
<DocScrutinizer05> without the need to have special gstreamer video source plugins that know about that special ioctl
<azonenberg> You dont, you have a separate shell script etc you run that pokes the ioctl
<azonenberg> and otherwise just run the chain on one camera
<DocScrutinizer05> well, sounds awkward
<DocScrutinizer05> why would I care about that mux? I'm not really interested in its existence even
<azonenberg> Why would you pretend you have two cameras if it's only one bus?
<DocScrutinizer05> I don't care if the two cam modules share one interface or have dedicated own interfaces
<azonenberg> That's like having a separate ethernet interface for home and work LANs
<azonenberg> and have it determine which cable you plugged in somehow
<DocScrutinizer05> CSI is no plug&play bus
<azonenberg> you select who you want to talk to, the rest of the system has one ip stack
<DocScrutinizer05> and the two cam modules not even are guaranteed to have any major similarity in their parameters and properties
<DocScrutinizer05> I'm not even interested in whether they are connected via CSI or USB or whatever
<DocScrutinizer05> from a userland perspective they are two pretty much independant devices
firebird has joined ##openfpga
<DocScrutinizer05> with a single strange property that they are mutually exclusive use
firebird is now known as Guest33599
<DocScrutinizer05> in this particular OMAP3 platform, this might chahge when moving to OMAP5 which has 3 CSI interfaces iirc
<DocScrutinizer05> making those two cameras one device API would create atrificial diferences in system API between a platform that uses mux and a platform that has dedicated interfaces
<DocScrutinizer05> and that difference would need patches in *all* userland programs code
<DocScrutinizer05> anyway my point is: no DT (nor any other) hw description ever can be both same time: generic and comprehensive/complete. You always will have to deal with the niche cases in specialized driver code
<DocScrutinizer05> to get a generic complete DT is as futile an effort as the semantic web
<DocScrutinizer05> as soon as you think you got a complete set of elements in your language, some other EE comes up with a new nifty way to do "CSMA/CD over PC speaker"
<DocScrutinizer05> or "power via NFC field" - all hail to layering violations
<DocScrutinizer05> DT is fine for a limited world of relatively similar platforms, say ISA PCs for example
<DocScrutinizer05> on embedded it starts to fail pretty easily
<DocScrutinizer05> same for servers most likely, at least the new lean ones
<DocScrutinizer05> what you gonna do when your "BIOS" actually is your GPU firmware?
* azonenberg would rather not have a GPU that needs firmware at all
<azonenberg> or a GPU in general
<azonenberg> on a server
tecepe has quit [Remote host closed the connection]
<DocScrutinizer05> sure. But that's what you get when you buy a raspi, no?
<azonenberg> Which is why i dont use pi's :p
Guest33599 has quit [Remote host closed the connection]
<felix_> rvense, balrog: did your hackerspaces get ticket tokens for the 33c3 by now?
<rvense> felix_: no :(
<felix_> ok, when i have feedback from balrog too, i'll poke the person again who might get you tokens and also try to find a solution for rqou
<rvense> thank you!
<qu1j0t3> hey balrog
* qu1j0t3 isn't stalking honest
<balrog> hey qu1j0t3
<balrog> LOL
<qu1j0t3> we just seem to end up in the SAME PLACES
<balrog> you only share 5 channels with me so no ;)
digshadow has joined ##openfpga
tecepe has joined ##openfpga
tecepe has quit [Ping timeout: 260 seconds]
tecepe has joined ##openfpga
_whitelogger has joined ##openfpga
tecepe has quit [Ping timeout: 248 seconds]
dingbat has joined ##openfpga
reportingsjr has joined ##openfpga
tecepe has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tecepe has quit [Remote host closed the connection]
digshadow has quit [Ping timeout: 248 seconds]
m_w has quit [Quit: leaving]