From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Wed, 6 Mar 2013 09:16:13 -0800 Subject: [PATCH 6/9] [media] ir-rx51: fix clock API related build issues In-Reply-To: <20130306062218.GA1638@itanic.dhcp.inet.fi> References: <1362521809-22989-1-git-send-email-arnd@arndb.de> <1362521809-22989-7-git-send-email-arnd@arndb.de> <20130305212351.4993d8c6@redhat.com> <20130306010952.GJ11806@atomide.com> <20130306062218.GA1638@itanic.dhcp.inet.fi> Message-ID: <20130306171612.GL11806@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Timo Kokkonen [130305 22:26]: > On 03.05 2013 17:09:53, Tony Lindgren wrote: > > * Mauro Carvalho Chehab [130305 16:28]: > > > Em Tue, 5 Mar 2013 23:16:46 +0100 > > > Arnd Bergmann 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 > > > > Cc: Mauro Carvalho Chehab > > > > > > From my side: > > > Acked-by: Mauro Carvalho Chehab > > > > 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 :) Sounds good to me. > 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.. Git bisect might help there. Maybe post the output and cc the usb people? Regards, Tony