Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio
On 17 September 2014 06:40, Jyri Sarha wrote: > Changes since v2: > - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock" > - Some minor cleanups > > The code has a functional dependency to: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html > > Without the above patch the audio card does not probe. > > The code has been rebased on top of Linux 3.17-rc5. The patches > bellow, the above dependency, and couple of commits to add BBB HDMI audio > support to omap2plus_defconfig can be pulled from: > > https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio How do you intend to get this merge, sending patchsets like this without indication to maintainers on a merge strategy is kinda messy. I'm not sure how maintained tilcdc is. Dave. > > Cheers, > Jyri > > Jyri Sarha (5): > clk: ti: add "ti,gpio-gate-clock" controlled clock > drm/tilcdc: Add I2S HDMI audio config for tda998x > ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S > bus > ASoC: davinci: HDMI audio build for AM33XX and TDA998x > ARM: dts: am335x-boneblack: Add HDMI audio support > > .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ > .../bindings/sound/davinci-evm-audio.txt |6 +- > arch/arm/boot/dts/am335x-boneblack.dts | 52 + > drivers/clk/ti/Makefile|2 +- > drivers/clk/ti/gpio.c | 202 > > drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- > sound/soc/davinci/Kconfig | 12 ++ > sound/soc/davinci/davinci-evm.c| 82 +++- > 8 files changed, 395 insertions(+), 6 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt > create mode 100644 drivers/clk/ti/gpio.c > > -- > 1.7.9.5 > > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 0/9] drm: tilcdc driver fixes
On 3 July 2014 06:38, Ezequiel García wrote: > On 02 Jul 02:08 PM, Dave Airlie wrote: >> On 2 July 2014 12:31, Darren Etheridge wrote: >> > On 07/01/2014 06:39 PM, Guido Martínez wrote: >> >> >> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: >> >>> >> >>> [snip] >> >>> >> >>> Otherwise I think this is a good and useful patch series. >> >> >> >> It that a Tested-by tag? :) >> > >> > >> > Sure - I would prefer that the WARN_ON was silenced when the tilcdc module >> > is removed, but the series adds improvements over what is there now. I >> > have >> > tested it across a few variants of AM335x boards and attached display >> > hardware in both module form and built-in to the kernel, therefore: >> > >> > Tested-by: Darren Etheridge >> >> Has someone gathered that tags and put these in a git tree by any chance? >> > > I don't think anyone has. Is that a problem? > > If you need a pull request with these, I can prepare something in bitbucket. > Would that work you? I've picked them up manually now, so should be all fine. Thanks, Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND 0/9] drm: tilcdc driver fixes
On 2 July 2014 12:31, Darren Etheridge wrote: > On 07/01/2014 06:39 PM, Guido Martínez wrote: >> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: >>> >>> [snip] >>> >>> Otherwise I think this is a good and useful patch series. >> >> It that a Tested-by tag? :) > > > Sure - I would prefer that the WARN_ON was silenced when the tilcdc module > is removed, but the series adds improvements over what is there now. I have > tested it across a few variants of AM335x boards and attached display > hardware in both module form and built-in to the kernel, therefore: > > Tested-by: Darren Etheridge Has someone gathered that tags and put these in a git tree by any chance? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] TI LCDC DRM driver
On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote: > Updated version of DRM driver for TI LCD Controller. Since the initial > version of the patch, which only supported TFP410 DVI output, I've added > an output driver for LCD panels (for example, LCD3 or LCD7 cape for the > beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI > encoder (via i2c encoder-slave output driver). > > At this point, I think the basic lcdc drm driver plus TFP410 DVI output > (first patch) is in reasonable shape (barring potential rename, if lcdc > is too generic of a name... but I was not feeling creative enough yet to > pick a new name). I'd like at least tilcdc :-) Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] backlight: initialize struct backlight_properties properly
On Mon, May 21, 2012 at 8:24 AM, Corentin Chary wrote: > In all these files, the .power field was never correctly initialized. > > Signed-off-by: Corentin Chary > --- > drivers/gpu/drm/i915/intel_panel.c | 1 + > drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 + I've taken these two hunks into drm-next. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
> As long as SOC vendors keep producing wildly different architectures > besides the core CPU we'll have this problem. Denying the reality won't > make that problem go away either. And device tree won't stop those > vendor from still trying to do things differently (better?) because they > are not constrained by having to ensure this single proprietary software > stack still boot. So you are saying the only way to get the Linux ARM shit cleaned up is to hope Microsoft succeeds in making Windows a success on ARM? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: > Adding support for common EDID parsing in kernel. > > EDID - Extended display identification data is a data structure provided by > a digital display to describe its capabilities to a video source, This a > standard supported by CEA and VESA. > > There are several custom implementations for parsing EDID in kernel, some > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > parsing of EDID should be done in a library, which is agnostic of the > framework (V4l2, DRM, FB) which is using the functionality, just based on > the raw EDID pointer with size/segment information. > > With other RFC's such as the one below, which tries to standardize HDMI API's > It would be better to have a common EDID code in one place.It also helps to > provide better interoperability with variety of TV/Monitor may be even by > listing out quirks which might get missed with several custom implementation > of EDID. > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > > This patch tries to add functions to parse some portion EDID (detailed timing, > monitor limits, AV delay information, deep color mode support, Audio and VSDB) > If we can align on this library approach i can enhance this library to parse > other blocks and probably we could also add quirks from other implementation > as well. > If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] TI DMM-TILER driver
On Fri, Dec 17, 2010 at 5:02 AM, David Sin wrote: > On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote: >> As far as I can tell, both DMM and GEM at a high level manage objects >> in video memory. The IOMMU that you have on the Omap hardware seems >> to resemble the GART that sits between PC-style video cards and main >> memory. >> >> I don't know any details, but google quickly finds >> http://lwn.net/Articles/283798/ with a description of the >> initial GEM design. My main thought when looking over the >> DMM code was that this should not be tied too closely to a >> specific hardware, and GEM seems to be an existing abstraction >> that may fit what you need. >> >> Arnd > Thanks for the pointer, Arnd. I also found a nice readme file in > the gpu/drm directory, which points to a wiki and source code. > I'll read into this and get back to you. I get the impression with the ARM graphics, that you just have a lot of separate drivers for separate IP blocks all providing some misc random interfaces to userspace where some binary driver binds all the functionality together into a useful whole, which seems like a really bad design. Generally on x86, the tiling hw is part of the GPU and is exposed as part of a coherent GPU driver. I'm just wonder what the use-cases for this tiler are and what open apps can use it for? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
