| Message ID | CACRpkdbyO0axd5ergYZcXO302f2fFAPKrSNevkvreP1kRjm-vw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi, On Sat, Apr 23, 2016 at 11:43:58AM +0200, Linus Walleij wrote: > Hi ARM SoC guys, > > these two patches move the ARM character LCD driver from > misc drivers to the auxdisplay subsystem where it belongs and > updates the defconfig for the RealView accordingly. > > Please pull it into some cleanup branch in the ARM SoC > tree. > > I tried to get some ACK from the auxdisplay maintainer but no > reaction. Auxdisplay is not a new framework, but rather a very old one. It got introduced in 2.6.21, and only received a couple of drivers since. It seems to be quite redundant with fbdev deferred_io, which itself is almost deprecated these days. Maxime
On Monday 25 April 2016 13:57:58 Maxime Ripard wrote: > Hi, > > On Sat, Apr 23, 2016 at 11:43:58AM +0200, Linus Walleij wrote: > > Hi ARM SoC guys, > > > > these two patches move the ARM character LCD driver from > > misc drivers to the auxdisplay subsystem where it belongs and > > updates the defconfig for the RealView accordingly. > > > > Please pull it into some cleanup branch in the ARM SoC > > tree. > > > > I tried to get some ACK from the auxdisplay maintainer but no > > reaction. > > Auxdisplay is not a new framework, but rather a very old one. > > It got introduced in 2.6.21, and only received a couple of drivers > since. > > It seems to be quite redundant with fbdev deferred_io, which itself is > almost deprecated these days. I'm holding off on this pull request for now then. I'd certainly like to see the driver get moved out of drivers/misc, let me know once there has been an agreement of where it should go. Arnd
On Mon, Apr 25, 2016 at 1:57 PM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Sat, Apr 23, 2016 at 11:43:58AM +0200, Linus Walleij wrote: >> Hi ARM SoC guys, >> >> these two patches move the ARM character LCD driver from >> misc drivers to the auxdisplay subsystem where it belongs and >> updates the defconfig for the RealView accordingly. >> >> Please pull it into some cleanup branch in the ARM SoC >> tree. >> >> I tried to get some ACK from the auxdisplay maintainer but no >> reaction. > > Auxdisplay is not a new framework, but rather a very old one. > > It got introduced in 2.6.21, and only received a couple of drivers > since. Small problem for me, but Robin is submitting a brand new auxdisplay driver: http://marc.info/?l=linux-kernel&m=146001950512999&w=2 http://marc.info/?l=linux-kernel&m=146001988013230&w=2 > It seems to be quite redundant with fbdev deferred_io, which itself is > almost deprecated these days. That is a valid argument for moving cfag12864b* out to drivers/video/* I guess, but it has nothing to do with this driver whatsoever. This driver has nothing to do with fbdev. Nothing at all. It so not connected to any framebuffer. This driver gets moved to auxdisplay to match the existing LCD driver in drivers/auxdisplay/ks0108.c which is a similar hardware, driving an LCD that likewise has nothing to do with fbdev. Yours, Linus Walleij
On Tue, Apr 26, 2016 at 12:41:29PM +0200, Linus Walleij wrote: > On Mon, Apr 25, 2016 at 1:57 PM, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Sat, Apr 23, 2016 at 11:43:58AM +0200, Linus Walleij wrote: > >> Hi ARM SoC guys, > >> > >> these two patches move the ARM character LCD driver from > >> misc drivers to the auxdisplay subsystem where it belongs and > >> updates the defconfig for the RealView accordingly. > >> > >> Please pull it into some cleanup branch in the ARM SoC > >> tree. > >> > >> I tried to get some ACK from the auxdisplay maintainer but no > >> reaction. > > > > Auxdisplay is not a new framework, but rather a very old one. > > > > It got introduced in 2.6.21, and only received a couple of drivers > > since. > > Small problem for me, but Robin is submitting a brand new > auxdisplay driver: > http://marc.info/?l=linux-kernel&m=146001950512999&w=2 > http://marc.info/?l=linux-kernel&m=146001988013230&w=2 My understanding is that Tomi doesn't want any new fbdev drivers, so I'm not sure this is the right place for those patches. > > It seems to be quite redundant with fbdev deferred_io, which itself is > > almost deprecated these days. > > That is a valid argument for moving cfag12864b* out to > drivers/video/* I guess, but it has nothing to do with this > driver whatsoever. > > This driver has nothing to do with fbdev. Nothing at all. > It so not connected to any framebuffer. > > This driver gets moved to auxdisplay to match the existing > LCD driver in drivers/auxdisplay/ks0108.c which is a similar > hardware, driving an LCD that likewise has nothing to do > with fbdev. My bad, I thought all auxdisplay drivers were fbdev ones, but I was wrong, obviously. And now, I don't really know what auxdisplay is about anymore :) Still, moving it to a "framework" that has been inactive for so long (and you even mention it in your PR) doesn't seem like the right move. Maxime
On Thu, Apr 28, 2016 at 11:26 AM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > Still, moving it to a "framework" that has been inactive for so long > (and you even mention it in your PR) doesn't seem like the right move. I still think sorting the driver into the right bucket has a value. When/if the Linux LCD support gets an upstream push they will know where to put their stuff: here, and then common stuff can be abstracted. With drivers floating around in misc the situation is even worse. http://lcd-linux.sourceforge.net/ Yours, Linus Walleij
On 28/04/16 12:26, Maxime Ripard wrote: > On Tue, Apr 26, 2016 at 12:41:29PM +0200, Linus Walleij wrote: >> On Mon, Apr 25, 2016 at 1:57 PM, Maxime Ripard >> <maxime.ripard@free-electrons.com> wrote: >>> On Sat, Apr 23, 2016 at 11:43:58AM +0200, Linus Walleij wrote: >>>> Hi ARM SoC guys, >>>> >>>> these two patches move the ARM character LCD driver from >>>> misc drivers to the auxdisplay subsystem where it belongs and >>>> updates the defconfig for the RealView accordingly. >>>> >>>> Please pull it into some cleanup branch in the ARM SoC >>>> tree. >>>> >>>> I tried to get some ACK from the auxdisplay maintainer but no >>>> reaction. >>> >>> Auxdisplay is not a new framework, but rather a very old one. >>> >>> It got introduced in 2.6.21, and only received a couple of drivers >>> since. >> >> Small problem for me, but Robin is submitting a brand new >> auxdisplay driver: >> http://marc.info/?l=linux-kernel&m=146001950512999&w=2 >> http://marc.info/?l=linux-kernel&m=146001988013230&w=2 > > My understanding is that Tomi doesn't want any new fbdev drivers, so > I'm not sure this is the right place for those patches. Hmm, that one looks like an fbdev driver, not an auxdisplay driver. But, not relevant for this patch, of course. >>> It seems to be quite redundant with fbdev deferred_io, which itself is >>> almost deprecated these days. >> >> That is a valid argument for moving cfag12864b* out to >> drivers/video/* I guess, but it has nothing to do with this >> driver whatsoever. >> >> This driver has nothing to do with fbdev. Nothing at all. >> It so not connected to any framebuffer. >> >> This driver gets moved to auxdisplay to match the existing >> LCD driver in drivers/auxdisplay/ks0108.c which is a similar >> hardware, driving an LCD that likewise has nothing to do >> with fbdev. > > My bad, I thought all auxdisplay drivers were fbdev ones, but I was > wrong, obviously. And now, I don't really know what auxdisplay is > about anymore :) > > Still, moving it to a "framework" that has been inactive for so long > (and you even mention it in your PR) doesn't seem like the right move. I think this move makes sense. It's only moving a file to a directory that at least mentions "display", not really moving it into a framework (because there doesn't seem to be any). Tomi
On Fri, 29 Apr 2016 17:53:17 +0300 Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: [...] > >> > >> Small problem for me, but Robin is submitting a brand new > >> auxdisplay driver: > >> http://marc.info/?l=linux-kernel&m=146001950512999&w=2 > >> http://marc.info/?l=linux-kernel&m=146001988013230&w=2 > > > > My understanding is that Tomi doesn't want any new fbdev drivers, so > > I'm not sure this is the right place for those patches. > > Hmm, that one looks like an fbdev driver, not an auxdisplay driver. > But, not relevant for this patch, of course. If you guys feel like auxdisplay is not the right subsystem for the driver, and would like me to move it, please share. Regards, Robin van der Gracht
On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht <robin@protonic.nl> wrote: > If you guys feel like auxdisplay is not the right subsystem for the > driver, and would like me to move it, please share. The best would be if you volunteer to maintain it and bring it forward. Yours, Linus Walleij
On Mon, 9 May 2016 15:19:26 +0200 Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht > <robin@protonic.nl> wrote: > > > If you guys feel like auxdisplay is not the right subsystem for the > > driver, and would like me to move it, please share. > > The best would be if you volunteer to maintain it and bring > it forward. Thats fine. Would it suffice if I submit another patch adding myself to the maintainers file? Regards, Robin
On Mon, May 9, 2016 at 4:17 PM, Robin van der Gracht <robin@protonic.nl> wrote: > On Mon, 9 May 2016 15:19:26 +0200 > Linus Walleij <linus.walleij@linaro.org> wrote: > >> On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht >> <robin@protonic.nl> wrote: >> >> > If you guys feel like auxdisplay is not the right subsystem for the >> > driver, and would like me to move it, please share. >> >> The best would be if you volunteer to maintain it and bring >> it forward. > > Thats fine. Would it suffice if I submit another patch adding myself > to the maintainers file? That's half of it, if Miguel does not come back then his name should be removed as the second step. You also need to have an idea on a path to funnel accumulated patches upstream to Torvalds. The recent patches to this subsystem were funneled by Greg, so we should ask him how he prefer to proceed. Greg, what do you prefer? Yours, Linus Walleij
On Mon, May 09, 2016 at 04:27:00PM +0200, Linus Walleij wrote: > On Mon, May 9, 2016 at 4:17 PM, Robin van der Gracht <robin@protonic.nl> wrote: > > On Mon, 9 May 2016 15:19:26 +0200 > > Linus Walleij <linus.walleij@linaro.org> wrote: > > > >> On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht > >> <robin@protonic.nl> wrote: > >> > >> > If you guys feel like auxdisplay is not the right subsystem for the > >> > driver, and would like me to move it, please share. > >> > >> The best would be if you volunteer to maintain it and bring > >> it forward. > > > > Thats fine. Would it suffice if I submit another patch adding myself > > to the maintainers file? > > That's half of it, if Miguel does not come back then his name > should be removed as the second step. > > You also need to have an idea on a path to funnel accumulated > patches upstream to Torvalds. The recent patches to this > subsystem were funneled by Greg, so we should ask him how > he prefer to proceed. > > Greg, what do you prefer? I don't care :) I can keep doing this, sending stuff to Linus through my char/misc tree, or it can go through someone else's tree, it doesn't bother me... thanks, greg k-h
On Tue, 10 May 2016 09:10:04 +0200 Greg KH <gregkh@linuxfoundation.org> wrote: > On Mon, May 09, 2016 at 04:27:00PM +0200, Linus Walleij wrote: > > On Mon, May 9, 2016 at 4:17 PM, Robin van der Gracht > > <robin@protonic.nl> wrote: > > > On Mon, 9 May 2016 15:19:26 +0200 > > > Linus Walleij <linus.walleij@linaro.org> wrote: > > > > > >> On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht > > >> <robin@protonic.nl> wrote: > > >> > > >> > If you guys feel like auxdisplay is not the right subsystem > > >> > for the driver, and would like me to move it, please share. > > >> > > >> The best would be if you volunteer to maintain it and bring > > >> it forward. > > > > > > Thats fine. Would it suffice if I submit another patch adding > > > myself to the maintainers file? > > > > That's half of it, if Miguel does not come back then his name > > should be removed as the second step. > > > > You also need to have an idea on a path to funnel accumulated > > patches upstream to Torvalds. The recent patches to this > > subsystem were funneled by Greg, so we should ask him how > > he prefer to proceed. > > > > Greg, what do you prefer? > > I don't care :) > > I can keep doing this, sending stuff to Linus through my char/misc > tree, or it can go through someone else's tree, it doesn't bother > me... Soo.. You're allowing me to send patches to you so you can funnel them through your channel (for now)? Kind regards, Robin
On Wed, May 11, 2016 at 09:46:35AM +0200, Robin van der Gracht wrote: > On Tue, 10 May 2016 09:10:04 +0200 > Greg KH <gregkh@linuxfoundation.org> wrote: > > > On Mon, May 09, 2016 at 04:27:00PM +0200, Linus Walleij wrote: > > > On Mon, May 9, 2016 at 4:17 PM, Robin van der Gracht > > > <robin@protonic.nl> wrote: > > > > On Mon, 9 May 2016 15:19:26 +0200 > > > > Linus Walleij <linus.walleij@linaro.org> wrote: > > > > > > > >> On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht > > > >> <robin@protonic.nl> wrote: > > > >> > > > >> > If you guys feel like auxdisplay is not the right subsystem > > > >> > for the driver, and would like me to move it, please share. > > > >> > > > >> The best would be if you volunteer to maintain it and bring > > > >> it forward. > > > > > > > > Thats fine. Would it suffice if I submit another patch adding > > > > myself to the maintainers file? > > > > > > That's half of it, if Miguel does not come back then his name > > > should be removed as the second step. > > > > > > You also need to have an idea on a path to funnel accumulated > > > patches upstream to Torvalds. The recent patches to this > > > subsystem were funneled by Greg, so we should ask him how > > > he prefer to proceed. > > > > > > Greg, what do you prefer? > > > > I don't care :) > > > > I can keep doing this, sending stuff to Linus through my char/misc > > tree, or it can go through someone else's tree, it doesn't bother > > me... > > Soo.. You're allowing me to send patches to you so you can funnel > them through your channel (for now)? Sure, I'd be glad to do so if that makes your life easier. Either way it's no real extra or less overall workload for me :) thanks, greg k-h
On Mon, 9 May 2016 16:27:00 +0200 Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, May 9, 2016 at 4:17 PM, Robin van der Gracht > <robin@protonic.nl> wrote: > > On Mon, 9 May 2016 15:19:26 +0200 > > Linus Walleij <linus.walleij@linaro.org> wrote: > > > >> On Mon, May 9, 2016 at 9:06 AM, Robin van der Gracht > >> <robin@protonic.nl> wrote: > >> > >> > If you guys feel like auxdisplay is not the right subsystem for > >> > the driver, and would like me to move it, please share. > >> > >> The best would be if you volunteer to maintain it and bring > >> it forward. > > > > Thats fine. Would it suffice if I submit another patch adding myself > > to the maintainers file? > > That's half of it, if Miguel does not come back then his name > should be removed as the second step. > First half is completed. I've added myself as maintainer for the driver I've posted recently (HT16K33 LED CONTROLLER DRIVER). According to MAINTAINERS, Miguel maintains: - CFAG12864B LCD DRIVER - CFAG12864BFB LCD FRAMEBUFFER DRIVER - KS0108 LCD CONTROLLER DRIVER - AUXILIARY DISPLAY DRIVERS AFAIK, I should not be judge in Miguels case. @linus: I'll send my patches to Greg if you agree on this. Kind regards, Robin van der Gracht
On Thu, May 12, 2016 at 12:25 PM, Robin van der Gracht <robin@protonic.nl> wrote: > First half is completed. I've added myself as maintainer for the > driver I've posted recently (HT16K33 LED CONTROLLER DRIVER). Good! > According to MAINTAINERS, Miguel maintains: > - CFAG12864B LCD DRIVER > - CFAG12864BFB LCD FRAMEBUFFER DRIVER > - KS0108 LCD CONTROLLER DRIVER > - AUXILIARY DISPLAY DRIVERS > > AFAIK, I should not be judge in Miguels case. If patches come in for these drivers and Miguel still seem to be fallen off the face of the earth I think you should ACK/merge patches for these too, but deal with it when it happens. > @linus: I'll send my patches to Greg if you agree on this. We are in agreement. Yours, Linus Walleij
Hi ARM SoC guys, these two patches move the ARM character LCD driver from misc drivers to the auxdisplay subsystem where it belongs and updates the defconfig for the RealView accordingly. Please pull it into some cleanup branch in the ARM SoC tree. I tried to get some ACK from the auxdisplay maintainer but no reaction. Yours, Linus Walleij The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git tags/move-auxdisplay for you to fetch changes up to 700ce70081d4f5ac7bc4fbfba209072152f96c89: ARM: realview: update defconfig to match new subsystem (2016-04-23 11:38:25 +0200) ---------------------------------------------------------------- This moves the ARM RealView auxilary display out of the misc drivers and into the new auxdisplay subsystem. ---------------------------------------------------------------- Linus Walleij (2): auxdisplay: move the ARM LCD driver into auxdisplay ARM: realview: update defconfig to match new subsystem arch/arm/configs/realview_defconfig | 3 ++- drivers/auxdisplay/Kconfig | 10 ++++++++++ drivers/auxdisplay/Makefile | 1 + drivers/{misc => auxdisplay}/arm-charlcd.c | 0 drivers/misc/Kconfig | 10 ---------- drivers/misc/Makefile | 1 - 6 files changed, 13 insertions(+), 12 deletions(-) rename drivers/{misc => auxdisplay}/arm-charlcd.c (100%)