From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kishon Vijay Abraham I Subject: Re: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver Date: Tue, 26 Mar 2013 11:33:44 +0530 Message-ID: <51513A40.7080905@ti.com> References: <1362662506-14823-4-git-send-email-kishon@ti.com> <1364203926-24488-1-git-send-email-kishon@ti.com> <51501CFB.4020905@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51501CFB.4020905@nvidia.com> Sender: linux-doc-owner@vger.kernel.org To: Laxman Dewangan , "balbi@ti.com" , "gg@slimlogic.co.uk" , Rajendra Nayak Cc: "grant.likely@secretlab.ca" , "rob.herring@calxeda.com" , "rob@landley.net" , "gregkh@linuxfoundation.org" , "s-guiriec@ti.com" , "sameo@linux.intel.com" , "broonie@opensource.wolfsonmicro.com" , "devicetree-discuss@lists.ozlabs.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" List-Id: devicetree@vger.kernel.org Hi, On Monday 25 March 2013 03:16 PM, Laxman Dewangan wrote: > On Monday 25 March 2013 03:02 PM, Kishon Vijay Abraham I wrote: >> From: Graeme Gregory >> >> This is the driver for the OTG transceiver built into the Palmas chip. It >> handles the various USB OTG events that can be generated by cable >> insertion/removal. >> >> Signed-off-by: Graeme Gregory >> Signed-off-by: Moiz Sonasath >> Signed-off-by: Ruchika Kharwar >> Signed-off-by: Kishon Vijay Abraham I >> Signed-off-by: Sebastien Guiriec >> --- > > I think this driver is more over the cable connection like vbus > detetcion or ID pin detection. > Then why not it is implemented based on extcon framework? extcon framework uses notification mechanism and Felipe dint like using notification here. right Felipe? > > That way, generic usb driver (like tegra_usb driver) will get > notification through extcon. > > We need this cable detection through extcon on our tegra solution > through the Palmas. > > > +#include > +#include > + > +static int palmas_usb_read(struct palmas *palmas, unsigned int reg, > + unsigned int *dest) > +{ > + unsigned int addr; > + int slave; > + > + slave = PALMAS_BASE_TO_SLAVE(PALMAS_USB_OTG_BASE); > + addr = PALMAS_BASE_TO_REG(PALMAS_USB_OTG_BASE, reg); > + > + return regmap_read(palmas->regmap[slave], addr, dest); > > > Please use the generic api for palmas_read()/palmas_write(0 as it will > be ease on debugging on register access. > Direct regmap_read() does not help much on this. Graeme, Any reason why you dint use palmas_read()/palmas_write here? Btw palmas_read()/palmas_write() internally uses regmap APIs. > >> +} >> + >> +static int palmas_usb_write(struct palmas *palmas, unsigned int reg, >> + unsigned int data) >> +{ >> + unsigned int addr; >> + int slave; >> + >> + slave = PALMAS_BASE_TO_SLAVE(PALMAS_USB_OTG_BASE); >> + addr = PALMAS_BASE_TO_REG(PALMAS_USB_OTG_BASE, reg); >> + >> + return regmap_write(palmas->regmap[slave], addr, data); > > Same as above. > > > >> + >> + if (status != OMAP_DWC3_UNKNOWN) { >> + palmas_usb->linkstat = status; >> + palmas_usb->mailboxstat = dwc3_omap_mailbox(status); > Omap specific call, why? This is generic palma driver. hmm.. I think we should either fall-back to the notification mechanism or have the client drivers pass function pointer here. Felipe? > > >> + > >> + palmas_usb->dev = &pdev->dev; >> + >> + palmas_usb->irq1 = regmap_irq_get_virq(palmas->irq_data, >> + PALMAS_ID_OTG_IRQ); >> + palmas_usb->irq2 = regmap_irq_get_virq(palmas->irq_data, >> + PALMAS_ID_IRQ); >> + palmas_usb->irq3 = regmap_irq_get_virq(palmas->irq_data, >> + PALMAS_VBUS_OTG_IRQ); >> + palmas_usb->irq4 = regmap_irq_get_virq(palmas->irq_data, >> + PALMAS_VBUS_IRQ); > > Should be come from platform_get_irq() through platform driver. No. It can be obtained from regmap too. Thanks Kishon