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]