Message ID | YBANNJ8XtoRf7SuW@smile.fi.intel.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | [GIT,PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1 | expand |
Hi, On 1/26/21 1:38 PM, Andy Shevchenko wrote: > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's collected into > immutable branch with a given tag, please pull to yours subsystems. > > (All changes are tagged by the respective maintainers) > > Thanks, > > With Best Regards, > Andy Shevchenko > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > git://git.infradead.org/linux-platform-drivers-x86.git tags/ib-drm-gpio-pdx86-rtc-wdt-v5.12-1 > > for you to fetch changes up to a507e5d90f3d6846a02d9c2c79e6f6395982db92: > > platform/x86: intel_scu_wdt: Get rid of custom x86 model comparison (2021-01-25 20:05:32 +0200) > > ---------------------------------------------------------------- > ib-drm-gpio-pdx86-rtc-wdt for v5.12-1 > > First part of Intel MID outdated platforms removal. > > The following is an automated git shortlog grouped by driver: > > drm/gma500: > - Get rid of duplicate NULL checks > - Convert to use new SCU IPC API > > gpio: > - msic: Remove driver for deprecated platform > - intel-mid: Remove driver for deprecated platform > > intel_mid_powerbtn: > - Remove driver for deprecated platform > > intel_mid_thermal: > - Remove driver for deprecated platform > > intel_scu_wdt: > - Get rid of custom x86 model comparison > - Drop SCU notification > - Move driver from arch/x86 > > rtc: > - mrst: Remove driver for deprecated platform > > watchdog: > - intel-mid_wdt: Postpone IRQ handler registration till SCU is ready > - intel_scu_watchdog: Remove driver for deprecated platform > > ---------------------------------------------------------------- > Andy Shevchenko (12): > drm/gma500: Convert to use new SCU IPC API > drm/gma500: Get rid of duplicate NULL checks > gpio: intel-mid: Remove driver for deprecated platform > gpio: msic: Remove driver for deprecated platform > platform/x86: intel_mid_thermal: Remove driver for deprecated platform > platform/x86: intel_mid_powerbtn: Remove driver for deprecated platform Erm, I already have this 2 in platform-drivers-x86/for-next since you said that these 2 could be merged independently. Anyways I just did a test-merge and there is no conflict, so everything is ok. From my pov this looks good and I plan to merge this into platform-drivers-x86/for-next before the merge-window. I'm going to hold off on doing that for a bit for now in case one of the other subsys maintainers has any objections. Regards, Hans > rtc: mrst: Remove driver for deprecated platform > watchdog: intel_scu_watchdog: Remove driver for deprecated platform > watchdog: intel-mid_wdt: Postpone IRQ handler registration till SCU is ready > platform/x86: intel_scu_wdt: Move driver from arch/x86 > platform/x86: intel_scu_wdt: Drop SCU notification > platform/x86: intel_scu_wdt: Get rid of custom x86 model comparison > > MAINTAINERS | 2 - > arch/x86/platform/intel-mid/device_libs/Makefile | 1 - > drivers/gpio/Kconfig | 14 - > drivers/gpio/Makefile | 1 - > drivers/gpio/TODO | 2 +- > drivers/gpio/gpio-intel-mid.c | 414 --------------- > drivers/gpio/gpio-msic.c | 314 ------------ > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/gma500/mdfld_device.c | 2 - > drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 - > drivers/gpu/drm/gma500/mdfld_output.c | 8 +- > drivers/gpu/drm/gma500/oaktrail_device.c | 3 - > drivers/gpu/drm/gma500/psb_drv.h | 3 + > drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 30 +- > drivers/platform/x86/Kconfig | 23 +- > drivers/platform/x86/Makefile | 3 +- > drivers/platform/x86/intel_mid_powerbtn.c | 233 --------- > drivers/platform/x86/intel_mid_thermal.c | 560 --------------------- > .../platform/x86/intel_scu_wdt.c | 41 +- > drivers/rtc/Kconfig | 12 - > drivers/rtc/Makefile | 1 - > drivers/rtc/rtc-mrst.c | 521 ------------------- > drivers/watchdog/Kconfig | 9 - > drivers/watchdog/Makefile | 1 - > drivers/watchdog/intel-mid_wdt.c | 8 +- > drivers/watchdog/intel_scu_watchdog.c | 533 -------------------- > drivers/watchdog/intel_scu_watchdog.h | 50 -- > 27 files changed, 54 insertions(+), 2738 deletions(-) > delete mode 100644 drivers/gpio/gpio-intel-mid.c > delete mode 100644 drivers/gpio/gpio-msic.c > delete mode 100644 drivers/platform/x86/intel_mid_powerbtn.c > delete mode 100644 drivers/platform/x86/intel_mid_thermal.c > rename arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c => drivers/platform/x86/intel_scu_wdt.c (69%) > delete mode 100644 drivers/rtc/rtc-mrst.c > delete mode 100644 drivers/watchdog/intel_scu_watchdog.c > delete mode 100644 drivers/watchdog/intel_scu_watchdog.h >
On Tue, Jan 26, 2021 at 4:23 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 1/26/21 1:38 PM, Andy Shevchenko wrote: > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > immutable branch with a given tag, please pull to yours subsystems. > > > > (All changes are tagged by the respective maintainers) ... > > platform/x86: intel_mid_thermal: Remove driver for deprecated platform > > platform/x86: intel_mid_powerbtn: Remove driver for deprecated platform > > Erm, I already have this 2 in platform-drivers-x86/for-next since you said that > these 2 could be merged independently. Yes, you may merge this on top, shouldn't be any conflicts. But this mail originally was sent a couple of days ago, I had a problem with my email setup. > Anyways I just did a test-merge and there is no conflict, so everything is ok. Yep. That's how it works :) > From my pov this looks good and I plan to merge this into platform-drivers-x86/for-next > before the merge-window. > > I'm going to hold off on doing that for a bit for now in case one of the other > subsys maintainers has any objections. Noted and thanks!
On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's collected into > immutable branch with a given tag, please pull to yours subsystems. Hi Andy, Do you plan on eventually removing X86_INTEL_MID completely? If so, then I should probably start looking at removing the corresponding parts in GMA500. Thanks Patrik
On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson <patrik.r.jakobsson@gmail.com> wrote: > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > immutable branch with a given tag, please pull to yours subsystems. > > Hi Andy, > Do you plan on eventually removing X86_INTEL_MID completely? If so, > then I should probably start looking at removing the corresponding > parts in GMA500. Nope. It is related to only Medfield / Clovertrail platforms. There are other (MID) platforms that may / might utilize this driver in the future. I.o.w. we probably can remove the oldest stuff in the driver WRT above mentioned platforms, but leave the driver for the rest. I wouldn't be in a hurry with this though, display drivers are easy to remove, but really hard to get back on velocity after that.
On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > <patrik.r.jakobsson@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > Hi guys, > > > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > > immutable branch with a given tag, please pull to yours subsystems. > > > > Hi Andy, > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > then I should probably start looking at removing the corresponding > > parts in GMA500. > > Nope. It is related to only Medfield / Clovertrail platforms. > > There are other (MID) platforms that may / might utilize this driver > in the future. Right, there's still Oaktrail / Moorestown with hardware in the wild. > > I.o.w. we probably can remove the oldest stuff in the driver WRT above > mentioned platforms, but leave the driver for the rest. > I wouldn't be in a hurry with this though, display drivers are easy to > remove, but really hard to get back on velocity after that. Ok, I'll have a look at removing Medfield. That code should have been removed a long time ago. -Patrik
On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson <patrik.r.jakobsson@gmail.com> wrote: > On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > <patrik.r.jakobsson@gmail.com> wrote: > > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > Hi guys, > > > > > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > > > immutable branch with a given tag, please pull to yours subsystems. > > > > > > Hi Andy, > > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > > then I should probably start looking at removing the corresponding > > > parts in GMA500. > > > > Nope. It is related to only Medfield / Clovertrail platforms. > > > > There are other (MID) platforms that may / might utilize this driver > > in the future. > > Right, there's still Oaktrail / Moorestown with hardware in the wild. Actually Moorestown had to be removed a few years ago (kernel won't boot on them anyway from that date when Alan removed support under arch/x86 for it). I'm talking about Merrifield and Moorefield that can utilize it and also some other platforms that are not SFI based (Cedar something... IIRC). > > I.o.w. we probably can remove the oldest stuff in the driver WRT above > > mentioned platforms, but leave the driver for the rest. > > I wouldn't be in a hurry with this though, display drivers are easy to > > remove, but really hard to get back on velocity after that. > > Ok, I'll have a look at removing Medfield. That code should have been > removed a long time ago.
Hi, On 1/26/21 6:14 PM, Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > <patrik.r.jakobsson@gmail.com> wrote: >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko >> <andy.shevchenko@gmail.com> wrote: >>> >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson >>> <patrik.r.jakobsson@gmail.com> wrote: >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko >>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> This is first part of Intel MID outdated platforms removal. It's collected into >>>>> immutable branch with a given tag, please pull to yours subsystems. >>>> >>>> Hi Andy, >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, >>>> then I should probably start looking at removing the corresponding >>>> parts in GMA500. >>> >>> Nope. It is related to only Medfield / Clovertrail platforms. >>> >>> There are other (MID) platforms that may / might utilize this driver >>> in the future. >> >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > Actually Moorestown had to be removed a few years ago (kernel won't > boot on them anyway from that date when Alan removed support under > arch/x86 for it). > > I'm talking about Merrifield and Moorefield that can utilize it and > also some other platforms that are not SFI based (Cedar something... > IIRC). Yes at least there are some 64 bit capable SoCs with GMA500 which were used in NAS like devices. These NAS-es actually have a VGA output (and maybe also DVI?) which is attached to the GMA500. I know people are running Fedora on these, so we should at least keep these supported. Regards, Hans
On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede <hdegoede@redhat.com> wrote: > On 1/26/21 6:14 PM, Andy Shevchenko wrote: > > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > > <patrik.r.jakobsson@gmail.com> wrote: > >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > >> <andy.shevchenko@gmail.com> wrote: > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > >>> <patrik.r.jakobsson@gmail.com> wrote: > >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > >>>> <andriy.shevchenko@linux.intel.com> wrote: > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> This is first part of Intel MID outdated platforms removal. It's collected into > >>>>> immutable branch with a given tag, please pull to yours subsystems. > >>>> > >>>> Hi Andy, > >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, > >>>> then I should probably start looking at removing the corresponding > >>>> parts in GMA500. > >>> > >>> Nope. It is related to only Medfield / Clovertrail platforms. > >>> > >>> There are other (MID) platforms that may / might utilize this driver > >>> in the future. > >> > >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > > > Actually Moorestown had to be removed a few years ago (kernel won't > > boot on them anyway from that date when Alan removed support under > > arch/x86 for it). > > > > I'm talking about Merrifield and Moorefield that can utilize it and > > also some other platforms that are not SFI based (Cedar something... > > IIRC). > > Yes at least there are some 64 bit capable SoCs with GMA500 which were > used in NAS like devices. These NAS-es actually have a VGA output > (and maybe also DVI?) which is attached to the GMA500. Since you are talking about 64-bit, definitely they are *not* Moorestown, Medfield, Clovertrail since the mentioned never were 64-bit. But it would be nice to see the CPU model number to be sure. > I know people are running Fedora on these, so we should at least keep > these supported. Is it possible to gather the CPU model number from them? (Or at least the exact device/box name)
On Tue, Jan 26, 2021 at 9:53 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede <hdegoede@redhat.com> wrote: > > On 1/26/21 6:14 PM, Andy Shevchenko wrote: > > > On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson > > > <patrik.r.jakobsson@gmail.com> wrote: > > >> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko > > >> <andy.shevchenko@gmail.com> wrote: > > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > >>> <patrik.r.jakobsson@gmail.com> wrote: > > >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > >>>> <andriy.shevchenko@linux.intel.com> wrote: > > >>>>> > > >>>>> Hi guys, > > >>>>> > > >>>>> This is first part of Intel MID outdated platforms removal. It's collected into > > >>>>> immutable branch with a given tag, please pull to yours subsystems. > > >>>> > > >>>> Hi Andy, > > >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, > > >>>> then I should probably start looking at removing the corresponding > > >>>> parts in GMA500. > > >>> > > >>> Nope. It is related to only Medfield / Clovertrail platforms. > > >>> > > >>> There are other (MID) platforms that may / might utilize this driver > > >>> in the future. > > >> > > >> Right, there's still Oaktrail / Moorestown with hardware in the wild. > > > > > > Actually Moorestown had to be removed a few years ago (kernel won't > > > boot on them anyway from that date when Alan removed support under > > > arch/x86 for it). Ok. I lump Moorestown and Oaktrail together since they have the same Z6xx series CPU/GPU (GMA600). I still have a working Oaktrail device so that support should stay in gma500. > > > > > > I'm talking about Merrifield and Moorefield that can utilize it and > > > also some other platforms that are not SFI based (Cedar something... > > > IIRC). > > > > Yes at least there are some 64 bit capable SoCs with GMA500 which were > > used in NAS like devices. These NAS-es actually have a VGA output > > (and maybe also DVI?) which is attached to the GMA500. Yes these should be Cedarview/Cedartrail. Some of them are 64-bit and some are 32-bit. I think it came down to if bios enabled it or not. Cedarview comes with VGA, DVI and eDP/DP. Quite a few Cedarview devices exist in the wild. > > Since you are talking about 64-bit, definitely they are *not* > Moorestown, Medfield, Clovertrail since the mentioned never were > 64-bit. But it would be nice to see the CPU model number to be sure. > > > I know people are running Fedora on these, so we should at least keep > > these supported. > > Is it possible to gather the CPU model number from them? (Or at least > the exact device/box name) Yes, it would be interesting to know more about Clovertrail. gma500 only supports up to the Cedarview GPUs but Clovertrail might also use a Cedarview GPU. -Patrik
Hi, On 1/26/21 9:54 PM, Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede <hdegoede@redhat.com> wrote: >> On 1/26/21 6:14 PM, Andy Shevchenko wrote: >>> On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson >>> <patrik.r.jakobsson@gmail.com> wrote: >>>> On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko >>>> <andy.shevchenko@gmail.com> wrote: >>>>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson >>>>> <patrik.r.jakobsson@gmail.com> wrote: >>>>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko >>>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> This is first part of Intel MID outdated platforms removal. It's collected into >>>>>>> immutable branch with a given tag, please pull to yours subsystems. >>>>>> >>>>>> Hi Andy, >>>>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, >>>>>> then I should probably start looking at removing the corresponding >>>>>> parts in GMA500. >>>>> >>>>> Nope. It is related to only Medfield / Clovertrail platforms. >>>>> >>>>> There are other (MID) platforms that may / might utilize this driver >>>>> in the future. >>>> >>>> Right, there's still Oaktrail / Moorestown with hardware in the wild. >>> >>> Actually Moorestown had to be removed a few years ago (kernel won't >>> boot on them anyway from that date when Alan removed support under >>> arch/x86 for it). >>> >>> I'm talking about Merrifield and Moorefield that can utilize it and >>> also some other platforms that are not SFI based (Cedar something... >>> IIRC). >> >> Yes at least there are some 64 bit capable SoCs with GMA500 which were >> used in NAS like devices. These NAS-es actually have a VGA output >> (and maybe also DVI?) which is attached to the GMA500. > > Since you are talking about 64-bit, definitely they are *not* > Moorestown, Medfield, Clovertrail since the mentioned never were > 64-bit. But it would be nice to see the CPU model number to be sure. My info on this comes from this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 And the machine that bugreport is about is a "Thecus N5550 NAS box (Intel Atom D2550/Cedarview platform)" Regards, Hans
On Tue, Jan 26, 2021 at 4:23 PM Hans de Goede <hdegoede@redhat.com> wrote: > On 1/26/21 1:38 PM, Andy Shevchenko wrote: > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > immutable branch with a given tag, please pull to yours subsystems. > > > > (All changes are tagged by the respective maintainers) > Erm, I already have this 2 in platform-drivers-x86/for-next since you said that > these 2 could be merged independently. > > Anyways I just did a test-merge and there is no conflict, so everything is ok. > > From my pov this looks good and I plan to merge this into platform-drivers-x86/for-next > before the merge-window. > > I'm going to hold off on doing that for a bit for now in case one of the other > subsys maintainers has any objections. Any news on this? Have you pulled it somewhere (I don't see it in Linux next)?
On Tue, Jan 26, 2021 at 2:41 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Hi guys, > > This is first part of Intel MID outdated platforms removal. It's collected into > immutable branch with a given tag, please pull to yours subsystems. > > (All changes are tagged by the respective maintainers) Bart, can you pull this into GPIO for-next, please? I would like to base my PR on top of your for-next with this one included.
Hi, On 2/3/21 10:54 AM, Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 4:23 PM Hans de Goede <hdegoede@redhat.com> wrote: >> On 1/26/21 1:38 PM, Andy Shevchenko wrote: >>> Hi guys, >>> >>> This is first part of Intel MID outdated platforms removal. It's collected into >>> immutable branch with a given tag, please pull to yours subsystems. >>> >>> (All changes are tagged by the respective maintainers) > >> Erm, I already have this 2 in platform-drivers-x86/for-next since you said that >> these 2 could be merged independently. >> >> Anyways I just did a test-merge and there is no conflict, so everything is ok. >> >> From my pov this looks good and I plan to merge this into platform-drivers-x86/for-next >> before the merge-window. >> >> I'm going to hold off on doing that for a bit for now in case one of the other >> subsys maintainers has any objections. > > Any news on this? Have you pulled it somewhere (I don't see it in Linux next)? I was going through all pending pdx86 stuff yesterday to prep for the upcoming merge-window. I was doing so in FIFO order and I ran out of steam just as I got to this pull-req. So today is a new day and after sending out a fixes pull-req for 5.11 this is (was) the first thing on my list. I've merged this into my review-hans now (and I will push it to for-next soon). I did one last check of all the commits after merging, and I found one small issue. The "gpio: msic: Remove driver for deprecated platform" commit forgets to drop the Makefile line for the msic driver: obj-$(CONFIG_GPIO_MSIC) += gpio-msic.o This is not a reason to redo the entire branch, but it would be good if you can do a follow up patch to fix this. Regards, Hans
On Wed, Feb 03, 2021 at 11:35:59AM +0100, Hans de Goede wrote: > On 2/3/21 10:54 AM, Andy Shevchenko wrote: > > On Tue, Jan 26, 2021 at 4:23 PM Hans de Goede <hdegoede@redhat.com> wrote: > >> On 1/26/21 1:38 PM, Andy Shevchenko wrote: > >>> Hi guys, > >>> > >>> This is first part of Intel MID outdated platforms removal. It's collected into > >>> immutable branch with a given tag, please pull to yours subsystems. > >>> > >>> (All changes are tagged by the respective maintainers) > > > >> Erm, I already have this 2 in platform-drivers-x86/for-next since you said that > >> these 2 could be merged independently. > >> > >> Anyways I just did a test-merge and there is no conflict, so everything is ok. > >> > >> From my pov this looks good and I plan to merge this into platform-drivers-x86/for-next > >> before the merge-window. > >> > >> I'm going to hold off on doing that for a bit for now in case one of the other > >> subsys maintainers has any objections. > > > > Any news on this? Have you pulled it somewhere (I don't see it in Linux next)? > > I was going through all pending pdx86 stuff yesterday to prep for the upcoming > merge-window. I was doing so in FIFO order and I ran out of steam just as I got > to this pull-req. > > So today is a new day and after sending out a fixes pull-req for 5.11 this is > (was) the first thing on my list. > > I've merged this into my review-hans now (and I will push it to for-next soon). > > I did one last check of all the commits after merging, and I found one small > issue. > > The "gpio: msic: Remove driver for deprecated platform" commit forgets to > drop the Makefile line for the msic driver: > > obj-$(CONFIG_GPIO_MSIC) += gpio-msic.o > > This is not a reason to redo the entire branch, but it would be good if you > can do a follow up patch to fix this. Indeed. Thanks for catching this, I'll fixed locally and will send it soon.
On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson <patrik.r.jakobsson@gmail.com> wrote: > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > Hi guys, > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > immutable branch with a given tag, please pull to yours subsystems. > > Hi Andy, > Do you plan on eventually removing X86_INTEL_MID completely? If so, > then I should probably start looking at removing the corresponding > parts in GMA500. I have noticed new commits in DRM against GMA500 and it seems now in a conflict with my immutable branch. Are you sure you don't forget to pull it?
On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > <patrik.r.jakobsson@gmail.com> wrote: > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > Hi guys, > > > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > > immutable branch with a given tag, please pull to yours subsystems. > > > > Hi Andy, > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > then I should probably start looking at removing the corresponding > > parts in GMA500. > > I have noticed new commits in DRM against GMA500 and it seems now in a > conflict with my immutable branch. Are you sure you don't forget to > pull it? Hi Andy, sorry I missed pulling the immutable branch before taking the gma500 medfield removal. I was unsure how to do that through drm-misc and it's tools so I got sidetracked. What would be the correct way to fix this? -Patrik > > -- > With Best Regards, > Andy Shevchenko
On Thu, Feb 4, 2021 at 11:19 AM Patrik Jakobsson <patrik.r.jakobsson@gmail.com> wrote: > > On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > <patrik.r.jakobsson@gmail.com> wrote: > > > On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > Hi guys, > > > > > > > > This is first part of Intel MID outdated platforms removal. It's collected into > > > > immutable branch with a given tag, please pull to yours subsystems. > > > > > > Hi Andy, > > > Do you plan on eventually removing X86_INTEL_MID completely? If so, > > > then I should probably start looking at removing the corresponding > > > parts in GMA500. > > > > I have noticed new commits in DRM against GMA500 and it seems now in a > > conflict with my immutable branch. Are you sure you don't forget to > > pull it? > > Hi Andy, sorry I missed pulling the immutable branch before taking the > gma500 medfield removal. I was unsure how to do that through drm-misc > and it's tools so I got sidetracked. What would be the correct way to > fix this? Imo Linus can resolve this, it's pretty trivial, as long as both pull requests point it out to him. -Daniel
Hi, On 2/4/21 11:36 AM, Daniel Vetter wrote: > On Thu, Feb 4, 2021 at 11:19 AM Patrik Jakobsson > <patrik.r.jakobsson@gmail.com> wrote: >> >> On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko >> <andy.shevchenko@gmail.com> wrote: >>> >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson >>> <patrik.r.jakobsson@gmail.com> wrote: >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko >>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> This is first part of Intel MID outdated platforms removal. It's collected into >>>>> immutable branch with a given tag, please pull to yours subsystems. >>>> >>>> Hi Andy, >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, >>>> then I should probably start looking at removing the corresponding >>>> parts in GMA500. >>> >>> I have noticed new commits in DRM against GMA500 and it seems now in a >>> conflict with my immutable branch. Are you sure you don't forget to >>> pull it? >> >> Hi Andy, sorry I missed pulling the immutable branch before taking the >> gma500 medfield removal. I was unsure how to do that through drm-misc >> and it's tools so I got sidetracked. What would be the correct way to >> fix this? > > Imo Linus can resolve this, it's pretty trivial, as long as both pull > requests point it out to him. The removal of older Intel platforms touches a number of subsystem trees, the idea about the IM branch was that all subsystem-trees would merge that. I can certainly point out the problem in the pdx86 pull-req to Linus, but the GPIO pull-req also contains a merge of the IM branch as will the x86/tip and rtc pull-reqs I believe. We can add a remark to all the pull-reqs about the issue I guess ? But it might be better to still merge the branch into drm-misc-next and resolve the conflict there. I think that should avoid Linus seeing it ? Regards, Hans
On 04/02/2021 11:50:03+0100, Hans de Goede wrote: > Hi, > > On 2/4/21 11:36 AM, Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 11:19 AM Patrik Jakobsson > > <patrik.r.jakobsson@gmail.com> wrote: > >> > >> On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko > >> <andy.shevchenko@gmail.com> wrote: > >>> > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > >>> <patrik.r.jakobsson@gmail.com> wrote: > >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > >>>> <andriy.shevchenko@linux.intel.com> wrote: > >>>>> > >>>>> Hi guys, > >>>>> > >>>>> This is first part of Intel MID outdated platforms removal. It's collected into > >>>>> immutable branch with a given tag, please pull to yours subsystems. > >>>> > >>>> Hi Andy, > >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, > >>>> then I should probably start looking at removing the corresponding > >>>> parts in GMA500. > >>> > >>> I have noticed new commits in DRM against GMA500 and it seems now in a > >>> conflict with my immutable branch. Are you sure you don't forget to > >>> pull it? > >> > >> Hi Andy, sorry I missed pulling the immutable branch before taking the > >> gma500 medfield removal. I was unsure how to do that through drm-misc > >> and it's tools so I got sidetracked. What would be the correct way to > >> fix this? > > > > Imo Linus can resolve this, it's pretty trivial, as long as both pull > > requests point it out to him. > > The removal of older Intel platforms touches a number of subsystem trees, > the idea about the IM branch was that all subsystem-trees would merge that. > > I can certainly point out the problem in the pdx86 pull-req to Linus, > but the GPIO pull-req also contains a merge of the IM branch as will > the x86/tip and rtc pull-reqs I believe. We can add a remark to all > the pull-reqs about the issue I guess ? > FWIW, I'm not going to merge the PR in the rtc tree because it is a simple removal and doesn't have any conflicts. > But it might be better to still merge the branch into drm-misc-next and > resolve the conflict there. I think that should avoid Linus seeing it ? > Linus doesn't mind seeing and solving conflicts.
On Thu, Feb 04, 2021 at 11:57:52AM +0100, Alexandre Belloni wrote: > On 04/02/2021 11:50:03+0100, Hans de Goede wrote: > > On 2/4/21 11:36 AM, Daniel Vetter wrote: > > > On Thu, Feb 4, 2021 at 11:19 AM Patrik Jakobsson > > > <patrik.r.jakobsson@gmail.com> wrote: > > >> On Wed, Feb 3, 2021 at 1:00 PM Andy Shevchenko > > >> <andy.shevchenko@gmail.com> wrote: > > >>> On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > > >>> <patrik.r.jakobsson@gmail.com> wrote: > > >>>> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko > > >>>> <andriy.shevchenko@linux.intel.com> wrote: > > >>>>> This is first part of Intel MID outdated platforms removal. It's collected into > > >>>>> immutable branch with a given tag, please pull to yours subsystems. > > >>>> > > >>>> Hi Andy, > > >>>> Do you plan on eventually removing X86_INTEL_MID completely? If so, > > >>>> then I should probably start looking at removing the corresponding > > >>>> parts in GMA500. > > >>> > > >>> I have noticed new commits in DRM against GMA500 and it seems now in a > > >>> conflict with my immutable branch. Are you sure you don't forget to > > >>> pull it? > > >> > > >> Hi Andy, sorry I missed pulling the immutable branch before taking the > > >> gma500 medfield removal. I was unsure how to do that through drm-misc > > >> and it's tools so I got sidetracked. What would be the correct way to > > >> fix this? > > > > > > Imo Linus can resolve this, it's pretty trivial, as long as both pull > > > requests point it out to him. > > > > The removal of older Intel platforms touches a number of subsystem trees, > > the idea about the IM branch was that all subsystem-trees would merge that. > > > > I can certainly point out the problem in the pdx86 pull-req to Linus, > > but the GPIO pull-req also contains a merge of the IM branch as will > > the x86/tip and rtc pull-reqs I believe. We can add a remark to all > > the pull-reqs about the issue I guess ? > > FWIW, I'm not going to merge the PR in the rtc tree because it is a > simple removal and doesn't have any conflicts. > > > But it might be better to still merge the branch into drm-misc-next and > > resolve the conflict there. I think that should avoid Linus seeing it ? > > Linus doesn't mind seeing and solving conflicts. Yes, but in this case the conflict is artificially created by us in the first place and shouldn't be there from the day 1. I consider merging immutable tag to DRM misc would be the less intrusive solution.