From: Graeme Gregory <gg@slimlogic.co.uk>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
"balbi@ti.com" <balbi@ti.com>, Rajendra Nayak <rnayak@ti.com>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"rob@landley.net" <rob@landley.net>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"s-guiriec@ti.com" <s-guiriec@ti.com>,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver
Date: Tue, 26 Mar 2013 09:51:49 +0000 [thread overview]
Message-ID: <51516FB5.3050504@slimlogic.co.uk> (raw)
In-Reply-To: <51516BC3.7030707@nvidia.com>
On 26/03/13 09:34, Laxman Dewangan wrote:
> On Tuesday 26 March 2013 02:57 PM, Graeme Gregory wrote:
>> On 26/03/13 09:12, Laxman Dewangan wrote:
>>> On Tuesday 26 March 2013 02:31 PM, Graeme Gregory wrote:
>>>
>>> But still you are using the PALMAS macro here and indirectly it is
>>> tied up. It is not completely independent.
>>> If need to be independent then regmap pointer with address need to be
>>> passed as independt header and no where on code whould refer the PALMA.
>>> I think as per current code, it is not possible although it is your
>>> big plan what I understand from some time back in one of patch
>>> discussion.
>>>
>> It is actually almost possible, but it is something I gave up looking
>> at. You can get the regmap of your parent i2c device without having
>> knowledge of the type of parent.
>
> There is multiple regmap of parent and hence getting correct regmap is
> really issue. May be RTC require regmap[0] and gpio require regmap[1].
>
If you notice each regmap is connected to the correct dummy. Its
possible to create the correct children per dummy. The twl6030 driver
does this. But this is pointless now as I never intend to work on it so
we shall go with the tightly coupled.
>
>>
>>>>>>> + 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.
>>> Kishon,
>>> I think it is very much possible. You can pass the interrupt throough
>>> IRQ_RESOURCE and populate it from DT. If you provide proper interrupt
>>> parent and irq number then irq framework take care of every thing.
>>> already tested this with RTC interrupt of plama and it worked very
>>> well.
>>>
>> If we are tightly coupling as above then using platform_irq is an extra
>> inefficiency. You both have to populate this then parse it afterwards.
>> Why not just use the regmap helper? Ill admit this code is like this as
>> there was a period where platform irqs in DT just was not working right!
>>
>> We should really agree now if we are going for loose or tight coupling
>> now rather than keep switching?
>
> Here we are hardcoding for PALMAS_ID_OTG_IRQ and so on. If we take
> data from platform then it need not and it will be completely
> independent of palma atleast on this front.
> We need to populate just as:
> palmas: palmas {
> :::::::
> palams_usb_phy {
> compatile = ...
> interrupt-parent = <& palmas>;
> interrupt = < 10, 0,
> 21, 0,
> 22, 0,
> 23, 0>;
> }
>
>
> and in code, we just need to do
> irq1 = platform_get_irq(pdev, 0);
> irq2 = platform_get_irq(pdev, 1);
> etc..
>
>
> So here, actually we do not need to use palmas one and it is
> completely independent.
>
> Also the way you define the DT od palmas, the above one looks more
> appropriate.
>
Ok that makes sense if you are actually planning to feed non palmas IRQs
to the usb via either palmas GPIO or even directly! I did not know there
was such a use case!
Graeme
next prev parent reply other threads:[~2013-03-26 9:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 13:21 [PATCH v2 0/4] usb: added palmas-usb driver and a few misc fixes Kishon Vijay Abraham I
2013-03-07 13:21 ` [PATCH v2 1/4] usb: dwc3: set dma_mask for dwc3_omap device Kishon Vijay Abraham I
2013-03-07 13:21 ` [PATCH v2 2/4] usb: dwc3: dwc3-omap: return -EPROBE_DEFER if probe has not yet executed Kishon Vijay Abraham I
2013-03-07 13:21 ` [PATCH v2 3/4] USB: Palmas OTG Transceiver Driver Kishon Vijay Abraham I
2013-03-14 13:56 ` Felipe Balbi
2013-03-14 14:53 ` kishon
2013-03-25 9:32 ` [PATCH v3] USB: PHY: Palmas USB " Kishon Vijay Abraham I
2013-03-25 9:46 ` Laxman Dewangan
2013-03-26 6:03 ` Kishon Vijay Abraham I
2013-03-26 9:01 ` Graeme Gregory
2013-03-26 9:12 ` Laxman Dewangan
2013-03-26 9:27 ` Graeme Gregory
2013-03-26 9:34 ` Laxman Dewangan
2013-03-26 9:51 ` Graeme Gregory [this message]
2013-03-26 11:28 ` Laxman Dewangan
2013-03-26 16:22 ` Stephen Warren
2013-03-26 16:57 ` Graeme Gregory
2013-03-26 20:23 ` Stephen Warren
2013-03-27 11:03 ` Graeme Gregory
2013-03-26 10:21 ` Felipe Balbi
2013-03-26 10:28 ` Laxman Dewangan
2013-03-26 12:07 ` Felipe Balbi
2013-03-26 16:14 ` Stephen Warren
2013-03-26 10:19 ` Felipe Balbi
2013-05-06 13:17 ` [PATCH v4] extcon: Palmas Extcon Driver Kishon Vijay Abraham I
2013-05-06 14:26 ` Laxman Dewangan
2013-05-07 5:06 ` Kishon Vijay Abraham I
2013-05-06 14:40 ` Mark Brown
2013-05-07 5:12 ` Kishon Vijay Abraham I
2013-05-07 7:58 ` Mark Brown
2013-05-07 9:47 ` Kishon Vijay Abraham I
2013-05-07 9:49 ` Graeme Gregory
2013-05-07 10:45 ` Mark Brown
2013-05-14 9:18 ` Kishon Vijay Abraham I
2013-05-14 9:54 ` Graeme Gregory
2013-05-14 18:43 ` Laxman Dewangan
2013-05-07 0:43 ` myungjoo.ham
2013-05-07 5:21 ` Kishon Vijay Abraham I
2013-05-22 6:23 ` Kishon Vijay Abraham I
2013-05-07 6:10 ` Chanwoo Choi
2013-05-07 6:25 ` Kishon Vijay Abraham I
2013-05-07 6:57 ` Chanwoo Choi
2013-05-07 7:05 ` Chanwoo Choi
2013-05-07 8:17 ` Kishon Vijay Abraham I
2013-03-07 13:21 ` [PATCH v2 4/4] usb: musb: omap2430: replace *_* with *-* in property names Kishon Vijay Abraham I
2013-03-14 13:57 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51516FB5.3050504@slimlogic.co.uk \
--to=gg@slimlogic.co.uk \
--cc=balbi@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@ti.com \
--cc=ldewangan@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rnayak@ti.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=s-guiriec@ti.com \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).