Hi, On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I wrote: > On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote: > >Hi Kishon, > > > >>-----Original Message----- > >>From: ABRAHAM, KISHON VIJAY > >>Sent: Wednesday, June 26, 2013 5:17 PM > >>To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM, > >>KISHON VIJAY; a...@arndb.de; swar...@nvidia.com; > >>sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux- > >>o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > >>u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux- > >>foundation.org > >>Cc: rob.herr...@calxeda.com; r...@landley.net; li...@arm.linux.org.uk; > >>benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net; > >>da...@davemloft.net; Nayak, Rajendra; shawn....@linaro.org; Shilimkar, > >>Santosh; devicetree-discuss@lists.ozlabs.org; linux- > >>d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian, > >>George > >>Subject: [PATCH v9 0/8] Generic PHY Framework > >> > >>Added a generic PHY framework that provides a set of APIs for the PHY > >>drivers > >>to create/destroy a PHY and APIs for the PHY users to obtain a > >>reference to > >>the PHY with or without using phandle. > >> > >>This framework will be of use only to devices that uses external PHY > >>(PHY > >>functionality is not embedded within the controller). > >> > >>The intention of creating this framework is to bring the phy drivers > >>spread > >>all over the Linux kernel to drivers/phy to increase code re-use and > >>to > >>increase code maintainability. > > > >I would like to use this framework for a smart-card controller connected to a > >smart-card phy. I have some questions and would like to get feedback on the > >same. > > glad to know that :-) > > > >I am using “TDA8026" Smartcard PHY from NXP. Here is the link for datasheet > >and app note for the same. The smart card controller is inside the TI SoC > >I am working with. > > > >Datasheet : > >www.nxp.com/documents/data_sheet/TDA8026.pdf? > > > >Appnote : > >http://www.nxp.com/documents/application_note/AN10724.pdf > > > >The TI SoC details are not public (yet). I can provide details to you > >offline. > > > >Brief about operation: > >- The controller can work with and without a PHY > >- When not using PHY, it is limited to talking to a single > > smart card. There is also a need to put external de-activation logic > > on card removal for this case. > >- With a PHY you can use more than one smart card. > >- Phy has 5 slots : 1 for smart card (credit/debit/other card with chip) > > and others for SAM – SIM like modules > >- Once the PHY is initialized, there are some operations that the > >controller > > can request of the PHY like: > > - Card configurations - set voltage > > - Activation of card > > - ATR – Answer to reset > > - Warm reset > > - ADPU exchange > > - Deactivation ( Normal/Emergency) > > hmm.. We should think about extending the phy_ops to include these > operations (something like phy_smart_card_ops so that other > smart_card PHYs will also be able to use it).
let's try to avoid use-case specific additions. set_voltage sounds like a regulator thing, but the regulator is controlled through the PHY. I guess it makes sense to have a generic phy_set_voltage() call since even USB can make use of that. For card activation, it sounds like phy_init()/phy_shutdown() would cover it. For warm reset perhaps a phy_reset() callback ? Although that could, easily, get abused. For deactivation, that's phy_shutdown(). ATR and ADPU needs more thought, I guess. > >- In the mode when smartcard controller talks directly to the card > >without the need > > for a PHY, all the above operations will be carried out by the > > controller itself > > > >My current thought process is to make the controller driver provide the user > >interface > >and talk to the PHY using the generic PHY framework you proposed. In the > >case where there > >is no PHY, my idea is to create a "dummy" PHY which uses the controller > >functionality itself. > > right. And in the case where you actually have a PHY, create a PHY > driver and implement the phy_smart_card_ops and register with the PHY > framework. I would try to avoid that. Otherwise we will have phy_usb_ops, phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would easily blow up. -- balbi
signature.asc
Description: Digital signature
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
