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: [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: [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
