[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
On Fri, May 22, 2015 at 04:05:22PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 16:02:13 +0200, > Takashi Iwai wrote: > > OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, > > so no big problem. > > Now the rebased branch is pushed. > > I also merged this branch now to for-next branch, so that it'll be > tested through linux-next. Thanks! -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
At Fri, 22 May 2015 16:02:13 +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 15:00:10 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > > > At Fri, 22 May 2015 14:53:31 +0100, > > > Russell King - ARM Linux wrote: > > > > > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > > > At Fri, 22 May 2015 14:15:35 +0100, > > > > > Russell King - ARM Linux wrote: > > > > > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > > > Add a helper for the EDID like data structure, which is > > > > > > > > typically passed > > > > > > > > from a HDMI adapter to its associated audio driver. This > > > > > > > > informs the > > > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > > > > > As far as I can tell people are fairly happy with the > > > > > > > implementation > > > > > > > here and unless I'm missing something are definitely happy with > > > > > > > the > > > > > > > interface. If that's the case can we get this into -next? > > > > > > > There's a > > > > > > > lot of interest in HDMI right now (which is great) and this would > > > > > > > be > > > > > > > helpful for that, it seems like even if there are issues with the > > > > > > > implementation it would be worth merging as is so we can start > > > > > > > adding > > > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > > > > > From an interface point of view: > > > > > > > > > > > > > > Reviewed-by: Mark Brown > > > > > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > > > planning on the audio driver itself being merged just yet as we > > > > > > still > > > > > > need to properly hammer out the differences between the AHB audio > > > > > > (for > > > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > > > digesting all backlogs now. > > > > > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > > > series, and merge that point into my for-next and/or publish it as a > > > > > > separate sub-branch... whatever people want, just let me know. > > > > > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > > > Then I can provide a branch that can be merged for the rest drm > > > > > stuff. > > > > > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > > > v4.1-rc1, thanks. > > > > > > I applied them on top of -rc4, I suppose it's OK? > > > > It is, but what it means is that I'll keep my copy of the patches in my > > tree rather than pulling your tree. Having branches spread on different > > start points makes it difficult to generate a patch series from the git > > tree - which is something I continue to do for the SolidRun iMX6 platforms > > (publishing it as separate patches, tarball of those patches and a combined > > patch.) > > > > As I say, it doesn't matter that much, I can just keep my copies of the > > patches, and when this stuff gets rebased to 4.2-rc1, git rebase should > > eliminate them automatically. > > OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, > so no big problem. Now the rebased branch is pushed. I also merged this branch now to for-next branch, so that it'll be tested through linux-next. Takashi
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
At Fri, 22 May 2015 15:00:10 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 14:53:31 +0100, > > Russell King - ARM Linux wrote: > > > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > > At Fri, 22 May 2015 14:15:35 +0100, > > > > Russell King - ARM Linux wrote: > > > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > > Add a helper for the EDID like data structure, which is typically > > > > > > > passed > > > > > > > from a HDMI adapter to its associated audio driver. This informs > > > > > > > the > > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > > > here and unless I'm missing something are definitely happy with the > > > > > > interface. If that's the case can we get this into -next? There's > > > > > > a > > > > > > lot of interest in HDMI right now (which is great) and this would be > > > > > > helpful for that, it seems like even if there are issues with the > > > > > > implementation it would be worth merging as is so we can start > > > > > > adding > > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > > > From an interface point of view: > > > > > > > > > > > > Reviewed-by: Mark Brown > > > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > > planning on the audio driver itself being merged just yet as we still > > > > > need to properly hammer out the differences between the AHB audio (for > > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > > digesting all backlogs now. > > > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > > series, and merge that point into my for-next and/or publish it as a > > > > > separate sub-branch... whatever people want, just let me know. > > > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > > Then I can provide a branch that can be merged for the rest drm > > > > stuff. > > > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > > v4.1-rc1, thanks. > > > > I applied them on top of -rc4, I suppose it's OK? > > It is, but what it means is that I'll keep my copy of the patches in my > tree rather than pulling your tree. Having branches spread on different > start points makes it difficult to generate a patch series from the git > tree - which is something I continue to do for the SolidRun iMX6 platforms > (publishing it as separate patches, tarball of those patches and a combined > patch.) > > As I say, it doesn't matter that much, I can just keep my copies of the > patches, and when this stuff gets rebased to 4.2-rc1, git rebase should > eliminate them automatically. OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, so no big problem. Takashi
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
At Fri, 22 May 2015 14:53:31 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 14:15:35 +0100, > > Russell King - ARM Linux wrote: > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > Add a helper for the EDID like data structure, which is typically > > > > > passed > > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > here and unless I'm missing something are definitely happy with the > > > > interface. If that's the case can we get this into -next? There's a > > > > lot of interest in HDMI right now (which is great) and this would be > > > > helpful for that, it seems like even if there are issues with the > > > > implementation it would be worth merging as is so we can start adding > > > > users and then do any improvements to the interface in parallel. > > > > > > > > From an interface point of view: > > > > > > > > Reviewed-by: Mark Brown > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > planning on the audio driver itself being merged just yet as we still > > > need to properly hammer out the differences between the AHB audio (for > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > digesting all backlogs now. > > > > > Alternatively, I could move these two patches to the beginning of my > > > series, and merge that point into my for-next and/or publish it as a > > > separate sub-branch... whatever people want, just let me know. > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > Then I can provide a branch that can be merged for the rest drm > > stuff. > > Yep, just patches 10 and 11. If possible, please base these patches on > v4.1-rc1, thanks. I applied them on top of -rc4, I suppose it's OK? Now pushed as topic/hdmi branch of sound git tree. Let me know if anything else needed. thanks, Takashi
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
At Fri, 22 May 2015 14:15:35 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > Add a helper for the EDID like data structure, which is typically passed > > > from a HDMI adapter to its associated audio driver. This informs the > > > audio driver of the capabilities of the attached HDMI sink. > > > > As far as I can tell people are fairly happy with the implementation > > here and unless I'm missing something are definitely happy with the > > interface. If that's the case can we get this into -next? There's a > > lot of interest in HDMI right now (which is great) and this would be > > helpful for that, it seems like even if there are issues with the > > implementation it would be worth merging as is so we can start adding > > users and then do any improvements to the interface in parallel. > > > > From an interface point of view: > > > > Reviewed-by: Mark Brown > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > planning on the audio driver itself being merged just yet as we still > need to properly hammer out the differences between the AHB audio (for > iMX6) and I2S audio (for Rockchip) for this device. Sorry, I've been on vacation in the last two weeks, so slowly digesting all backlogs now. > Alternatively, I could move these two patches to the beginning of my > series, and merge that point into my for-next and/or publish it as a > separate sub-branch... whatever people want, just let me know. I'm fine to take the sound part. It's only patches 10 and 11, right? Then I can provide a branch that can be merged for the rest drm stuff. thanks, Takashi
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 14:53:31 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > At Fri, 22 May 2015 14:15:35 +0100, > > > Russell King - ARM Linux wrote: > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > Add a helper for the EDID like data structure, which is typically > > > > > > passed > > > > > > from a HDMI adapter to its associated audio driver. This informs > > > > > > the > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > > here and unless I'm missing something are definitely happy with the > > > > > interface. If that's the case can we get this into -next? There's a > > > > > lot of interest in HDMI right now (which is great) and this would be > > > > > helpful for that, it seems like even if there are issues with the > > > > > implementation it would be worth merging as is so we can start adding > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > From an interface point of view: > > > > > > > > > > Reviewed-by: Mark Brown > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > planning on the audio driver itself being merged just yet as we still > > > > need to properly hammer out the differences between the AHB audio (for > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > digesting all backlogs now. > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > series, and merge that point into my for-next and/or publish it as a > > > > separate sub-branch... whatever people want, just let me know. > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > Then I can provide a branch that can be merged for the rest drm > > > stuff. > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > v4.1-rc1, thanks. > > I applied them on top of -rc4, I suppose it's OK? It is, but what it means is that I'll keep my copy of the patches in my tree rather than pulling your tree. Having branches spread on different start points makes it difficult to generate a patch series from the git tree - which is something I continue to do for the SolidRun iMX6 platforms (publishing it as separate patches, tarball of those patches and a combined patch.) As I say, it doesn't matter that much, I can just keep my copies of the patches, and when this stuff gets rebased to 4.2-rc1, git rebase should eliminate them automatically. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 14:15:35 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > Add a helper for the EDID like data structure, which is typically passed > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > As far as I can tell people are fairly happy with the implementation > > > here and unless I'm missing something are definitely happy with the > > > interface. If that's the case can we get this into -next? There's a > > > lot of interest in HDMI right now (which is great) and this would be > > > helpful for that, it seems like even if there are issues with the > > > implementation it would be worth merging as is so we can start adding > > > users and then do any improvements to the interface in parallel. > > > > > > From an interface point of view: > > > > > > Reviewed-by: Mark Brown > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > planning on the audio driver itself being merged just yet as we still > > need to properly hammer out the differences between the AHB audio (for > > iMX6) and I2S audio (for Rockchip) for this device. > > Sorry, I've been on vacation in the last two weeks, so slowly > digesting all backlogs now. > > > Alternatively, I could move these two patches to the beginning of my > > series, and merge that point into my for-next and/or publish it as a > > separate sub-branch... whatever people want, just let me know. > > I'm fine to take the sound part. It's only patches 10 and 11, right? > Then I can provide a branch that can be merged for the rest drm > stuff. Yep, just patches 10 and 11. If possible, please base these patches on v4.1-rc1, thanks. Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > Add a helper for the EDID like data structure, which is typically passed > > from a HDMI adapter to its associated audio driver. This informs the > > audio driver of the capabilities of the attached HDMI sink. > > As far as I can tell people are fairly happy with the implementation > here and unless I'm missing something are definitely happy with the > interface. If that's the case can we get this into -next? There's a > lot of interest in HDMI right now (which is great) and this would be > helpful for that, it seems like even if there are issues with the > implementation it would be worth merging as is so we can start adding > users and then do any improvements to the interface in parallel. > > From an interface point of view: > > Reviewed-by: Mark Brown I'd be more than happy if Takashi Iwai wants to take them - I'm not planning on the audio driver itself being merged just yet as we still need to properly hammer out the differences between the AHB audio (for iMX6) and I2S audio (for Rockchip) for this device. Alternatively, I could move these two patches to the beginning of my series, and merge that point into my for-next and/or publish it as a separate sub-branch... whatever people want, just let me know. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[alsa-devel] [PATCH 10/13] sound/core: add DRM ELD helper
On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > Add a helper for the EDID like data structure, which is typically passed > from a HDMI adapter to its associated audio driver. This informs the > audio driver of the capabilities of the attached HDMI sink. As far as I can tell people are fairly happy with the implementation here and unless I'm missing something are definitely happy with the interface. If that's the case can we get this into -next? There's a lot of interest in HDMI right now (which is great) and this would be helpful for that, it seems like even if there are issues with the implementation it would be worth merging as is so we can start adding users and then do any improvements to the interface in parallel.
