| Message ID | 1450975076-7411-2-git-send-email-ivo.g.dimitrov.75@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote: > So it can be used by code outside arch/arm/kernel/. Fix save_atags() > declaration to match its definition while at it. > > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com>
* Pali Rohár <pali.rohar@gmail.com> [151224 09:48]: > On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote: > > So it can be used by code outside arch/arm/kernel/. Fix save_atags() > > declaration to match its definition while at it. > > > > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> > > Tested-by: Pali Rohár <pali.rohar@gmail.com> Nice, please upload both to Russell's patch system after no more comments: Acked-by: Tony Lindgren <tony@atomide.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24.12.2015 20:53, Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [151224 09:48]: >> On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote: >>> So it can be used by code outside arch/arm/kernel/. Fix save_atags() >>> declaration to match its definition while at it. >>> >>> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> >> >> Tested-by: Pali Rohár <pali.rohar@gmail.com> > > Nice, please upload both to Russell's patch system after no > more comments: > > Acked-by: Tony Lindgren <tony@atomide.com> > Hi Tony, Could you elaborate on that patch system? Where it is and do I need some special account/access? Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > Could you elaborate on that patch system? Where it is and do I need some > special account/access? Sorry going through my pending mail and only now noticed this one. Looks like you got it figured out though as the patches are in mainline now :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jan 21, 2016 at 02:02:55PM -0800, Tony Lindgren wrote: > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > > Could you elaborate on that patch system? Where it is and do I > > need some special account/access? > > Sorry going through my pending mail and only now noticed this > one. Looks like you got it figured out though as the patches > are in mainline now :) IIRC this was the last blocker for removing n900 legacy code? will it finally be gone in v4.6? -- Sebastian
* Sebastian Reichel <sre@kernel.org> [160127 16:06]: > Hi, > > On Thu, Jan 21, 2016 at 02:02:55PM -0800, Tony Lindgren wrote: > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > > > Could you elaborate on that patch system? Where it is and do I > > > need some special account/access? > > > > Sorry going through my pending mail and only now noticed this > > one. Looks like you got it figured out though as the patches > > are in mainline now :) > > IIRC this was the last blocker for removing n900 legacy code? > will it finally be gone in v4.6? Yes I think we should do that but keep all the platform data intact until v4.7. Let's start a separate thread on that with all the n900 people in Cc. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 28 January 2016 01:05:53 Sebastian Reichel wrote: > Hi, > > On Thu, Jan 21, 2016 at 02:02:55PM -0800, Tony Lindgren wrote: > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > > > Could you elaborate on that patch system? Where it is and do I > > > need some special account/access? > > > > Sorry going through my pending mail and only now noticed this > > one. Looks like you got it figured out though as the patches > > are in mainline now :) > > IIRC this was the last blocker for removing n900 legacy code? No! I know at least two missing-feature regressions in DT booted kernel: * slot name in sysfs for omap mmc devices * missing DT support for ir-rx51 driver Plus, before removing board-rx51.c file we should backup or convert to DT this C-state cpuidle table (to prevent its lost): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51.c#n62
* Pali Rohár <pali.rohar@gmail.com> [160128 00:34]: > On Thursday 28 January 2016 01:05:53 Sebastian Reichel wrote: > > Hi, > > > > On Thu, Jan 21, 2016 at 02:02:55PM -0800, Tony Lindgren wrote: > > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > > > > Could you elaborate on that patch system? Where it is and do I > > > > need some special account/access? > > > > > > Sorry going through my pending mail and only now noticed this > > > one. Looks like you got it figured out though as the patches > > > are in mainline now :) > > > > IIRC this was the last blocker for removing n900 legacy code? > > No! I know at least two missing-feature regressions in DT booted kernel: > > * slot name in sysfs for omap mmc devices Can't you do this already by passing platform_data in addition to dts using pdata-quirks.c? Then when we have a generic binding for this we can move to use that. > * missing DT support for ir-rx51 driver I believe this still works the same as ever with platform_data if you completely disable multiarch. However, that's not a good solution, it's best to update it to use the generic drivers/pwm/pwm-omap-dmtimer.c. I can take a look at this one no problem unless somebody else is already working on it. > Plus, before removing board-rx51.c file we should backup or convert to > DT this C-state cpuidle table (to prevent its lost): > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51.c#n62 Oh you mean just the table in the comments there? We have board-rx51.c still available in git log so I think we have plenty of back up versions of that :) $ git show v4.4:arch/arm/mach-omap2/board-rx51.c Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jan 28, 2016 at 08:17:24AM -0800, Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [160128 00:34]: > > On Thursday 28 January 2016 01:05:53 Sebastian Reichel wrote: > > > IIRC this was the last blocker for removing n900 legacy code? > > > > No! I know at least two missing-feature regressions in DT booted > > kernel: > > > > * slot name in sysfs for omap mmc devices > > Can't you do this already by passing platform_data in addition to > dts using pdata-quirks.c? > > Then when we have a generic binding for this we can move to use > that. I guess the driver must be modified to check and parse platform_data if initalised via DT, but I think this could be done in time for v4.6. > > * missing DT support for ir-rx51 driver > > I believe this still works the same as ever with platform_data if > you completely disable multiarch. However, that's not a good > solution, it's best to update it to use the generic > drivers/pwm/pwm-omap-dmtimer.c. > > I can take a look at this one no problem unless somebody else > is already working on it. I had a look at it some time ago. IIRC one can simply replace the <plat/clock.h> with <linux/clk.h>. The dmtimer part requires more work, since it uses two dmtimers: One in PWM mode (the output of this one is connected to the IR led). This one could probably be converted to pwm-omap-dmtimer. But it also uses a second one for calculating the pulse length. I have not yet tried it, but I guess converting is not really trivial. OTOH it's also broken for quite some time (3.8!) on multiplatform, so I wonder if this is really a blocker. Has this been compiled by anybody on an unpatches mainline kernel since then? Maybe it could be fixed after switching to DT only? -- Sebastian
* Sebastian Reichel <sre@kernel.org> [160128 08:43]: > Hi, > > On Thu, Jan 28, 2016 at 08:17:24AM -0800, Tony Lindgren wrote: > > * Pali Rohár <pali.rohar@gmail.com> [160128 00:34]: > > > On Thursday 28 January 2016 01:05:53 Sebastian Reichel wrote: > > > > IIRC this was the last blocker for removing n900 legacy code? > > > > > > No! I know at least two missing-feature regressions in DT booted > > > kernel: > > > > > > * slot name in sysfs for omap mmc devices > > > > Can't you do this already by passing platform_data in addition to > > dts using pdata-quirks.c? > > > > Then when we have a generic binding for this we can move to use > > that. > > I guess the driver must be modified to check and parse platform_data > if initalised via DT, but I think this could be done in time for > v4.6. Yes for sure. There's nothing stopping having both platform_data and data from dts available in driver probe. Coming up with a generic binding then can be done as a follow-up project. > > > * missing DT support for ir-rx51 driver > > > > I believe this still works the same as ever with platform_data if > > you completely disable multiarch. However, that's not a good > > solution, it's best to update it to use the generic > > drivers/pwm/pwm-omap-dmtimer.c. > > > > I can take a look at this one no problem unless somebody else > > is already working on it. > > I had a look at it some time ago. IIRC one can simply replace the > <plat/clock.h> with <linux/clk.h>. The dmtimer part requires more > work, since it uses two dmtimers: One in PWM mode (the output of > this one is connected to the IR led). This one could probably be > converted to pwm-omap-dmtimer. But it also uses a second one for > calculating the pulse length. I have not yet tried it, but I guess > converting is not really trivial. OK. I'll take a look. We may get away with hrtimer for the pulse length calculation. > OTOH it's also broken for quite some time (3.8!) on multiplatform, > so I wonder if this is really a blocker. Has this been compiled > by anybody on an unpatches mainline kernel since then? Maybe it > could be fixed after switching to DT only? Right.. I doubt anybody has been using the non-multiplatform configuration for ages on omaps. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [160128 09:06]: > * Sebastian Reichel <sre@kernel.org> [160128 08:43]: > > > OTOH it's also broken for quite some time (3.8!) on multiplatform, > > so I wonder if this is really a blocker. Has this been compiled > > by anybody on an unpatches mainline kernel since then? Maybe it > > could be fixed after switching to DT only? > > Right.. I doubt anybody has been using the non-multiplatform > configuration for ages on omaps. But yeah, the ir-rx51.c regression a multiarch related related problem and not a legacy vs DT based booting issue. AFAIK the same regression exists with mainline with legacy booting too. We still should get it fixed of course :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 28 January 2016 08:17:24 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [160128 00:34]: > > On Thursday 28 January 2016 01:05:53 Sebastian Reichel wrote: > > > Hi, > > > > > > On Thu, Jan 21, 2016 at 02:02:55PM -0800, Tony Lindgren wrote: > > > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [151224 11:02]: > > > > > Could you elaborate on that patch system? Where it is and do I > > > > > need some special account/access? > > > > > > > > Sorry going through my pending mail and only now noticed this > > > > one. Looks like you got it figured out though as the patches > > > > are in mainline now :) > > > > > > IIRC this was the last blocker for removing n900 legacy code? > > > > No! I know at least two missing-feature regressions in DT booted kernel: > > > > * slot name in sysfs for omap mmc devices > > Can't you do this already by passing platform_data in addition to > dts using pdata-quirks.c? After patching omap hsmmc driver it could be possible. But I do not like this solution as it duplicate omap hsmmc DT specification from nokia n900 DTS file to board pdata-quirks file. It means that in nokia n900 DTS file will be mmc information which will not be used and this is not correct in the way how we use DTS files. > Then when we have a generic binding for this we can move to use > that. > > > * missing DT support for ir-rx51 driver > > I believe this still works the same as ever with platform_data if > you completely disable multiarch. However, that's not a good > solution, it's best to update it to use the generic > drivers/pwm/pwm-omap-dmtimer.c. > > I can take a look at this one no problem unless somebody else > is already working on it. It also needs porting driver to support multiarch. It you have time for it, you can take it. > > Plus, before removing board-rx51.c file we should backup or convert to > > DT this C-state cpuidle table (to prevent its lost): > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51.c#n62 > > Oh you mean just the table in the comments there? Yes, that table in comments. > We have board-rx51.c still available in git log so I think we > have plenty of back up versions of that :) > > $ git show v4.4:arch/arm/mach-omap2/board-rx51.c I know, but how many users and developers are looking into git *history* if they need to know what is missing in *current* kernel? I think that removing board-rx51.c file would mean that table is lost and everybody forget that this table needs to be ported to nokia n900 DTS file.
Hi, * Pali Rohár <pali.rohar@gmail.com> [160129 00:32]: > But I do not like this solution as it duplicate omap hsmmc DT > specification from nokia n900 DTS file to board pdata-quirks file. > > It means that in nokia n900 DTS file will be mmc information which will > not be used and this is not correct in the way how we use DTS files. I think you're misunderstanding the above a bit here.. We can pass both dts data and auxilary platform_data to the driver. So only need to pass the slot names in the aux data set in pdata-quirks.c based on the mmc device IO address. > I know, but how many users and developers are looking into git *history* > if they need to know what is missing in *current* kernel? > > I think that removing board-rx51.c file would mean that table is lost > and everybody forget that this table needs to be ported to nokia n900 > DTS file. How about send a patch to copy those comments to board-n900.dts too? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 29 January 2016 08:20:26 Tony Lindgren wrote: > Hi, > > * Pali Rohár <pali.rohar@gmail.com> [160129 00:32]: > > But I do not like this solution as it duplicate omap hsmmc DT > > specification from nokia n900 DTS file to board pdata-quirks file. > > > > It means that in nokia n900 DTS file will be mmc information which will > > not be used and this is not correct in the way how we use DTS files. > > I think you're misunderstanding the above a bit here.. We can pass > both dts data and auxilary platform_data to the driver. So only > need to pass the slot names in the aux data set in pdata-quirks.c > based on the mmc device IO address. That would means to change omap hsmmc driver a bit more... I do not it could be simple... > > I know, but how many users and developers are looking into git *history* > > if they need to know what is missing in *current* kernel? > > > > I think that removing board-rx51.c file would mean that table is lost > > and everybody forget that this table needs to be ported to nokia n900 > > DTS file. > > How about send a patch to copy those comments to board-n900.dts > too? Ok, I'm fine with it. But I would like to see cpuidle omap support in DT.
* Pali Rohár <pali.rohar@gmail.com> [160208 01:14]: > On Friday 29 January 2016 08:20:26 Tony Lindgren wrote: > > Hi, > > > > * Pali Rohár <pali.rohar@gmail.com> [160129 00:32]: > > > But I do not like this solution as it duplicate omap hsmmc DT > > > specification from nokia n900 DTS file to board pdata-quirks file. > > > > > > It means that in nokia n900 DTS file will be mmc information which will > > > not be used and this is not correct in the way how we use DTS files. > > > > I think you're misunderstanding the above a bit here.. We can pass > > both dts data and auxilary platform_data to the driver. So only > > need to pass the slot names in the aux data set in pdata-quirks.c > > based on the mmc device IO address. > > That would means to change omap hsmmc driver a bit more... I do not it > could be simple... I think all it takes is just copying over the slot names from pdev->dev.platform_data in of_get_hsmmc_pdata()? Looks like you need to use container_of() there to get the pdev, or change it to pass pdev to of_get_hsmmc_pdata() though. > > > I know, but how many users and developers are looking into git *history* > > > if they need to know what is missing in *current* kernel? > > > > > > I think that removing board-rx51.c file would mean that table is lost > > > and everybody forget that this table needs to be ported to nokia n900 > > > DTS file. > > > > How about send a patch to copy those comments to board-n900.dts > > too? > > Ok, I'm fine with it. But I would like to see cpuidle omap support in DT. Hmm but we're already using arch/arm/mach-omap2/cpuidle34xx.c to hit deeper idle states for DT based booting too? Or maybe you mean something else? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 08 February 2016 21:22:10 Tony Lindgren wrote: > > > > I know, but how many users and developers are looking into git > > > > *history* if they need to know what is missing in *current* > > > > kernel? > > > > > > > > I think that removing board-rx51.c file would mean that table > > > > is lost and everybody forget that this table needs to be > > > > ported to nokia n900 DTS file. > > > > > > How about send a patch to copy those comments to board-n900.dts > > > too? > > > > Ok, I'm fine with it. But I would like to see cpuidle omap support > > in DT. > > Hmm but we're already using arch/arm/mach-omap2/cpuidle34xx.c > to hit deeper idle states for DT based booting too? Or maybe > you mean something else? And this is our problem. Nokia N900 needs different cpu idle parameters as hardcoded in cpuidle34xx.c file. And because they are not in DT, but in kernel source code, we cannot overwrite them from n900 DTS file.
* Pali Rohár <pali.rohar@gmail.com> [160208 12:37]: > On Monday 08 February 2016 21:22:10 Tony Lindgren wrote: > > > > > I know, but how many users and developers are looking into git > > > > > *history* if they need to know what is missing in *current* > > > > > kernel? > > > > > > > > > > I think that removing board-rx51.c file would mean that table > > > > > is lost and everybody forget that this table needs to be > > > > > ported to nokia n900 DTS file. > > > > > > > > How about send a patch to copy those comments to board-n900.dts > > > > too? > > > > > > Ok, I'm fine with it. But I would like to see cpuidle omap support > > > in DT. > > > > Hmm but we're already using arch/arm/mach-omap2/cpuidle34xx.c > > to hit deeper idle states for DT based booting too? Or maybe > > you mean something else? > > And this is our problem. Nokia N900 needs different cpu idle parameters > as hardcoded in cpuidle34xx.c file. And because they are not in DT, but > in kernel source code, we cannot overwrite them from n900 DTS file. Oh. Can we set different parameters in omap3_idle_init() based on the soc_is_omap34xx()? You'd assume these parameters are SoC specific, not board specific? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 08 February 2016 21:42:29 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [160208 12:37]: > > On Monday 08 February 2016 21:22:10 Tony Lindgren wrote: > > > > > > I know, but how many users and developers are looking into > > > > > > git *history* if they need to know what is missing in > > > > > > *current* kernel? > > > > > > > > > > > > I think that removing board-rx51.c file would mean that > > > > > > table is lost and everybody forget that this table needs > > > > > > to be ported to nokia n900 DTS file. > > > > > > > > > > How about send a patch to copy those comments to > > > > > board-n900.dts too? > > > > > > > > Ok, I'm fine with it. But I would like to see cpuidle omap > > > > support in DT. > > > > > > Hmm but we're already using arch/arm/mach-omap2/cpuidle34xx.c > > > to hit deeper idle states for DT based booting too? Or maybe > > > you mean something else? > > > > And this is our problem. Nokia N900 needs different cpu idle > > parameters as hardcoded in cpuidle34xx.c file. And because they > > are not in DT, but in kernel source code, we cannot overwrite them > > from n900 DTS file. > > Oh. Can we set different parameters in omap3_idle_init() > based on the soc_is_omap34xx()? We had it and it was removed, see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc > You'd assume these parameters are SoC specific, not board > specific? Looks like board specific. > Regards, > > Tony This ATAGS thread is too big now and dicussion about cpuidle I already started in different thread named "Re: Nokia N900: Proper C-states". You are CCed, so better reply here. Sorry for interrupting :-)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h index e0adb9f..3613d7e 100644 --- a/arch/arm/include/asm/setup.h +++ b/arch/arm/include/asm/setup.h @@ -25,4 +25,10 @@ extern int arm_add_memory(u64 start, u64 size); extern void early_print(const char *str, ...); extern void dump_machine_table(void); +#ifdef CONFIG_ATAGS_PROC +extern void save_atags(const struct tag *tags); +#else +static inline void save_atags(const struct tag *tags) { } +#endif + #endif diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h index ec4164d..edfa226 100644 --- a/arch/arm/kernel/atags.h +++ b/arch/arm/kernel/atags.h @@ -1,9 +1,3 @@ -#ifdef CONFIG_ATAGS_PROC -extern void save_atags(struct tag *tags); -#else -static inline void save_atags(struct tag *tags) { } -#endif - void convert_to_tag_list(struct tag *tags); #ifdef CONFIG_ATAGS
So it can be used by code outside arch/arm/kernel/. Fix save_atags() declaration to match its definition while at it. Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> --- arch/arm/include/asm/setup.h | 6 ++++++ arch/arm/kernel/atags.h | 6 ------ 2 files changed, 6 insertions(+), 6 deletions(-)