> -----Original Message----- > From: Peter Chen [mailto:hzpeterchen@xxxxxxxxx] > Sent: Thursday, February 16, 2012 5:37 PM > To: Mehresh Ramneek-B31383 > Cc: Chen Peter-B29397; linux-usb@xxxxxxxxxxxxxxx; Li Yang-R58472; Aggrwal > Poonam-B10812 > Subject: Re: [PATCH][v4]fsl/usb:Add controller version based ULPI and > UTMI phy support > > On Thu, Feb 16, 2012 at 6:14 PM, Mehresh Ramneek-B31383 > <B31383@xxxxxxxxxxxxx> wrote: > > > > > >> -----Original Message----- > >> From: Chen Peter-B29397 > >> Sent: Thursday, February 16, 2012 3:18 PM > >> To: Mehresh Ramneek-B31383 > >> Cc: linux-usb@xxxxxxxxxxxxxxx; Li Yang-R58472 > >> Subject: RE: [PATCH][v4]fsl/usb:Add controller version based ULPI and > >> UTMI phy support > >> > >> > >> > I see 2 issues here: > >> > > >> > 1. Device-tree not being used for IMX platforms > >> > 2. sysif_regs not defined for IMX platforms > >> > > >> > For the first issue, I can replace CONFIG_ARCH_MXC macro with > >> > usb_get_ver_info() > >> > returning some standard error value for nonDT platforms > >> > > >> > For the second issue, we can replace CONFIG_ARCH_MXC macro with > >> > if (pdata->have_sysif_regs) for IMX platforms > >> > > >> > Is it possible to define pdata->have_sysif_regs = 0 for IMX > >> > platforms ?? > >> > > >> > > Just how much effort it'll be for IMX team to define this for their > platforms ? > > > It is not i.mx platform registers, so i.mx does not initialize it, its > value is 0 at i.mx. > i.mx need to do nothing for pdaat->have_sysif_regs. > > > We should try and resolve this issue together. I'm providing my > > support in every possible way, even offering to alter functions to > return values for imx platforms. > > > > You cannot keep asking people to send patches for the platforms that > > imx team is supposed to maintain...we need to work together to resolve > issues... > > > Ramneek, your patch causes i.mx compile error, the reason is you add > struct(register) which > is not defined at i.mx platform. WHY do you think it is i.mx team's duty? > Peter, I said this in context of usage of CONFIG_ARCH_MXC macro in usb gadget driver. It doesn't matter who's adding what code in the driver, the basic notion is to make sure not to use soc specific macros/ code inside driver code someone from imx team can help me in getting rid of CONFIG_ARCH_MXC macro. The main reason for me sending this patch is also this. Initially, I was also using ...BOOKE macro for this code, but later realized this issue, and wrote usb_get_ver_info() function to identify controller version as long as code compilation issue on IMX is concerned, I'm still trying to find the best possible way to resolve it...but I would really appreciate some help from your side as I'm not very much aware of imx code structure... regards, Ramneek > > I'm trying to clean up fsl usb gadget code here, and this patch is the > first step towards it. > > > > We can keep working to get rid of other soc macros also in subsequent > patches... > > > At Chipidea(former ARC)'s datasheet, the registers from 0x0-0x200( 0x200- > 0x400 for another controller, etc) are common registers. The other > registers (like from 0x800) is platform specific, it is differ with > platforms. > We can work together to move platform specific to fsl_ppc_udc.c and > fsl_arm_udc.c like Leo has suggested. > > Recently, we are working at PHY's driver(Please see heikki's separate PHY > from OTG structure patch, currently it is v11). Later, we hope there is a > generic PHY driver, then we can add our individual PHY code as platform > driver. like: usb/phy/generic.c, usb/phy/fsl_arm.c, usb/phy/fsl_ppc.c, > etc. You can handle your PHY's staff , like init, low power, wakeup, > charger at your platform driver. > This is a good idea...but again, would it be appropriate to use soc based macros inside this driver ?? Regards, Ramneek > -- > BR, > Peter Chen -- 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
