On Wed, Jun 29, 2011 at 22:26, Jiang, Scott wrote: >> these magic numbers really need to be defines. i'll probably merge >> the toolchain/trunk/proc-defs/header-frags/regbits/ppi.h header file >> into asm/bfin_ppi.h, then you can replace all of this logic with that. > > Yes, some macros are defined in mach/defBF5xx.h, but not complete > We'd better put all these macros together.
OK, i'll try and get this done this week. in general, i'm trying to widdle down the code in the def* and cdef* files to a more standard asm/<peripheral>.h header. this keeps global namespace pollution down. >> + intf->ppi_control |= 0x000c; >> + /* set port cfg */ >> + else if (params->flags & PPI_FLAG_ONE_SYNC) >> + intf->ppi_control |= 0x0000; >> + else if (params->flags & PPI_FLAG_FS2_ASSERT) >> + intf->ppi_control |= 0x0030; >> + else >> + intf->ppi_control |= 0x0010; >> >> do we really need to have this abstraction ? why dont we just let >> users program the ppi_control directly via the board config. > > Because eppi has different register bit. If we use bit flag, ppi or eppi > driver can convert this. > That means one sensor configuration can be used both on ppi and eppi. > Perhaps it is no use, I can remove it. imo, that makes sense if there was a layer on top that was abstracted across ppi/eppi. but we're talking about resources that comes from a boards file that is specific to one cpu, and that code isnt being stretched across multiple cpus with ppis and eppis. i can understand having this logic in the char/bfin_ppi.c driver where the client is a userspace app that is written once and can be used on all of the Blackfin cpus unchanged. but that isnt what we're talking about in this case i dont think. -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
