[PATCH 6/9] [media] ir-rx51: fix clock API related build issues

Timo Kokkonen timo.t.kokkonen at iki.fi
Wed Mar 6 01:22:18 EST 2013


On 03.05 2013 17:09:53, Tony Lindgren wrote:
> * Mauro Carvalho Chehab <mchehab at redhat.com> [130305 16:28]:
> > Em Tue,  5 Mar 2013 23:16:46 +0100
> > Arnd Bergmann <arnd at arndb.de> escreveu:
> > 
> > > OMAP1 no longer provides its own clock interfaces since patch
> > > a135eaae52 "ARM: OMAP: remove plat/clock.h". This is great, but
> > > we now have to convert the ir-rx51 driver to use the generic
> > > interface from linux/clk.h.
> > > 
> > > The driver also uses the omap_dm_timer_get_fclk() function,
> > > which is not exported for OMAP1, so we have to move the
> > > definition out of the OMAP2 specific section.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > > Cc: Mauro Carvalho Chehab <mchehab at redhat.com>
> > 
> > From my side:
> > Acked-by: Mauro Carvalho Chehab <mchehab at redhat.com>
> 
> There's just one issue, this driver most likely only needed on
> rx51 board.. So I suggest we just mark the driver depends on
> ARCH_OMAP2PLUS and let's drop this patch.
> 
> This driver is already disabled for ARCH_MULTIPLATFORM
> as we need to move dmtimer.c to drivers and have some minimal
> include/linux/timer-omap.h for it.
>  

I've also had this cunning plan that if or when the PWM subsystem
starts supporting the PWM output in OMAP3, I could convert this driver
to generate the IR carrier wave through the PWM subsystem and then use
HR timers to generate the pulses. I think that's much better approach
than trying to depend on interfaces that are not easily
available. Should be possible, but I haven't proven yet that it will
work :)

Unfortunately I haven't got into executing on that plan yet. In
addition to the challenge of scheduling some of my free time for doing
this, my RX51 device is not enumerating the USB with the latest kernel
and I haven't figured out that yet. And because of that, I haven't
been able to get my user space running over nfsroot setup I've been
using..

-Timo

> > > --- a/arch/arm/plat-omap/dmtimer.c
> > > +++ b/arch/arm/plat-omap/dmtimer.c
> > > @@ -333,6 +333,14 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer)
> > >  }
> > >  EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq);
> > >  
> > > +struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > > +{
> > > +	if (timer)
> > > +		return timer->fclk;
> > > +	return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > > +
> > >  #if defined(CONFIG_ARCH_OMAP1)
> > >  #include <mach/hardware.h>
> > >  /**
> > > @@ -371,14 +379,6 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
> > >  
> > >  #else
> > >  
> > > -struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > > -{
> > > -	if (timer)
> > > -		return timer->fclk;
> > > -	return NULL;
> > > -}
> > > -EXPORT_SYMBOL_GPL(omap_dm_timer_get_fclk);
> > > -
> > >  __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
> > >  {
> > >  	BUG();
> 
> Then omap_dm_timer_get_fclk() won't work on omap1 as there's no
> separate functional clock. We probably should not even export
> this function eventually when things are fixed up.
> 
> Regards,
> 
> Tony



More information about the linux-arm-kernel mailing list