Re: [PATCH v4 2/2] irqchip: add support for Sigma Designs SMP86xx/SMP87xx interrupt controller

On 09/02/2016 10:33, Marc Zyngier wrote: > As I already said on IRC, one of us (Thomas, Jason or me) will queue it, > and it will eventually appear in the branches documented in the > MAINTAINERS file. Thanks for bringing the T field in the MAINTAINERS file to my attention, I had managed to

Re: [PATCH] ARM: tango: use "depends on" instead of "if" after prompt

mada > --- > > arch/arm/mach-tango/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Acked-by: Marc Gonzalez

Re: [PATCH] ARM: tango: use const and __initconst for smp_operations

p.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marc Gonzalez

Re: [PATCH] ARM: tango: use const and __initconst for smp_operations

> arch/arm/mach-tango/platsmp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com>

Re: [PATCH] ARM: tango: use "depends on" instead of "if" after prompt

asahiro Yamada <yamada.masah...@socionext.com> > --- > > arch/arm/mach-tango/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Acked-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com>

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 22/01/2016 17:39, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 22/01/2016 17:35, Måns Rullgård wrote: >> >>> Marc Gonzalez writes: >>> >>>> With your latest patch, can I drop the ranges property? >>> >>> Why wo

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 22/01/2016 17:35, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 20/01/2016 19:09, Måns Rullgård wrote: >> >>> Marc Gonzalez writes: >>> >>>> On 20/01/2016 17:38, Måns Rullgård wrote: >>>> >>>>> M

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 19:09, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 20/01/2016 17:38, Måns Rullgård wrote: >> >>> Marc Gonzalez writes: >>> >>>> On 20/01/2016 17:25, Måns Rullgård wrote: >>>> >>>>>

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 22/01/2016 17:35, Måns Rullgård wrote: > Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: > >> On 20/01/2016 19:09, Måns Rullgård wrote: >> >>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: >>> >>>> On 20/01/2016 17:3

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 22/01/2016 17:39, Måns Rullgård wrote: > Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: > >> On 22/01/2016 17:35, Måns Rullgård wrote: >> >>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: >>> >>>> With your latest

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 19:09, Måns Rullgård wrote: > Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: > >> On 20/01/2016 17:38, Måns Rullgård wrote: >> >>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: >>> >>>> On 20/01/2016 17

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 18:02, Mark Rutland wrote: > When you put together the binding document, please point out that the > ranges property is necessary. I don't quite understand. Can I write the node without a ranges property, and the driver would still function correctly? Regards.

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:38, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 20/01/2016 17:25, Måns Rullgård wrote: >> >>> Marc Zyngier writes: >>> >>>> On 20/01/16 16:10, Måns Rullgård wrote: >>>> >>>>> Marc

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:25, Måns Rullgård wrote: > Marc Zyngier writes: > >> On 20/01/16 16:10, Måns Rullgård wrote: >> >>> Marc Zyngier writes: >>> > + if (of_property_read_u32(node, "reg", )) > + panic("%s: failed to get reg base", node->name); > + > + chip =

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:10, Måns Rullgård wrote: > Marc Zyngier wrote: > >>> + if (of_property_read_u32(node, "reg", )) >>> + panic("%s: failed to get reg base", node->name); >>> + >>> + chip = kzalloc(sizeof(*chip), GFP_KERNEL); >>> + chip->ctl = ctl; >>> + chip->base = base; > > As

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 18:02, Mark Rutland wrote: > When you put together the binding document, please point out that the > ranges property is necessary. I don't quite understand. Can I write the node without a ranges property, and the driver would still function correctly? Regards.

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:38, Måns Rullgård wrote: > Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes: > >> On 20/01/2016 17:25, Måns Rullgård wrote: >> >>> Marc Zyngier <marc.zyng...@arm.com> writes: >>> >>>> On 20/01/16 16:10, Måns R

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:10, Måns Rullgård wrote: > Marc Zyngier wrote: > >>> + if (of_property_read_u32(node, "reg", )) >>> + panic("%s: failed to get reg base", node->name); >>> + >>> + chip = kzalloc(sizeof(*chip), GFP_KERNEL); >>> + chip->ctl = ctl; >>> + chip->base = base; > > As

Re: [RFC PATCH v3] irqchip: Add support for Tango interrupt controller

On 20/01/2016 17:25, Måns Rullgård wrote: > Marc Zyngier writes: > >> On 20/01/16 16:10, Måns Rullgård wrote: >> >>> Marc Zyngier writes: >>> > + if (of_property_read_u32(node, "reg", )) > + panic("%s: failed to get reg base",

Re: m(un)map kmalloc buffers to userspace

On 09/12/2015 14:55, Michal Hocko wrote: > On Tue 08-12-15 18:25:31, Sebastian Frias wrote: >> Hi, >> >> We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9. >> >> The driver maps kmalloc'ed memory to user space. > > This sounds like a terrible idea to me. Why don't you simply

Re: m(un)map kmalloc buffers to userspace

On 09/12/2015 14:55, Michal Hocko wrote: > On Tue 08-12-15 18:25:31, Sebastian Frias wrote: >> Hi, >> >> We are porting a driver from Linux 3.4.39+ to 4.1.13+, CPU is Cortex-A9. >> >> The driver maps kmalloc'ed memory to user space. > > This sounds like a terrible idea to me. Why don't you simply

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 14:57, Thomas Gleixner wrote: > On Thu, 19 Nov 2015, Marc Gonzalez wrote: >> On 19/11/2015 12:14, Thomas Gleixner wrote: >> >>> So yes, the alignment of the clocksource struct is not longer >>> relevant. The case where we acces

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 14:57, Thomas Gleixner wrote: > On Thu, 19 Nov 2015, Marc Gonzalez wrote: >> On 19/11/2015 12:14, Thomas Gleixner wrote: >> >>> So yes, the alignment of the clocksource struct is not longer >>> relevant. The case where we acces

Re: clk: tango4: undefined CONFIG_ARCH_TANGOX

On 20/11/2015 09:50, Valentin Rothberg wrote: > your commit ed12dfc92f01 ("clk: tango4: clkgen driver for Tango4 > platforms") has shown up in today's linux-next tree (i.e., > next-20151120) adding the following build condition to the tango4 clk > driver: > >

Re: clk: tango4: undefined CONFIG_ARCH_TANGOX

On 20/11/2015 09:50, Valentin Rothberg wrote: > your commit ed12dfc92f01 ("clk: tango4: clkgen driver for Tango4 > platforms") has shown up in today's linux-next tree (i.e., > next-20151120) adding the following build condition to the tango4 clk > driver: > >

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 12:21, Russell King wrote: > When I wrote the MMIO clocksource implementation, there was no > cacheline_aligned on struct clocksource, and the arrangement I came > to for the structure put the 'reg' and 'read' within the same cache line > (note that the MMIO clocksource

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 12:14, Thomas Gleixner wrote: > So yes, the alignment of the clocksource struct is not longer > relevant. The case where we access clocksource->max_cycles is when > CONFIG_DEBUG_TIMEKEEPING is enabled, which imposes worse performance > problems to timekeeping than the extra

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 11:36, Russell King - ARM Linux wrote: > On Thu, Nov 19, 2015 at 11:33:47AM +0100, Thomas Gleixner wrote: >> Russell, >> >> On Wed, 18 Nov 2015, Russell King - ARM Linux wrote: >> >>> On Wed, Nov 18, 2015 at 02:43:34PM +0100, Marc Gonzalez w

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 18/11/2015 18:21, Russell King - ARM Linux wrote: > On Wed, Nov 18, 2015 at 02:43:34PM +0100, Marc Gonzalez wrote: > >> Since 'struct clocksource' is cacheline_aligned, gcc must insert >> a lot of padding between reg and clksrc in 'struct clocksource_mmio' >> (for

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 18/11/2015 18:21, Russell King - ARM Linux wrote: > On Wed, Nov 18, 2015 at 02:43:34PM +0100, Marc Gonzalez wrote: > >> Since 'struct clocksource' is cacheline_aligned, gcc must insert >> a lot of padding between reg and clksrc in 'struct clocksource_mmio' >> (for

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 12:21, Russell King wrote: > When I wrote the MMIO clocksource implementation, there was no > cacheline_aligned on struct clocksource, and the arrangement I came > to for the structure put the 'reg' and 'read' within the same cache line > (note that the MMIO clocksource

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 12:14, Thomas Gleixner wrote: > So yes, the alignment of the clocksource struct is not longer > relevant. The case where we access clocksource->max_cycles is when > CONFIG_DEBUG_TIMEKEEPING is enabled, which imposes worse performance > problems to timekeeping than the extra

Re: [PATCH] clocksource: Store reg field within struct clocksource

On 19/11/2015 11:36, Russell King - ARM Linux wrote: > On Thu, Nov 19, 2015 at 11:33:47AM +0100, Thomas Gleixner wrote: >> Russell, >> >> On Wed, 18 Nov 2015, Russell King - ARM Linux wrote: >> >>> On Wed, Nov 18, 2015 at 02:43:34PM +0100, Marc Gonzalez w

[PATCH] clocksource: Store reg field within struct clocksource

| +++ | max_idle_ns | +++ Signed-off-by: Marc Gonzalez --- drivers/clocksource/mmio.c | 36 +--- include/linux/clocksource.h | 3 +++ 2 files changed, 16 insertions(+), 23

[PATCH] clocksource: Store reg field within struct clocksource

| +++ | max_idle_ns | +++ Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- drivers/clocksource/mmio.c | 36 +--- include/linux/clocksource.h | 3

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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 t

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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 t

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

On 13/11/2015 16:26, Thomas Gleixner wrote: > On Fri, 13 Nov 2015, Marc Gonzalez wrote: >> On 13/11/2015 15:16, Daniel Lezcano wrote: >>> For example: >>> >>> struct clockcommon { >>> u32 mult; >>> u32 shift; >>> int rati

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

On 13/11/2015 15:16, 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 t

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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. > > Signed-off-by: Daniel Lezcano > --- >

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

On 13/11/2015 16:26, Thomas Gleixner wrote: > On Fri, 13 Nov 2015, Marc Gonzalez wrote: >> On 13/11/2015 15:16, Daniel Lezcano wrote: >>> For example: >>> >>> struct clockcommon { >>> u32 mult; >>> u32 shift; >>> int rati

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

On 13/11/2015 15:16, 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 t

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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

Re: [PATCH] clocksource/drivers/tango-xtal: Replace code by clocksource_mmio_init

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. > > Signed-off-by: Daniel Lezcano

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 26/10/2015 14:54, Måns Rullgård wrote: > Let's try something else: > > Device trees list the exact chip, the oldest chip with the same > features, and the oldest compatible chip. From the sound of things, > that means the smp8759 should use "sigma,smp8759-ethernet", >

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 26/10/2015 13:05, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 23/10/2015 15:41, Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> >>>> On 22/10/2015 16:02, Mans Rullgard wrote: >>>> >>>>> This adds a bin

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 23/10/2015 15:41, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> On 22/10/2015 16:02, Mans Rullgard wrote: >> >>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller >>> using the "aurora,nb8800" compatible string. When us

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 23/10/2015 15:41, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> On 22/10/2015 16:02, Mans Rullgard wrote: >> >>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller >>> using the "aurora,nb8800" compatible string. When us

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 26/10/2015 13:05, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 23/10/2015 15:41, Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> >>>> On 22/10/2015 16:02, Mans Rullgard wrote: >>>> >>>>> This adds a bin

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 26/10/2015 14:54, Måns Rullgård wrote: > Let's try something else: > > Device trees list the exact chip, the oldest chip with the same > features, and the oldest compatible chip. From the sound of things, > that means the smp8759 should use "sigma,smp8759-ethernet", >

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 23/10/2015 15:41, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> On 22/10/2015 16:02, Mans Rullgard wrote: >> >>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller >>> using the "aurora,nb8800" compatible string. When us

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 22/10/2015 16:02, Mans Rullgard wrote: > This adds a binding for the Aurora VLSI NB8800 Ethernet controller > using the "aurora,nb8800" compatible string. When used in Sigma > Designs chips a few additional control registers are available. > This variant is indicated by the

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 23/10/2015 15:41, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> On 22/10/2015 16:02, Mans Rullgard wrote: >> >>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller >>> using the "aurora,nb8800" compatible string. When us

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

On 22/10/2015 16:02, Mans Rullgard wrote: > This adds a binding for the Aurora VLSI NB8800 Ethernet controller > using the "aurora,nb8800" compatible string. When used in Sigma > Designs chips a few additional control registers are available. > This variant is indicated by the

Re: [PATCH] clk: add support for Sigma Designs SMP86xx/87xx clocks

On 09/10/2015 14:35, Mans Rullgard wrote: > This adds support for most of the clocks in the Sigma Designs > SMP86xx (tango3) and SMP87xx (tango4) chips. > > Signed-off-by: Mans Rullgard > --- > I'm sending this now to avoid the maintainers wasting more time reviewing > the woefully incomplete

Re: [PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 09/10/2015 18:01, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> >>>> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >>>> Use it for clocksource, sched_clock

Re: [PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Måns Rullgård wrote: > Marc Gonzalez wrote: > >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. > > Given the nature of this hardware, I think it would make much more sense > to supp

[PATCH v5] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- drivers/clocksource/Kconfig | 4 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/tango_xtal.c | 66

[PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- drivers/clocksource/Kconfig | 4 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/tango_xtal.c | 71

Re: [PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 09/10/2015 15:24, Daniel Lezcano wrote: > On 10/09/2015 02:13 PM, Marc Gonzalez wrote: >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. >> >> Signed-off-by: Marc Gonzalez >>

[PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- I have a nagging feeling that the QUIT_IF macro will get this patch NAKed ;-) My rationale: error-handling tends to take the focus away from

Re: [PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 09/10/2015 18:01, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> >>>> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >>>> Use it for clocksource, sched_clock

Re: [PATCH] clk: add support for Sigma Designs SMP86xx/87xx clocks

On 09/10/2015 14:35, Mans Rullgard wrote: > This adds support for most of the clocks in the Sigma Designs > SMP86xx (tango3) and SMP87xx (tango4) chips. > > Signed-off-by: Mans Rullgard > --- > I'm sending this now to avoid the maintainers wasting more time reviewing > the

[PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- I have a nagging feeling that the QUIT_IF macro will get this patch NAKed ;-) My rationale: error-ha

[PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- drivers/clocksource/Kconfig | 4 +++ drivers/clocksource/Makefile | 1 + drivers/clock

Re: [PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 09/10/2015 15:24, Daniel Lezcano wrote: > On 10/09/2015 02:13 PM, Marc Gonzalez wrote: >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. >> >> Signed-off-by: Marc Gonzalez <marc_gonza...

[PATCH v5] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- drivers/clocksource/Kconfig | 4 +++ drivers/clocksource/Makefile | 1 + drivers/clock

Re: [PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Måns Rullgård wrote: > Marc Gonzalez wrote: > >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. > > Given the nature of this hardware, I think it would make much more sense > to supp

Re: [PATCH v2] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 07/10/2015 14:31, Daniel Lezcano wrote: > On 10/07/2015 01:35 PM, Marc Gonzalez wrote: >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. >> >> Signed-off-by: Marc Gonzalez >> --- &

[PATCH v2] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- AFAICS, clocksource_register_hz does not report failures via its return value (always 0) but writes warnings to stdout? Open question: can I

Re: [PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

On 07/10/2015 11:47, Daniel Lezcano wrote: > On 10/07/2015 10:23 AM, Marc Gonzalez wrote: >> Daniel Lezcano wrote: >> >>> static u64 *notrace* read_sched_clock(void) >> >> What about read_clocksource? and read_xtal_counter? > > See commit 89e

Re: [PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

Hello everyone, On 07/10/2015 01:09, Daniel Lezcano wrote: > On 10/06/2015 05:10 PM, Marc Gonzalez wrote: >> Date: Tue, 6 Oct 2015 16:49:28 +0200 >> Subject: [PATCH] clocksource: Sigma Designs Tango 27 MHz xtal > > Fix the patch format. OK. > Subject is clocksource/dri

Re: [PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

Hello everyone, On 07/10/2015 01:09, Daniel Lezcano wrote: > On 10/06/2015 05:10 PM, Marc Gonzalez wrote: >> Date: Tue, 6 Oct 2015 16:49:28 +0200 >> Subject: [PATCH] clocksource: Sigma Designs Tango 27 MHz xtal > > Fix the patch format. OK. > Subject is clocksource/dri

Re: [PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

On 07/10/2015 11:47, Daniel Lezcano wrote: > On 10/07/2015 10:23 AM, Marc Gonzalez wrote: >> Daniel Lezcano wrote: >> >>> static u64 *notrace* read_sched_clock(void) >> >> What about read_clocksource? and read_xtal_counter? > > See commit 89e

[PATCH v2] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- AFAICS, clocksource_register_hz does not report failures via its return value (always 0) but writes wa

Re: [PATCH v2] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 07/10/2015 14:31, Daniel Lezcano wrote: > On 10/07/2015 01:35 PM, Marc Gonzalez wrote: >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. >> >> Signed-off-by: Marc Gonzalez <

[PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

Date: Tue, 6 Oct 2015 16:49:28 +0200 Subject: [PATCH] clocksource: Sigma Designs Tango 27 MHz xtal Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- drivers/clocksource/Makefile | 1

[PATCH v1] clocksource: Sigma Designs Tango 27 MHz xtal

Date: Tue, 6 Oct 2015 16:49:28 +0200 Subject: [PATCH] clocksource: Sigma Designs Tango 27 MHz xtal Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez <marc_gonza...@sigmadesigns.com> --- d

<    1   2   3   4   5   6