On 1 March 2012 21:40, Sangwook Lee <sangwook.lee@xxxxxxxxxx> wrote:
[...]
> I found out some code related to this burst function.
>
> the snip from ehci-s5pv210.c, 2.6.35 kernel
>
> /* Mark hardware accessible again as we are out of D3 state by now
> */
> set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> #if defined(CONFIG_ARCH_S5PV210) || defined(CONFIG_ARCH_S5P6450)
> ehci_writel(ehci, 0x000F0000, (void __iomem *)ehci->caps + 0x90);
> #endif
>
> #if defined(CONFIG_ARCH_S5PV310)
> ehci_writel(ehci, 0x03C00000, (void __iomem *)ehci->caps + 0x90);
> #endif
> if (ehci_readl(ehci, &ehci->regs->configured_flag) == FLAG_CF) {
>
> From this code, this burst function seems to be depending on CPUs,
> The driver by itself is not good idea because echi-s5p.c will have defined.
>
> Which is the better place to pus this CPU specific definition either
> drivers/usb/host/ehci-s5p.h is
> or mach/xx.h or include/linux/usb/xxx.h ? I am not clear about this.
Any configuration that is controller specific should be in the driver.
If that configuration has a SoC specific behavior, a id_table can be
provided to the platform_driver which can provide any SoC specific
information. The samsung keypad driver is an example of how this can
be handled (drivers/input/keyboard/samsung.c).
Thanks,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
