Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Hi Stefan On Sun, 28 Oct 2018 at 08:31, Stefan Wahren wrote: > > Hi Dave, > > > Dave Stevenson hat am 26. Oktober 2018 um > > 19:15 geschrieben: > > > > > > Thanks Stefan. > > I've picked up your latest patches which mean I can get the driver > > loaded via the (almost) approved method. > > I do seem to still have issues with not getting the expected address > > ranges, so the driver/VPU was trying to map cached alias memory. As > > your patches only came through yesterday I haven't had a chance to dig > > through why yet. I've done a temporary hack to ensure we always map > > the uncached alias, but that can't persist. > > does it mean with DT probing it worked before and with platform change it's > broken? > Or anything else cause this regression in 4.19? Yes, probing via DT with the node under soc gave me the correct DMA addresses (uncached alias). With the platform changes I get the cached alias. Both were under 4.14. I'll try again on a later branch. > > The networking issue has been resolved :-) > > > > I've pushed where I've got to to > > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b > > It's a touch messy due to integrating in your patches in the last 24 > > hours. It needs a full rebase so that my changes are on top of yours > > rather than haphazard. > > As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree > > and jump to either that or directly on staging. I'll see where I get > > to early next week. > > Sorry, but there is no need for a quick shot against a downstream 4.14. I > assumed you make your changes against upstream linux-next + Phil's and my > patches. > > You can use https://github.com/anholt/linux/commits/bcm2835-audio until > 4.20-rc1 is out. > Using 4.14 or 4.19 doesn't make any sense to me. As an employee of Raspberry Pi Trading my first responsibilty is to them, and that means LTS releases feeding in to the downstream kernel. If these drivers can be pushed upstream then that's a win as it avoids divergence, but it is not my main goal. At least 4.19 and 4.20 aren't far apart so there are likely to be fewer differences. I had it all working on 4.14, therefore it made sense to see whether your changes allowed me to load as a platform driver. It did, but with this little niggle over cache aliases. I'll try again on a later kernel and try to get some more info. Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Hi Dave, > Dave Stevenson hat am 26. Oktober 2018 um > 19:15 geschrieben: > > > Thanks Stefan. > I've picked up your latest patches which mean I can get the driver > loaded via the (almost) approved method. > I do seem to still have issues with not getting the expected address > ranges, so the driver/VPU was trying to map cached alias memory. As > your patches only came through yesterday I haven't had a chance to dig > through why yet. I've done a temporary hack to ensure we always map > the uncached alias, but that can't persist. does it mean with DT probing it worked before and with platform change it's broken? Or anything else cause this regression in 4.19? > The networking issue has been resolved :-) > > I've pushed where I've got to to > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b > It's a touch messy due to integrating in your patches in the last 24 > hours. It needs a full rebase so that my changes are on top of yours > rather than haphazard. > As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree > and jump to either that or directly on staging. I'll see where I get > to early next week. Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches. You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out. Using 4.14 or 4.19 doesn't make any sense to me. Regards Stefan > > Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
On Thu, 18 Oct 2018 at 10:38, Stefan Wahren wrote: > > Am 18.10.2018 um 11:22 schrieb Dave Stevenson: > > On Wed, 17 Oct 2018 at 17:51, Peter Robinson wrote: > >> Drop various pieces of dead code from here and there to get rid of > >> the remaining users of VCHI_CONNECTION_T. After that we get to drop > >> entire header files worth of unused code. > >> > >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > >> snd-bcm2835 can still play analog audio just fine. > >> > > thanks and i'm fine with your patch series: > > > > Acked-by: Stefan Wahren > > > > Unfortunately this would break compilation of the downstream vchi > > drivers like vcsm [1]. Personally i don't want to maintain another > > one, because i cannot see the gain of the resulting effort. > > > > [1] - > > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > > I feel like everyone else already knows the answer but why don't we just > merge that code into staging? > >>> Dave's been working on a new VCSM service where the firmware can call > >>> back into Linux to allocate (instead of just having a permanent carveout > >>> of system memory that the firmware allocates from), and lets us make > >>> dma-bufs out of those buffers. That driver makes a no-copies v4l2 media > >>> decode driver possible, which would then let Kodi and similar projects > >>> switch from downstream kernels with closed graphics to upstream kernels > >>> with open graphics. > >>> > >>> Given that the new VCSM service is a rewrite, it's not clear to me that > >>> importing the old VCSM driver is a win. But maybe we should go raid > >>> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab > >>> the new drivers. Upstreaming the VCHI audio driver to staging has > >>> clearly been a win for it, so maybe other eyes on the new v4l2 codec > >>> could help Dave along in stabilizing it. > >> I think that makes sense as long as the firmware side changes are in > >> place so it can actually be used. > > The firmware has supported the necessary for dmabuf import since Sept 2017. > > > > The new vcsm driver currently only supports importing from other > > kernel modules as I cut it back to the bare minimum to ease > > upstreaming. To be a complete replacement of the existing then it > > needs to support userspace alloc/free/import/mmap. I did have most of > > that working, but will add it in stages. > > The codec code is working for decode but something is off for setting > > formats on encode. > > Both drivers are loading through DT at the moment as I couldn't get > > Eric's platform driver stuff working. IIRC A combination of modules > > not getting loaded and getting the appropriate coherent DMA mask set > > (being under soc in DT gives the correct mappings, but being a > > platform driver didn't). > > I'm working on these issues and i will post a proper solution soon. > > In case you need a hack in order to test your stuff, i can prepare a > branch for you. Thanks Stefan. I've picked up your latest patches which mean I can get the driver loaded via the (almost) approved method. I do seem to still have issues with not getting the expected address ranges, so the driver/VPU was trying to map cached alias memory. As your patches only came through yesterday I haven't had a chance to dig through why yet. I've done a temporary hack to ensure we always map the uncached alias, but that can't persist. > > > > I'm fire-fighting a networking issue at the moment, but hope to be > > back on codecs next week. > > Could you hold off raiding my trees until say Fri 26th Oct so I can > > ensure they are fully up to date? If I get a chance then I'll start > > the work of porting into staging before then. > > The merge window will open soon, so i don't see the need to hurry. The networking issue has been resolved :-) I've pushed where I've got to to https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b It's a touch messy due to integrating in your patches in the last 24 hours. It needs a full rebase so that my changes are on top of yours rather than haphazard. As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree and jump to either that or directly on staging. I'll see where I get to early next week. Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Am 18.10.2018 um 11:22 schrieb Dave Stevenson: > On Wed, 17 Oct 2018 at 17:51, Peter Robinson wrote: >> Drop various pieces of dead code from here and there to get rid of >> the remaining users of VCHI_CONNECTION_T. After that we get to drop >> entire header files worth of unused code. >> >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that >> snd-bcm2835 can still play analog audio just fine. >> > thanks and i'm fine with your patch series: > > Acked-by: Stefan Wahren > > Unfortunately this would break compilation of the downstream vchi > drivers like vcsm [1]. Personally i don't want to maintain another > one, because i cannot see the gain of the resulting effort. > > [1] - > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm I feel like everyone else already knows the answer but why don't we just merge that code into staging? >>> Dave's been working on a new VCSM service where the firmware can call >>> back into Linux to allocate (instead of just having a permanent carveout >>> of system memory that the firmware allocates from), and lets us make >>> dma-bufs out of those buffers. That driver makes a no-copies v4l2 media >>> decode driver possible, which would then let Kodi and similar projects >>> switch from downstream kernels with closed graphics to upstream kernels >>> with open graphics. >>> >>> Given that the new VCSM service is a rewrite, it's not clear to me that >>> importing the old VCSM driver is a win. But maybe we should go raid >>> https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab >>> the new drivers. Upstreaming the VCHI audio driver to staging has >>> clearly been a win for it, so maybe other eyes on the new v4l2 codec >>> could help Dave along in stabilizing it. >> I think that makes sense as long as the firmware side changes are in >> place so it can actually be used. > The firmware has supported the necessary for dmabuf import since Sept 2017. > > The new vcsm driver currently only supports importing from other > kernel modules as I cut it back to the bare minimum to ease > upstreaming. To be a complete replacement of the existing then it > needs to support userspace alloc/free/import/mmap. I did have most of > that working, but will add it in stages. > The codec code is working for decode but something is off for setting > formats on encode. > Both drivers are loading through DT at the moment as I couldn't get > Eric's platform driver stuff working. IIRC A combination of modules > not getting loaded and getting the appropriate coherent DMA mask set > (being under soc in DT gives the correct mappings, but being a > platform driver didn't). I'm working on these issues and i will post a proper solution soon. In case you need a hack in order to test your stuff, i can prepare a branch for you. > > I'm fire-fighting a networking issue at the moment, but hope to be > back on codecs next week. > Could you hold off raiding my trees until say Fri 26th Oct so I can > ensure they are fully up to date? If I get a chance then I'll start > the work of porting into staging before then. The merge window will open soon, so i don't see the need to hurry. Thanks Stefan > > Dave > > ___ > linux-rpi-kernel mailing list > linux-rpi-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
On Wed, 17 Oct 2018 at 17:51, Peter Robinson wrote: > > > >> > Drop various pieces of dead code from here and there to get rid of > > >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop > > >> > entire header files worth of unused code. > > >> > > > >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > > >> > snd-bcm2835 can still play analog audio just fine. > > >> > > > >> > > >> thanks and i'm fine with your patch series: > > >> > > >> Acked-by: Stefan Wahren > > >> > > >> Unfortunately this would break compilation of the downstream vchi > > >> drivers like vcsm [1]. Personally i don't want to maintain another > > >> one, because i cannot see the gain of the resulting effort. > > >> > > >> [1] - > > >> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > > > > > > > > > I feel like everyone else already knows the answer but why don't we just > > > merge that code into staging? > > > > Dave's been working on a new VCSM service where the firmware can call > > back into Linux to allocate (instead of just having a permanent carveout > > of system memory that the firmware allocates from), and lets us make > > dma-bufs out of those buffers. That driver makes a no-copies v4l2 media > > decode driver possible, which would then let Kodi and similar projects > > switch from downstream kernels with closed graphics to upstream kernels > > with open graphics. > > > > Given that the new VCSM service is a rewrite, it's not clear to me that > > importing the old VCSM driver is a win. But maybe we should go raid > > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab > > the new drivers. Upstreaming the VCHI audio driver to staging has > > clearly been a win for it, so maybe other eyes on the new v4l2 codec > > could help Dave along in stabilizing it. > > I think that makes sense as long as the firmware side changes are in > place so it can actually be used. The firmware has supported the necessary for dmabuf import since Sept 2017. The new vcsm driver currently only supports importing from other kernel modules as I cut it back to the bare minimum to ease upstreaming. To be a complete replacement of the existing then it needs to support userspace alloc/free/import/mmap. I did have most of that working, but will add it in stages. The codec code is working for decode but something is off for setting formats on encode. Both drivers are loading through DT at the moment as I couldn't get Eric's platform driver stuff working. IIRC A combination of modules not getting loaded and getting the appropriate coherent DMA mask set (being under soc in DT gives the correct mappings, but being a platform driver didn't). I'm fire-fighting a networking issue at the moment, but hope to be back on codecs next week. Could you hold off raiding my trees until say Fri 26th Oct so I can ensure they are fully up to date? If I get a chance then I'll start the work of porting into staging before then. Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
> >> > Drop various pieces of dead code from here and there to get rid of > >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop > >> > entire header files worth of unused code. > >> > > >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > >> > snd-bcm2835 can still play analog audio just fine. > >> > > >> > >> thanks and i'm fine with your patch series: > >> > >> Acked-by: Stefan Wahren > >> > >> Unfortunately this would break compilation of the downstream vchi > >> drivers like vcsm [1]. Personally i don't want to maintain another > >> one, because i cannot see the gain of the resulting effort. > >> > >> [1] - > >> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > > > > > > I feel like everyone else already knows the answer but why don't we just > > merge that code into staging? > > Dave's been working on a new VCSM service where the firmware can call > back into Linux to allocate (instead of just having a permanent carveout > of system memory that the firmware allocates from), and lets us make > dma-bufs out of those buffers. That driver makes a no-copies v4l2 media > decode driver possible, which would then let Kodi and similar projects > switch from downstream kernels with closed graphics to upstream kernels > with open graphics. > > Given that the new VCSM service is a rewrite, it's not clear to me that > importing the old VCSM driver is a win. But maybe we should go raid > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab > the new drivers. Upstreaming the VCHI audio driver to staging has > clearly been a win for it, so maybe other eyes on the new v4l2 codec > could help Dave along in stabilizing it. I think that makes sense as long as the firmware side changes are in place so it can actually be used. Peter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Dan Carpenter writes: > On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote: >> Hi Tuomas, >> >> > Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 >> > geschrieben: >> > >> > >> > Drop various pieces of dead code from here and there to get rid of >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop >> > entire header files worth of unused code. >> > >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that >> > snd-bcm2835 can still play analog audio just fine. >> > >> >> thanks and i'm fine with your patch series: >> >> Acked-by: Stefan Wahren >> >> Unfortunately this would break compilation of the downstream vchi >> drivers like vcsm [1]. Personally i don't want to maintain another >> one, because i cannot see the gain of the resulting effort. >> >> [1] - >> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > > > I feel like everyone else already knows the answer but why don't we just > merge that code into staging? Dave's been working on a new VCSM service where the firmware can call back into Linux to allocate (instead of just having a permanent carveout of system memory that the firmware allocates from), and lets us make dma-bufs out of those buffers. That driver makes a no-copies v4l2 media decode driver possible, which would then let Kodi and similar projects switch from downstream kernels with closed graphics to upstream kernels with open graphics. Given that the new VCSM service is a rewrite, it's not clear to me that importing the old VCSM driver is a win. But maybe we should go raid https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab the new drivers. Upstreaming the VCHI audio driver to staging has clearly been a win for it, so maybe other eyes on the new v4l2 codec could help Dave along in stabilizing it. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Hi, Am 17.10.2018 um 11:55 schrieb Dave Stevenson: > On Mon, 15 Oct 2018 at 17:27, Eric Anholt wrote: >> Stefan Wahren writes: >> >>> Hi Tuomas, >>> Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 geschrieben: Drop various pieces of dead code from here and there to get rid of the remaining users of VCHI_CONNECTION_T. After that we get to drop entire header files worth of unused code. I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that snd-bcm2835 can still play analog audio just fine. >>> thanks and i'm fine with your patch series: >>> >>> Acked-by: Stefan Wahren >>> >>> Unfortunately this would break compilation of the downstream vchi >>> drivers like vcsm [1]. Personally i don't want to maintain another >>> one, because i cannot see the gain of the resulting effort. >>> >>> [1] - >>> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > I'm happy enough to work around these changes. Once the change is in a > released kernel we can merge a modified version of vc_sm into the > downstream kernel branch. It's not as if it requires big changes. > >> I think the main concern would be if we removed things necessary for >> 6by9's new vcsm (the one that will let us do dma-buf sharing between >> media decode and DRM). > The new vcsm uses the same VCHI service as the existing downstream vc_sm > driver. > The video codec driver don't use any VCHI functionality over and above > the camera. It goes via a slightly extended version of the > mmal-vchiq.c, which I have split out into a shared module. my statement about the old vc_sm based on assumption there wont be a user of this driver. In case the camera driver would use the new vc_sm driver, i would be happier to see this merged in staging than in downstream. Stefan > >> On the other hand, git revert is a thing, so it's not like we actually >> lose anything. > :-) > > Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
On Sat, Oct 06, 2018 at 12:18:38PM +0200, Stefan Wahren wrote: > Hi Tuomas, > > > Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 > > geschrieben: > > > > > > Drop various pieces of dead code from here and there to get rid of > > the remaining users of VCHI_CONNECTION_T. After that we get to drop > > entire header files worth of unused code. > > > > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > > snd-bcm2835 can still play analog audio just fine. > > > > thanks and i'm fine with your patch series: > > Acked-by: Stefan Wahren > > Unfortunately this would break compilation of the downstream vchi > drivers like vcsm [1]. Personally i don't want to maintain another > one, because i cannot see the gain of the resulting effort. > > [1] - > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm I feel like everyone else already knows the answer but why don't we just merge that code into staging? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
On Mon, 15 Oct 2018 at 17:27, Eric Anholt wrote: > > Stefan Wahren writes: > > > Hi Tuomas, > > > >> Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 > >> geschrieben: > >> > >> > >> Drop various pieces of dead code from here and there to get rid of > >> the remaining users of VCHI_CONNECTION_T. After that we get to drop > >> entire header files worth of unused code. > >> > >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > >> snd-bcm2835 can still play analog audio just fine. > >> > > > > thanks and i'm fine with your patch series: > > > > Acked-by: Stefan Wahren > > > > Unfortunately this would break compilation of the downstream vchi > > drivers like vcsm [1]. Personally i don't want to maintain another > > one, because i cannot see the gain of the resulting effort. > > > > [1] - > > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm I'm happy enough to work around these changes. Once the change is in a released kernel we can merge a modified version of vc_sm into the downstream kernel branch. It's not as if it requires big changes. > I think the main concern would be if we removed things necessary for > 6by9's new vcsm (the one that will let us do dma-buf sharing between > media decode and DRM). The new vcsm uses the same VCHI service as the existing downstream vc_sm driver. The video codec driver don't use any VCHI functionality over and above the camera. It goes via a slightly extended version of the mmal-vchiq.c, which I have split out into a shared module. > On the other hand, git revert is a thing, so it's not like we actually > lose anything. :-) Dave ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Stefan Wahren writes: > Hi Tuomas, > >> Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 >> geschrieben: >> >> >> Drop various pieces of dead code from here and there to get rid of >> the remaining users of VCHI_CONNECTION_T. After that we get to drop >> entire header files worth of unused code. >> >> I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that >> snd-bcm2835 can still play analog audio just fine. >> > > thanks and i'm fine with your patch series: > > Acked-by: Stefan Wahren > > Unfortunately this would break compilation of the downstream vchi > drivers like vcsm [1]. Personally i don't want to maintain another > one, because i cannot see the gain of the resulting effort. > > [1] - > https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm I think the main concern would be if we removed things necessary for 6by9's new vcsm (the one that will let us do dma-buf sharing between media decode and DRM). On the other hand, git revert is a thing, so it's not like we actually lose anything. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Hi Tuomas, > Tuomas Tynkkynen hat am 4. Oktober 2018 um 11:37 > geschrieben: > > > Drop various pieces of dead code from here and there to get rid of > the remaining users of VCHI_CONNECTION_T. After that we get to drop > entire header files worth of unused code. > > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > snd-bcm2835 can still play analog audio just fine. > thanks and i'm fine with your patch series: Acked-by: Stefan Wahren Unfortunately this would break compilation of the downstream vchi drivers like vcsm [1]. Personally i don't want to maintain another one, because i cannot see the gain of the resulting effort. [1] - https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] staging: vc04_services: Some dead code removal
Drop various pieces of dead code from here and there to get rid of the remaining users of VCHI_CONNECTION_T. After that we get to drop entire header files worth of unused code. I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that snd-bcm2835 can still play analog audio just fine. Tuomas Tynkkynen (7): staging: vc04_services: Drop pointless stub functions staging: vc04_services: Drop 'connection' field from SERVICE_CREATION_T staging: vc04_services: Drop trivially unused fields from SERVICE_CREATION_T staging: vc04_services: Drop declaration of vchi_crc_control() staging: vc04_services: Drop VCHI_SERVICE_INIT and SERVICE_INFO_T staging: vc04_services: Drop unused parameters from vchi_connect() staging: vc04_services: Drop no longer needed headers .../bcm2835-audio/bcm2835-vchiq.c | 10 +- .../vc04_services/bcm2835-audio/bcm2835.h | 1 - .../vc04_services/bcm2835-camera/mmal-vchiq.c | 9 +- .../interface/vchi/connections/connection.h | 324 -- .../interface/vchi/message_drivers/message.h | 196 --- .../vc04_services/interface/vchi/vchi.h | 41 +-- .../interface/vchi/vchi_cfg_internal.h| 71 .../interface/vchiq_arm/vchiq_shim.c | 38 +- 8 files changed, 5 insertions(+), 685 deletions(-) delete mode 100644 drivers/staging/vc04_services/interface/vchi/connections/connection.h delete mode 100644 drivers/staging/vc04_services/interface/vchi/message_drivers/message.h delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_cfg_internal.h -- 2.18.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
