Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1271137 > unrolled thread
| Started by | Daniel Lezcano <daniel.lezcano@linaro.org> |
|---|---|
| First post | 2015-11-17 13:30 +0100 |
| Last post | 2015-11-17 14:20 +0100 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init Daniel Lezcano <daniel.lezcano@linaro.org> - 2015-11-17 13:30 +0100
Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init Marc Gonzalez <marc_gonzalez@sigmadesigns.com> - 2015-11-17 13:50 +0100
Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init Måns Rullgård <mans@mansr.com> - 2015-11-17 14:10 +0100
Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init Daniel Lezcano <daniel.lezcano@linaro.org> - 2015-11-17 14:20 +0100
| From | Daniel Lezcano <daniel.lezcano@linaro.org> |
|---|---|
| Date | 2015-11-17 13:30 +0100 |
| Subject | Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init |
| Message-ID | <qvNyy-4XK-21@gated-at.bofh.it> |
On 11/13/2015 01:20 PM, Marc Gonzalez wrote: > On 13/11/2015 11:58, Daniel Lezcano wrote: > >> The current code to initialize, register and read the clocksource is >> already factored out in mmio.c via the clocksource_mmio_init function. >> >> Factor out the code with the clocksource_mmio_init function. > > The reason I didn't like clocksource_mmio_init() is because it exports > 4 generic accessors. > > I guess this function makes more sense when all platforms are using it, > in an ARCH_MULTIPLATFORM kernel. (Also the accessors are probably quite > small, so the waste is probably minimal.) Hi Marc, it is not clear for me if you agree with this patch or not. Can you clarify ? Thanks -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Marc Gonzalez <marc_gonzalez@sigmadesigns.com> |
|---|---|
| Date | 2015-11-17 13:50 +0100 |
| Message-ID | <qvNRT-54p-3@gated-at.bofh.it> |
| In reply to | #1271137 |
On 17/11/2015 13:22, Daniel Lezcano wrote: > On 11/13/2015 01:20 PM, Marc Gonzalez wrote: >> On 13/11/2015 11:58, Daniel Lezcano wrote: >> >>> The current code to initialize, register and read the clocksource is >>> already factored out in mmio.c via the clocksource_mmio_init function. >>> >>> Factor out the code with the clocksource_mmio_init function. >> >> The reason I didn't like clocksource_mmio_init() is because it exports >> 4 generic accessors. >> >> I guess this function makes more sense when all platforms are using it, >> in an ARCH_MULTIPLATFORM kernel. (Also the accessors are probably quite >> small, so the waste is probably minimal.) > > Hi Marc, > > it is not clear for me if you agree with this patch or not. Can you > clarify ? [ Adding rmk as the original mmio.c author ] Hello Daniel, It's hard to give a straight answer. From my limited perspective (building a kernel for Sigma boards only) I feel that mmio.c brings nothing. (As you mentioned, it would be interesting to measure whether having reg_base in the ctx, rather than as a global is better or worse for perf, though the actual difference may be lost in the noise.) On the other hand, I can see how a different perspective, such as yours, may see benefits in having all drivers use the same APIs; and there may be other savings for ARCH_MULTIPLATFORM builds with lots of platforms. I guess if you think it is a good patch, I will defer to your experience. I just wish Thomas would take a look at my mmio patch. I will make an official submission, so that it can be properly shot down :-) Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2015-11-17 14:10 +0100 |
| Subject | Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init |
| Message-ID | <qvObg-5rX-1@gated-at.bofh.it> |
| In reply to | #1271145 |
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> writes: > On 17/11/2015 13:22, Daniel Lezcano wrote: >> On 11/13/2015 01:20 PM, Marc Gonzalez wrote: >>> On 13/11/2015 11:58, Daniel Lezcano wrote: >>> >>>> The current code to initialize, register and read the clocksource is >>>> already factored out in mmio.c via the clocksource_mmio_init function. >>>> >>>> Factor out the code with the clocksource_mmio_init function. >>> >>> The reason I didn't like clocksource_mmio_init() is because it exports >>> 4 generic accessors. >>> >>> I guess this function makes more sense when all platforms are using it, >>> in an ARCH_MULTIPLATFORM kernel. (Also the accessors are probably quite >>> small, so the waste is probably minimal.) >> >> Hi Marc, >> >> it is not clear for me if you agree with this patch or not. Can you >> clarify ? > > [ Adding rmk as the original mmio.c author ] > > Hello Daniel, > > It's hard to give a straight answer. From my limited perspective (building > a kernel for Sigma boards only) I feel that mmio.c brings nothing. (As you > mentioned, it would be interesting to measure whether having reg_base in > the ctx, rather than as a global is better or worse for perf, though the > actual difference may be lost in the noise.) > > On the other hand, I can see how a different perspective, such as yours, > may see benefits in having all drivers use the same APIs; and there may > be other savings for ARCH_MULTIPLATFORM builds with lots of platforms. I think the patch is good. If there are issues with clocksource_mmio those should addressed separately. -- Måns Rullgård mans@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Daniel Lezcano <daniel.lezcano@linaro.org> |
|---|---|
| Date | 2015-11-17 14:20 +0100 |
| Message-ID | <qvOkV-5vY-3@gated-at.bofh.it> |
| In reply to | #1271145 |
On 11/17/2015 01:48 PM, Marc Gonzalez wrote: > On 17/11/2015 13:22, Daniel Lezcano wrote: >> On 11/13/2015 01:20 PM, Marc Gonzalez wrote: >>> On 13/11/2015 11:58, Daniel Lezcano wrote: >>> >>>> The current code to initialize, register and read the clocksource is >>>> already factored out in mmio.c via the clocksource_mmio_init function. >>>> >>>> Factor out the code with the clocksource_mmio_init function. >>> >>> The reason I didn't like clocksource_mmio_init() is because it exports >>> 4 generic accessors. >>> >>> I guess this function makes more sense when all platforms are using it, >>> in an ARCH_MULTIPLATFORM kernel. (Also the accessors are probably quite >>> small, so the waste is probably minimal.) >> >> Hi Marc, >> >> it is not clear for me if you agree with this patch or not. Can you >> clarify ? > > [ Adding rmk as the original mmio.c author ] Good idea. Russell, the patch is https://lkml.org/lkml/2015/11/13/261 > Hello Daniel, > > It's hard to give a straight answer. From my limited perspective (building > a kernel for Sigma boards only) I feel that mmio.c brings nothing. (As you > mentioned, it would be interesting to measure whether having reg_base in > the ctx, rather than as a global is better or worse for perf, though the > actual difference may be lost in the noise.) > > On the other hand, I can see how a different perspective, such as yours, > may see benefits in having all drivers use the same APIs; and there may > be other savings for ARCH_MULTIPLATFORM builds with lots of platforms. IMO, if all the drivers are using the same code, then optimizing it will benefit to all drivers at the same time. > I guess if you think it is a good patch, I will defer to your experience. Ok, I will wait for Russell comments then. Thanks! -- Daniel > I just wish Thomas would take a look at my mmio patch. I will make an > official submission, so that it can be properly shot down :-) -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web