Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 12/01/2014 09:31 PM, Mark Brown wrote: On Mon, Dec 01, 2014 at 11:07:06AM +0200, Tomi Valkeinen wrote: On 29/11/14 13:59, Mark Brown wrote: Reviewed-by: Mark Brown broo...@kernel.org Thanks. And just to be sure, that's ok, we can merge these in the next merge window? Yes. but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit. Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup. I really want to see people making an effort to make code shareable here - I think one of the reasons nobody is upstreaming any of their code is that there's nothing generic in place to handle generic tasks so people just look at their code, think it's too much of a device specific hack and think they'll get back to looking at it later. If this is a sensible set of callbacks to have to pass configuration around let's make that discoverable without requiring people to look through the OMAP drivers. Ok, I'll make the API more generic after this merge window and maybe move omap-hdmi-audio under sound/soc/generic and rename it. These changes should still be merged under fbdev because of changes to the API header. Cheers, Jyri -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On 29/11/14 13:59, Mark Brown wrote: On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio I guess I'm OK with these so Reviewed-by: Mark Brown broo...@kernel.org Thanks. And just to be sure, that's ok, we can merge these in the next merge window? but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit. Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Mon, Dec 01, 2014 at 11:07:06AM +0200, Tomi Valkeinen wrote: On 29/11/14 13:59, Mark Brown wrote: Reviewed-by: Mark Brown broo...@kernel.org Thanks. And just to be sure, that's ok, we can merge these in the next merge window? Yes. but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit. Yep, if I'm not mistaken I did suggest that to Jyri at some point. We can continue working on that, but I'd rather not do anything big on that front before there is some other SoC that has the same setup. I really want to see people making an effort to make code shareable here - I think one of the reasons nobody is upstreaming any of their code is that there's nothing generic in place to handle generic tasks so people just look at their code, think it's too much of a device specific hack and think they'll get back to looking at it later. If this is a sensible set of callbacks to have to pass configuration around let's make that discoverable without requiring people to look through the OMAP drivers. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio I guess I'm OK with these so Reviewed-by: Mark Brown broo...@kernel.org but like I said in reply to the patch adding the new driver I think we're going to want to generalize this a bit. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 25/11/14 20:10, Mark Brown wrote: On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote: On 24/11/14 19:39, Mark Brown wrote: The whole series is about HDMI audio, not video. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner. Can you please apply them, I'll try to get round to reviewing the audio bits soon but either these will need applying if the rest of it's OK or if there does turn out to be a problem they cut down on the size of the series. I really do want to read it closely, but hopefully by the weekend. Ok, I've picked the following patches: OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 24/11/14 19:39, Mark Brown wrote: OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different. I was vague as I don't have the details. I don't know much about the audio side, except from the users side. Jyri can perhaps fill in the details. But a proper review for sound/ side would be appreciated. For what it's worth, I can say from a user's perspective that with this series the OMAP HDMI audio finally seems to work so that I'm satisfied with it. While there's still things to improve, it works and I can keep it enabled in the kernel while developing the video side and it doesn't get on my way. The whole series is about HDMI audio, not video. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner. And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev? I don't particularly _want_ to apply these via fbdev, but I think it's the easiest way. Most of the files touched are in drivers/video/, so hopefully merging via fbdev reduces the chances of conflicts. And this needs your ack before it can be merged via fbdev tree. Until you've said that you're fine getting this via fbdev, we don't know how this will be merged, and I can't create dependencies to fbdev. This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at Well, yes, I see your point. And I agree that patches that the rest of the series does not depend on should normally be applied individually if the series starts getting multiple revisions (although even those patches could cause conflicts if the rest of the patches touch code nearby). But that's not the case here, as all the patches are needed to get a working HDMI audio. least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting). Yes, lack of communication was my mistake. In any case, how do you want to proceed? As I said, I very much would like to get this into the next merge window and from my point of view the current versions looks good. If you find something to be fixed in the sound/ side, and you're fine with merging this via fbdev, I can start merging the earlier patches in the series so that the next revision is easier to review. But the merge window is getting close. If you find something very wrong with the series, we can skip this merge window. But if there are only issues that can be easily fixed with follow-up patches, I'd rather merge this revision than do more full review rounds. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote: On 24/11/14 19:39, Mark Brown wrote: The whole series is about HDMI audio, not video. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. My point was, there's no particular reason to apply those patches individually. It's an independent series, about HDMI audio, and applying only some of the earlier patches does not improve the kernel in visible manner. Can you please apply them, I'll try to get round to reviewing the audio bits soon but either these will need applying if the rest of it's OK or if there does turn out to be a problem they cut down on the size of the series. I really do want to read it closely, but hopefully by the weekend. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 21/11/14 18:14, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote: On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). But in what way is it broken and how did this happen? Why are none of I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point. As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach. the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. The whole series is about HDMI audio, not video. The main HDMI driver resides in the fbdev directory, as the video side is the master here, and it contains the code to access the registers (including audio related registers). The sound/ part in this series acts as a logic between the asoc and the low level HDMI driver. This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work). And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees. So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 21/11/14 18:38, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. I agree all these should be studied and worked further. However, I would still like to merge this series in the next merge window: a) The series does fix the OMAP HDMI audio, so that users can actually use it. b) The series does make the driver model much better, so that I can actually be bothered to keep it enabled (earlier, even when it more or less worked, it was too much hassle when doing development using modules). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 06:38 PM, Mark Brown wrote: On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. In the discussion we recognized three modes of operation, a) try to keep audio device always operational even if audio is not going anywhere (cable is disconnected or video mode does not support audio) b) remove the audio device when audio is not available c) disable audio device if audio is not available and abort any ongoing stream when audio becomes unavailable d) force pause on the stream when audio is not available The implementation in the patches follows mode c) and in my mind it makes the most sense. The mode is not carved into stone by the current implementation and it can be changed if we decide so. I see no point in keeping the hdmi audio completely broken until we collectively decide on how all HDMI audio devices should behave. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. The idea of the patch set is to restore the old hdmi audio functionality in a form that is easier to use and maintain. Additional functionality can be added later. For instance restricting the allowed sample rates etc. based EDID Short Audio Descriptors. Best regards, Jyri -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On Mon, Nov 24, 2014 at 10:18:31AM +0200, Tomi Valkeinen wrote: On 21/11/14 18:14, Mark Brown wrote: But in what way is it broken and how did this happen? Why are none of I don't have a clear answer, but it probably involves lack of use, and buggy and hard to use implementation. Things have changed around the original HDMI audio implementation, and it stopped working at some point. As the original implementation was found rather lacking, and with some fundamental issues, it was deemed better to have a fresh approach. OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different. the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. The whole series is about HDMI audio, not video. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. This series only touch the parts about HDMI audio, so the fixes early on don't really fix anything without the rest of the series (as the current HDMI audio doesn't work). And in any case, I don't like applying individual patches from a series. Usually that just complicates things. If I would apply some of the early patches to fbdev, then this series would no longer work on plain mainline kernel, and would instead depend on fbdev tree. The situation But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev? would be ever worse if you'd also pick some of the audio patches to sound tree, creating a dependency to two subsystem trees. So if there's no particular important reason to pick patches from a series, I rather keep it as a whole to simplify merging and testing. This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting). signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote: The series looks good to me, and works for me. Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches. I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells. As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it. With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 01:23 PM, Mark Brown wrote: On Thu, Nov 20, 2014 at 12:59:44PM +0200, Tomi Valkeinen wrote: The series looks good to me, and works for me. Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches. I've not reviewed it yet and I'm still seeing some fairly basic discussion between Jiri and Jean-Francois about approaches to integrating HDMI which seem to have ground to a halt (I've not been reading them in any detail). The fact that we're getting no sharing at all between all the different HDMI devices people are supporting and very limited dialogue between them is really setting off alarm bells. OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The issue about generic HDMI codec, that Jean-Francois (and soon me) is trying to solve - applies to the cases where a generic cpu-dai is connected to an external HDMI encoder with i2s (or s/pdif, unfortunately do not have such HW). In these cases the structure of the ASoC setup resembles closely the usual pattern of ASoC cards. The main difference is just that the codec IP also handling the video and there are no mixers, etc. I am currently trying to find the common denominator between tda998x and SiI9022 HDMI encoder chips to come up with a generic solution for the external HDMI encoder case. However, this work is completely separate to the omap-hdmi-audio and its review should not be delayed because of the hdmi codec work. Best regards, Jyri As far as I can tell in order to figure out what to do with all this HDMI stuff I'm going to need to go to square one, get an overview of the hardware that's out there for myself and try to work out what to do with it. With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. (Sorry, I forgot to comment this part.) The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). Another target was to make configuring the audio as simple as possible. Because everything needed for HDMI audio is always there if the video side is correctly configured, there should be no need for any additional configuration (in DT or otherwise) to get the audio working. Now simply selecting omap-hdmi-audio is enough. There is no complex cross dependencies to the video side any more, the audio driver simply does find its device if the HDMI video driver is not probed. But indeed, in functional sense the whole series - apart from the couple of fixes in the beginning - is just moving the code around. Best regards, Jyri -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote: On 11/21/2014 01:23 PM, Mark Brown wrote: With this specific series I also need to figure out what all the video side is about (like I said earlier a lot of the patches look like they're supposed to be simple fixes for the video code not terribly closely tied to the rest of the series but none of them are getting applied) and what the end goal is beyond mechanically moving code. The end goal of this series is to fix OMAP HDMI audio, that got broken couple of releases ago. At the same time I cleaned up the old complex scheme to make the connection between the video and audio parts and allow multiple HDMI devices (DSS side is not ready for this yet, but audio side is). But in what way is it broken and how did this happen? Why are none of the patches which look like they're supposed to be bug fixes early on in the series getting applied? I had thought this was just a lack of interest on the video side but it seems there's some other problems since the series has apparently been discussed off-list and still it's just as big as it was initially. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Fri, Nov 21, 2014 at 02:10:11PM +0200, Jyri Sarha wrote: OMAP HDMI audio is fundamentally different to the case on Armada or on BBB. In omap the whole HDMI IP is integrated to the SoC and there really is no codec in the ASoC sense. The the cpu-dai transmits the audio directly to hdmi wire and there is no i2s bus involved. So this case should not be mixed with the patches Jean-Francois working on. The code is also orthogonal in that sense that the latest omap-hdmi-audio uses the generic dymmy codec. The discussion seemed to be about what to do with unplugged connections which isn't what you're talking about there and does seem like an area where we should at least be aiming for common behaviour even if not a common implementation. There's also all the stuff about parsing EDIDs for capabilities which would seem to be related to that but seems to have gone off into the weeds. signature.asc Description: Digital signature
Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
Hi Mark, On 13/11/14 10:05, Tomi Valkeinen wrote: Hi Mark, On 13/11/14 00:23, Mark Brown wrote: On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers. So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all Sorry for the lack of communication. We've been discussing this series on irc. It's been mostly about how to manage the device/driver split between drivers/video/ and sound/ sides. that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here? The series is all audio in terms of functionality. The first few patches could probably be merged independently, but I've wanted this whole OMAP HDMI audio rewrite to be in one series. I'll start testing this latest series, and I hope we can merge it for the next merge window so that we'll finally get the OMAP HDMI audio working. I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). The series looks good to me, and works for me. Do you have any comments for the sound/ parts? If not, I can merge this series via fbdev tree, and for that I'd like your ack on the sound/ patches. Tomi signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, 13 Nov 2014 17:44:38 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Same for me, but checking the audio capability is done on audio streaming start only. Hmm, I understood you have option a)? You said I even let audio streaming start when the HDMI cable is disconnected. The option a) is the one of the patch, but I am moving towards option c). With audio support is not available I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end. What I was saying is: when the cable is connected, all audio/video parameters are known. Then, when the cable is disconnected, there is no reason, a priori, to change these parameters, and audio/video streaming may continue. The problem might be raised later when an other monitor with different parameters will be connected. So to clarify, our driver only has audio support available if: - we successfully read EDID - EDID shows it's a HDMI monitor - EDID shows it has audio support for the format we support (this we don't actually do yet) Otherwise we default to DVI, which means no audio. If, at any point, the situation changes to no audio support available, the audio playback is aborted and starting new audio playback fails. [snip] So, to summarize, you need the information 'audio support available' on the audio side. It should not be difficult to export a function in the generic HDMI driver for this job. This function would have the following arguments: - device (child device of the HDMI transmitter) - pin (output widget name) - status (enable/disable) and would: - set the pin status so that the HDMI output would be included or not in the audio path, and - abort audio streaming on disabling audio. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
Hi Mark, On 13/11/14 00:23, Mark Brown wrote: On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers. So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all Sorry for the lack of communication. We've been discussing this series on irc. It's been mostly about how to manage the device/driver split between drivers/video/ and sound/ sides. that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here? The series is all audio in terms of functionality. The first few patches could probably be merged independently, but I've wanted this whole OMAP HDMI audio rewrite to be in one series. I'll start testing this latest series, and I hope we can merge it for the next merge window so that we'll finally get the OMAP HDMI audio working. I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. Tomi signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.html and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is useful. I even let audio streaming start when the HDMI cable is disconnected. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
Hi, On 13/11/14 11:17, Jean-Francois Moine wrote: On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.html Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA. The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function. So, correct me if I'm wrong, but I think this is the fundamental difference: In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null. In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... Tomi signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/13/2014 12:00 PM, Tomi Valkeinen wrote: Hi, On 13/11/14 11:17, Jean-Francois Moine wrote: On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: ... and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? There was the 4th option: the driver forcing pause on the pcm when the cable is disconnected or screen is blanked and resuming it automatically when the picture is back. But I think that is maybe too hackish solution. Considering the big picture, including the userspace. I think we would need some way to tell the userspace when the HDMI device is available. The problem is the same for both a and c cases. Maybe a read only alsa mixer could be used for that. Cheers, Jyri Currently, the OMAP HDMI version does c). It's the easiest solution for us. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... -- 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: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, 13 Nov 2014 12:00:41 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA. The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function. So, correct me if I'm wrong, but I think this is the fundamental difference: In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null. In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible. When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? Such changes occur only when the HDMI output device (TV) is replaced by an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland... So, no, actually, once streaming is started, no information go from the HDMI transmitter to the CODEC. - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? Bug in my patch: audio playback will be rejected if there will be no audio support. useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Same for me, but checking the audio capability is done on audio streaming start only. When the HDMI output device is disconnected, the video and audio outputs don't need to be changed. I often switch off my TV set when I will not use my computer for a while, letting the computer itself running. When I get back and switch on back the TV set, video and audio are still there. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows. BTW, you are talking about video modes without audio support. What are you thinking about? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 13/11/14 17:00, Jean-Francois Moine wrote: When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection. What does started mean here? tda998x device/driver has been probed? The reason for the above is probably to handle hotplug? I.e. tda998x needs to be enabled always to detect HPD? Usually for OMAP, the HPD detection happens outside the HDMI IP. Thus the HDMI IP is turned fully off when the video is disabled. I believe tda998x could be used the same way, if the HPD pin is connected to a SoC GPIO instead of tda998x. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? Such changes occur only when the HDMI output device (TV) is replaced by The user can change the video mode at any time. The audio data packets are sent in the video blanking intervals, and if those intervals are too short, the video mode cannot support audio. If I'm not mistaken, officially only certain video modes defined in the HDMI spec support audio. an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland... HPD (which usually equals to cable change, but not always) is handled. a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Same for me, but checking the audio capability is done on audio streaming start only. Hmm, I understood you have option a)? You said I even let audio streaming start when the HDMI cable is disconnected. With audio support is not available I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end. So to clarify, our driver only has audio support available if: - we successfully read EDID - EDID shows it's a HDMI monitor - EDID shows it has audio support for the format we support (this we don't actually do yet) Otherwise we default to DVI, which means no audio. If, at any point, the situation changes to no audio support available, the audio playback is aborted and starting new audio playback fails. AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows. True. But the HDMI transmitter can know if the audio absolutely cannot be played, because there's no cable, or because the monitor says it doesn't support audio, or because the video mode cannot support audio, or because the HDMI output stream is disabled. So the question is, do we want/need to inform the userspace about those situations? Should a HDMI transmitted always look like it can play audio, even if it's clear it cannot? Again, I know very little about audio, but I think it would be nice that if I open the sound configuration window on my desktop, it'd show me that the HDMI audio device is disabled (because there's no cable). But perhaps that's a separate feature. We could have HDMI audio device always there and functional, but the desktop could get the information about HDMI cable connection some other way (DRM). And if the cable is not there, it knows that this particular audio device is also out, and thus doesn't show it (even if it's functional). BTW, you are talking about video modes without audio support. What are you thinking about? This I covered above. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: https://github.com/jsarha/linux.git omap-hdmi-audio It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers. Changes since v7: - Squash: - OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device - into OMAPDSS: Remove all references to obsolete HDMI audio callbacks Changes since v6: - ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support - Fix Kconfig help text - Remove #include sound/simple_card.h - Use snd-soc-dummy codec instead of hdmi-audio-codec - Add: OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() - Add: OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter - Add: OMAPDSS: omapdss.h: Remove audio_state member of struct omap_dss_device - OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio - Register omap-hdmi-audio with PLATFORM_DEVID_AUTO - OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio - Register omap-hdmi-audio with PLATFORM_DEVID_AUTO - Add: OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback Jyri Sarha (19): OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio ASoC: omap: Remove obsolete HDMI audio code and Kconfig options OMAPDSS: Remove all references to obsolete HDMI audio callbacks OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback .../fbdev/omap2/displays-new/connector-hdmi.c | 99 - .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- drivers/video/fbdev/omap2/dss/Kconfig |7 - drivers/video/fbdev/omap2/dss/hdmi.h | 38 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 269 +++-- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |4 - drivers/video/fbdev/omap2/dss/hdmi5.c | 265 ++--- drivers/video/fbdev/omap2/dss/hdmi5_core.c |9 +- drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 - drivers/video/fbdev/omap2/dss/hdmi_common.c|2 - drivers/video/fbdev/omap2/dss/hdmi_wp.c| 16 +- include/sound/omap-hdmi-audio.h| 43 +++ include/video/omapdss.h| 40 -- sound/soc/omap/Kconfig | 26 +- sound/soc/omap/Makefile|6 +- sound/soc/omap/omap-hdmi-audio.c | 407 sound/soc/omap/omap-hdmi-card.c| 87 - sound/soc/omap/omap-hdmi.c | 364 - sound/soc/omap/omap-hdmi.h | 38 -- 20 files changed, 781 insertions(+), 1011 deletions(-) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h -- 1.7.9.5 -- 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 v7.1 00/19] Rework OMAP4+ HDMI audio support
On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers. So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here? signature.asc Description: Digital signature
