**** BEGIN LOGGING AT Sun Apr 30 03:00:02 2017
Apr 30 19:38:37 <kremlin> zmatt: hey
Apr 30 21:01:23 <ArunMKumar> anybody tried yocto project on BBB here?
Apr 30 23:20:12 <zmatt> kremlin: yo
Apr 30 23:59:20 <kremlin> zmatt: have you ever played with the am335x's EDMA?
Apr 30 23:59:29 <kremlin> specifically with regards to how the sdmmc controller plugs into it
May 01 00:03:42 <zmatt> I've used EDMA for various applications, I don't *think* I've used it with the mmc controller yet, although I wouldn't really expect any major surprises there
May 01 00:08:33 <zmatt> do you have specific questions about it?
May 01 00:09:31 <kremlin> im wondering if my understanding of it is correct:
May 01 00:09:53 <kremlin> you have a number of channels, each associated with an intr
May 01 00:10:06 <zmatt> do you have my edma header?
May 01 00:10:10 <kremlin> i don't
May 01 00:10:25 <kremlin> our edma driver is already written, i am looking to plug into it
May 01 00:10:26 <kremlin> hold on
May 01 00:10:44 <zmatt> nevertheless, my header contains a lot of notes and remarks w.r.t. how edma works
May 01 00:10:45 <kremlin> http://ce.gl/edmavar.h
May 01 00:10:51 <kremlin> that's what i'm working with
May 01 00:10:53 <kremlin> oh!
May 01 00:10:55 <kremlin> please share
May 01 00:12:01 <zmatt> hold on
May 01 00:12:11 <kremlin> much appreciated
May 01 00:25:21 <zmatt> https://liktaanjeneus.nl/edma3.h.html   (and link to edma3-tc.h.html at the top)
May 01 00:25:54 <zmatt> non-html versions are there too, just remove the suffix, but my custom syntax highlighting rules help with my slightly strange C++ code ;)
May 01 00:26:58 <zmatt> edma3-tc contains a simple description of what an edma transfer does, concretely
May 01 00:29:25 <zmatt> edma3.h has a large block of comments if you scroll a bit down
May 01 00:34:16 <zmatt> wow that edmavar.h you got certainly managed to (over)simplify things...
May 01 00:35:29 <zmatt> I'm guessing it uses a 1:1:1 mapping of dma channel -> job ("PaRAM slot") -> irq channel
May 01 00:35:30 <kremlin> awesome, thanks
May 01 00:35:33 <kremlin> yeah, it's spartan
May 01 00:35:41 <kremlin> yeah
May 01 00:36:12 <zmatt> sounds like fun if e.g. you'd want to reliably stream audio
May 01 00:36:51 <kremlin> i'm trying to move our omap sdmmc device driver from PIO -> DMA
May 01 00:36:58 <kremlin> so it won't be slow as molases
May 01 00:37:29 <zmatt> have a link to the implementation-side of this edma driver?
May 01 00:38:36 <zmatt> I'm wondering what edma_trig_xfer_by_dev does exactly
May 01 00:40:56 <kremlin> zmatt: https://ce.gl/edma.c
May 01 00:43:11 <zmatt> btw "shadow region" is what my headers call a client... I've renamed a few things like that where their official names make absolutely no sense :P
May 01 00:44:26 <kremlin> there is a lot of that official names nonsense with this dma thing
May 01 00:44:29 <kremlin> EDMA vs ADMA
May 01 00:44:54 <kremlin> vs what they call edma intrs, like SDMARREQN
May 01 00:45:12 <zmatt> neither ADMA nor SDMA is an EDMA-related term
May 01 00:45:17 <kremlin> SDMARREQN appears like three times in the TRM and is never explained or defined further
May 01 00:45:19 <zmatt> SDMA doesn't exist on the am335x
May 01 00:46:12 <zmatt> ADMA is the built-in DMA that the MMC can have, but iirc none of the MMC controllers on the AM335x have one
May 01 00:46:42 <kremlin> they do according to the device tree
May 01 00:46:54 <kremlin> mmc@48060000 {
May 01 00:46:55 <kremlin>    compatible = "ti,omap4-hsmmc";
May 01 00:46:57 <kremlin>    ti,hwmods = "mmc1";
May 01 00:46:59 <kremlin>    ti,dual-volt;
May 01 00:47:01 <kremlin>    ti,needs-special-reset;
May 01 00:47:03 <kremlin>    ti,needs-special-hs-handling;
May 01 00:47:05 <kremlin>    dmas = <0x33 0x18 0x0 0x0 0x33 0x19 0x0 0x0>;
May 01 00:47:07 <kremlin>    dma-names = "tx", "rx";
May 01 00:47:46 <zmatt> I see no ADMA
May 01 00:48:32 <zmatt> also, why are you looking at a decompiled DT instead of the sources?
May 01 00:49:02 <kremlin> is there a difference?
May 01 00:49:29 <zmatt> is there a difference between source code and disasssembly? :P
May 01 00:49:34 <kremlin> also, our fdt implementation is still shaky
May 01 00:50:09 <kremlin> i didn't think decompiled fdt files would differ from the source
May 01 00:50:23 <zmatt> you lose all symbolic references
May 01 00:50:28 <kremlin> ahh
May 01 00:50:36 <zmatt> and DT encodes no type information, so that's replaced by guesswork by the decompiler
May 01 00:50:43 <kremlin> like this: https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/Documentation/devicetree/bindings/dma/dma.txt#L90
May 01 00:50:45 <kremlin> ?
May 01 00:52:24 <zmatt> https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.25-bone4/arch/arm/boot/dts/am33xx.dtsi#L425
May 01 00:52:39 <zmatt> beware of the off-by-one... mmc1 is actually mmc0
May 01 00:52:47 <zmatt> (TI....)
May 01 00:57:26 <kremlin> nothing will ever be as bad as the framebuffer pixel bit ordering silicon bug
May 01 00:57:44 <kremlin> that guy definitely got fired
May 01 00:58:54 <zmatt> dunno, framebuffer formats are insanely confusing with inconsistent terminology
May 01 01:00:46 <zmatt> it just means you have an abgr8888 framebuffer (i.e. struct { u8 r, g, b, a; }) instead of an argb8888 (i.e. struct { u8 b, g, r, a; })
May 01 01:00:59 <zmatt> the gpu supports both iirc
May 01 01:01:09 <kremlin> iirc this one was particularly egregarious
May 01 01:01:38 <kremlin> the 24bpp ordering had it so that the r,g,b MSB bits were not contiguous with the rest of the bits
May 01 01:01:48 <zmatt> no it just swaps r and b
May 01 01:01:52 <zmatt> nothing more
May 01 01:01:54 <kremlin> oh
May 01 01:02:07 <kremlin> well, then, that was still a dumb design decision
May 01 01:02:20 <zmatt> I very much doubt it was "decision"
May 01 01:02:30 <kremlin> my display driver is stuck at 16bpp because of it
May 01 01:02:49 <zmatt> which is what you want anyway for the bbb
May 01 01:03:47 <kremlin> well, i'd like 1920x1200 @ 60hz and 24 bit color depth
May 01 01:04:03 <kremlin> but that'd involve changes to a lot of things
May 01 01:04:54 <zmatt> you think you have that memory bandwidth?  do you have a CAPE that supports 24-bit color depth? (the hdmi framer on the bbb is only wired up for 16-bit)  do have not have better use for those I/Os ?
May 01 01:05:29 <kremlin> that's what im saying, there'd need to be faster memory, better PHY transmitter, etc
May 01 01:05:44 <zmatt> a CAPE designed for 24-bit depth probably already has r and b swapped hence the issue wouldn't exist
May 01 01:05:54 <kremlin> and yeah, those i/os overlap with the eMMC NAND pins
May 01 01:05:59 <zmatt> no
May 01 01:06:17 <zmatt> they don't
May 01 01:07:20 <kremlin> http://elinux.org/images/0/03/P8Header.PNG
May 01 01:07:28 <kremlin> see e.g. pin 17
May 01 01:07:39 <kremlin> mode 1 is lcd, mode 2 mmc
May 01 01:08:02 <kremlin> (i could be completely wrong here)
May 01 01:08:05 <kremlin> whihc would be nice
May 01 01:08:22 <zmatt> mmc1_dat3 is also available on pin 6 and that's the one used
May 01 01:08:41 <zmatt> see my pins spreadsheet
May 01 01:08:57 <zmatt> https://goo.gl/Jkcg0w (mainly the P9 and P8 tabs)
May 01 01:09:04 <kremlin> oh snap, i didn't realize pins could be available in more than 1 location
May 01 01:09:08 <kremlin> i need to patch something
May 01 01:09:31 <zmatt> in some cases many locations
May 01 01:09:40 <zmatt> see the Signals tab of aforementioned spreadsheet
May 01 01:18:16 <zmatt> btw here's the device tree declarations for the mmc controllers in my own dt sources -> https://liktaanjeneus.nl/l3.dtsi.html#mmc0
May 01 01:21:45 <kremlin> thanks
May 01 01:23:34 <zmatt> I'm not sure why mmc0 is marked as dual-volt, it isn't really... at least not in the sense of being able to change voltage without pcb change
May 01 01:25:26 <zmatt> (the am335x determines at power-on-reset whether the vddhv banks are 1.8V or 3.3V)
May 01 01:31:11 <zmatt> btw, although on the am335x each gpio belongs to only one pin (hence gpio number is usable to uniquely identify pins that belong to the subset which support gpio operation), this is not true on TI SoCs in general
May 01 01:33:49 <kremlin> ah, yeah, i deduced that
May 01 01:35:08 <zmatt> index into pinmux array is the best way to identify pins, and is what I call pin number
May 01 01:35:34 <zmatt> a minor gotcha is that some omaps have two pinmux arrays, one in the wakeup domain and one in the core domain :/
**** ENDING LOGGING AT Mon May 01 03:00:00 2017