Re: Nokia N900: musb is in wrong state after boot
On 06/10/2016 11:15 AM, joerg Reisenweber wrote: Sorry for butting in... > On Fri 10 June 2016 10:59:40 Bin Liu wrote: >> The musb ug says the testmde is not used in normal operation, so my >> opinion is force_host should not be used for hacking n900 host mode if >> this is for real product development or support. > > You're aware N900 OS aka maemo is a) FOSS, and b) EOL at least from Nokia's > POV? So there's neither "product development" nor any _'official'_ support > involved. > And c) we (community) already _did_ use it since it was the only chance to > make hostmode sort of work for N900, it's not like we could redesign N900 > hardware to support regular hostmode, we need to work with what RL gave us. > It evades me why you discourage resp reject this established solution. > Just Nokia not supporting hostmode evidently doesn't mean we can't get > anything done, and I don't see why we should refrain from doing so. I think there was some unfortunately choice of words used in the thread. It is TI intention to support community effort and we are very appreciative of the work and effort done by the N900 community. Please do not misunderstand that we dont care for FOSS community, in fact, we are part of the FOSS community as well and a significant investment is done to ensure that "upstream first" approach is taken to benefit everyone. Hopefully with that out of the way, on this specific topic, based on a quick chat with Bin, I think Bin meant to indicate that as per Mentor vendor documentation, the option is a test mode meant for silicon validation purposes - typically many vendor hardware blocks have these "test mode" bits and options meant to help silicon validation software, unfortunately these modes do not tend to be well tested and the typical "official disclaimer" is "Not for 'production device usage' and 'user might be on his/her own' " - That does not mean it cannot work, but it may not always be working OR can have reliability issues/open up unknown silicon issues that has not been well covered by SoC and/or IP vendor. In this case specifically, I think Bin's experience of having had tried to get this working in AM335x and had failed makes him a little more skeptical. I think Bin has accepted this patch, but anyways, it is always good to highlight potential risk. I assume Bin can elaborate more as needed. Post Note: We all do appreciate all the creative ways folks do use TI SoCs, it is important we try and continue do that to leverage every single transistor that the SoC has, but we should also just keep a watch for any potential risks we might have to face with these options we exploit. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
On 07/02/2014 07:03 AM, Roger Quadros wrote: > After clarification from the hardware team it was found that > this 1.8V PHY supply can't be switched OFF when SoC is Active. > It can only be switched off when in PORz (power on reset). I dont think folks know the reasoning why hardware team decided that the voltage rail cannot be switched off -> I suggest adding the following information as well. Since isolation is not present in the design for these PHY IPs to allow for the PHY rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. Only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. > > This patch is required for proper functionality of USB, SATA > and PCIe on DRA7-evm. > > CC: Rajendra Nayak > CC: Tero Kristo > Signed-off-by: Roger Quadros > --- > arch/arm/boot/dts/dra7-evm.dts | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index 4adc280..8308954 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -240,6 +240,7 @@ > regulator-name = "ldo3"; > regulator-min-microvolt = <180>; > regulator-max-microvolt = <180>; > + regulator-always-on; > regulator-boot-on; > }; > > -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names "wkupclk" and "refclk"
On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi wrote: > On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: >> On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: >> > +Nishant >> > >> > Hi, >> > >> > On 04/28/2014 07:03 PM, Felipe Balbi wrote: >> > > Hi, >> > > >> > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: >> > >> As clocks might be named differently on multiple platforms, use a >> > >> generic >> > >> name in the driver and allow device tree node to specify the platform >> > >> specific clock name. >> > >> >> > >> Signed-off-by: Roger Quadros >> > >> --- >> > >> drivers/phy/phy-omap-usb2.c | 8 >> > >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > >> >> > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c >> > >> index a2205a8..fb5e515 100644 >> > >> --- a/drivers/phy/phy-omap-usb2.c >> > >> +++ b/drivers/phy/phy-omap-usb2.c >> > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device >> > >> *pdev) >> > >> if (IS_ERR(phy_provider)) >> > >> return PTR_ERR(phy_provider); >> > >> >> > >> -phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); >> > >> +phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); >> > > >> > > doesn't this patch cause a regression ? I mean, you're changing the >> > > clock name before fixing DTS. Also, that DTS has been in a major version >> > > of the kernel, so we need to maintain compatibility with it. How about: >> > >> > I'm changing the DTS in Patch 4, but I prefer to do it in this patch >> > to prevent synchronization issues in -next. >> > >> > About backward compatibility, I agree with you but at the same time I >> > don't think anyone using TI SoCs burns the DTB to ROM and needs >> > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. >> > Do you feel strict backward compatibility is worth the effort for TI >> > specific blocks? >> >> dunno, but it would, at least, avoid "synchronization issues with >> linux-next" :-) > > and the bisectability issue. I agree - we cannot drop backward compatibility for DTBs http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 " + + 3) Bindings can be augmented, but the driver shouldn't break when given + the old binding. ie. add additional properties, but don't change the + meaning of an existing property. For drivers, default to the original + behaviour when a newly added property is missing. " Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 07:07 PM, Kevin Hilman wrote:
> Nishanth Menon writes:
>
>> On 02/10/2014 12:28 PM, Kevin Hilman wrote:
>>> Roger Quadros writes:
>>>
>>>> +devicetree
>>>>
>>>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>>>> Hi,
>>>>>
>>>>> A quick note to report that I saw regression in today's next tag (logs
>>>>> indicate around EHCI) boot on various TI platforms:
>>>>>
>>>>> Note: crane and sdp2430 are not expected to pass with
>>>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>>>> but USB is disabled there)
>>>>>
>>>>> next-20140210-multi_v7_defconfig
>>>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>>>> around ehci
>>>>>
>>>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>>>> around ehci
>>>>>
>>>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>>>> around ehci
>>>>>
>>>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>>>> 8: crane: No Image built - Missing platform support?:
>>>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>>>> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>>>> around ehci
>>>>>
>>>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>>>> around ehci
>>>>
>>>> I think the problem is that ehci-platform driver gets loaded instead of
>>>> ehci-omap.
>>>>
>>>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>>>
>>>> usbhsehci: ehci@4a064c00 {
>>>> compatible = "ti,ehci-omap", "usb-ehci";
>>>> reg = <0x4a064c00 0x400>;
>>>> interrupt-parent = <&gic>;
>>>> interrupts = >>> IRQ_TYPE_LEVEL_HIGH>;
>>>> };
>>>>
>>>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>>>
>>>> A quick fix would be to eliminate "usb-ehci" from the DT node of all
>>>> failing platforms.
>>>
>>> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
>>> fixed the problem for me on 3530/overo, 3730/beagle-xM and
>>> 4460/panda-es. But I don't think that's the right fix. First we have
>>> to figure out why ehci-omap stopped getting loaded first.
>>
>> Wont that depend on driver probe order? of_match_device is fairly
>> simple compatible walk through without looking at other drivers which
>> might also be compatible, but not yet probed?
>>
>> The issue started I think with the following patch getting merged:
>> ehci-platform: Add support for clks and phy passed through devicetree
>> some version of http://www.spinics.net/lists/linux-usb/msg101061.html
>> introduced { .compatible = "usb-ehci", },
>
> This is what I was getting at: an understanding of what caused the
> failue in the first place.
>
>> Now, in the build we have two drivers which dts claims compatibility
>> with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
>> for the platform. Thinking that way, in fact, the current
>> compatibility even matches drivers/usb/host/ehci-ppc-of.c which
>> obviously wont work either.
>
> Right, so I agree that it makes sense to remove a compatible string
> where there is no compatability, but a couple other things should happen
> here.
>
> 1) changelog should describe why this compatible string is in the omap
> dtsi files in first place.
>
Agreed: I had commented the same on
https://patchwork.kernel.org/patch/3621811/
> 2) investigation into the patch that introduced this change to double
> check it's not introducing other breakage as well.
discussion is now on the relevant patch generating the break:
http://marc.info/?t=13917875203&r=1&w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 12:28 PM, Kevin Hilman wrote:
> Roger Quadros writes:
>
>> +devicetree
>>
>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>> Hi,
>>>
>>> A quick note to report that I saw regression in today's next tag (logs
>>> indicate around EHCI) boot on various TI platforms:
>>>
>>> Note: crane and sdp2430 are not expected to pass with
>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>> but USB is disabled there)
>>>
>>> next-20140210-multi_v7_defconfig
>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>> around ehci
>>>
>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>> around ehci
>>>
>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>> around ehci
>>>
>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>> 8: crane: No Image built - Missing platform support?:
>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>> around ehci
>>>
>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>> around ehci
>>
>> I think the problem is that ehci-platform driver gets loaded instead of
>> ehci-omap.
>>
>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>
>> usbhsehci: ehci@4a064c00 {
>> compatible = "ti,ehci-omap", "usb-ehci";
>> reg = <0x4a064c00 0x400>;
>> interrupt-parent = <&gic>;
>> interrupts = > IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>
>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
>> platforms.
>
> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
> fixed the problem for me on 3530/overo, 3730/beagle-xM and
> 4460/panda-es. But I don't think that's the right fix. First we have
> to figure out why ehci-omap stopped getting loaded first.
Wont that depend on driver probe order? of_match_device is fairly
simple compatible walk through without looking at other drivers which
might also be compatible, but not yet probed?
The issue started I think with the following patch getting merged:
ehci-platform: Add support for clks and phy passed through devicetree
some version of http://www.spinics.net/lists/linux-usb/msg101061.html
introduced { .compatible = "usb-ehci", },
Now, in the build we have two drivers which dts claims compatibility
with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
for the platform. Thinking that way, in fact, the current
compatibility even matches drivers/usb/host/ehci-ppc-of.c which
obviously wont work either.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 11:50 AM, Roger Quadros wrote:
> +devicetree
>
[...]
> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>
> usbhsehci: ehci@4a064c00 {
> compatible = "ti,ehci-omap", "usb-ehci";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = ;
> };
>
> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>
> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
> platforms.
If the driver is not compatible with "usb-ehci", not sure why do we
even state that in dts node?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 10:11 AM, Roger Quadros wrote: > On 02/10/2014 05:59 PM, Nishanth Menon wrote: >> Hi, >> >> A quick note to report that I saw regression in today's next tag (logs >> indicate around EHCI) boot on various TI platforms: >> >> Note: crane and sdp2430 are not expected to pass with >> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >> but USB is disabled there) > > I'll take a look what's happening. Thanks. > Funny thing is that am335x doesn't even have an EHCI controller. I dont think any of the am335x platforms fail - just OMAP3,4 platforms which do fail. Side note: all platforms are tested with device tree boot (not the legacy boot). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
regression(ti platforms): next-20140210 (ehci?)
Hi, A quick note to report that I saw regression in today's next tag (logs indicate around EHCI) boot on various TI platforms: Note: crane and sdp2430 are not expected to pass with multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane but USB is disabled there) next-20140210-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 around ehci 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 around ehci 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK around ehci 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 around ehci 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ around ehci 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot FAIL: http://slexy.org/raw/s21cwW7PqH around ehci 14:sdp4430: Boot PASS: http://slexy.org/raw/s2hL39Pyl9 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20UsDeuVB TOTAL = 15 boards, Booted Boards = 7, No Boot boards = 8 next-20140207-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2yo795okf 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2TfAOi6XP 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21sKT3pFN 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21nCiNjAR 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21uEu69lC 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21SklkJs7 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s21aYZvPl7 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s20soGBbYz 10:ldp: Boot PASS: http://slexy.org/raw/s20lDIIwgN 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2a5NWPUtE 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot PASS: http://slexy.org/raw/s2osagMVWZ 14:sdp4430: Boot PASS: http://slexy.org/raw/s2NxmpHFaW 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2PMcXzAUP TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 in comparison: v3.14-rc2-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2NWCJQczI 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2566ZAl5d 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2msKg3ZQ9 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2898HemYQ 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20ajDkVgM 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20YmD8SSG 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2sXDV7x0T 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s21Zz8NJrj 10:ldp: Boot PASS: http://slexy.org/raw/s21NANMvTx 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20NER4paD 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot PASS: http://slexy.org/raw/s2WCHUl033 14:sdp4430: Boot PASS: http://slexy.org/raw/s21ySru6J1 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2kztuFoSu TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
On Tue, Nov 26, 2013 at 3:04 PM, Tony Lindgren wrote: > * Roger Quadros [131120 02:33]: >> Nishant, >> >> On 11/19/2013 11:05 PM, Nishanth Menon wrote: >> > >> > >> > On 09/24/2013 03:53 AM, Roger Quadros wrote: >> >> Provide RESET GPIO and Power regulator for the USB PHY, >> >> the USB Host port mode and the PHY device for the controller. >> >> Also provide pin multiplexer information for USB host pins. >> >> >> >> We also relocate omap3_pmx_core pin definations so that they >> >> are close to omap3_pmx_wkup pin definations. >> >> >> >> Signed-off-by: Roger Quadros >> >> --- >> > >> > just using this thread, but a question -> >> > >> > I am kernel * master dec8e46 Merge >> > tag 'arc-v3.13-rc1-part2' of >> > git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc >> > >> > and I see that VAUX2 which supplies USB_1V8[1] is not enabled -> I did >> > a quick patch and it did seem to work (Usb keyboard, networking, mouse >> > etc on my ehci ports seems to come up good) - any suggestions how we'd >> > like to handle this? >> >> It worked for me without your patch. It could be that u-boot is enabling >> that regulator for me. I'm on u-boot-v2013.10. >> >> In any case, your patch seems the right thing to do. We should take it in >> the rc cycle. > > Can you guys post a proper fix for this? Meanwhile, I'll mark this > thread as read to shrink my inbox a bit. already done: https://patchwork.kernel.org/patch/3231151/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
On Mon, Nov 25, 2013 at 7:55 AM, Roger Quadros wrote:
> Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply
> for the USB PHY.
>
> As the generic PHY driver can't handle more than one supply
> at the moment, we configure this supply to be always on.
> This will cause a very small power impact if the USB host subsystem
> is not in use, about 76.86 micro-W + LDO power.
>
> Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere,
> so there won't be any functional impact on those boards other than
> some additional LDO power consumption.
>
> Reported-by: Nishanth Menon
> Signed-off-by: Roger Quadros
Tested-by: Nishanth Menon
I might suggest though that the better alternative might be to get phy
driver to handle multiple regulators considering that DT is supposed
to represent the h/w topology.
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts | 8
> arch/arm/boot/dts/omap3-beagle.dts| 8
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 31a632f..b39918e 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -215,3 +215,11 @@
> &usbhsehci {
> phys = <0 &hsusb2_phy>;
> };
> +
> +&vaux2 {
> + regulator-name = "usb_1v8";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> +};
> +
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index fa532aa..9764556 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -178,3 +178,11 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&vaux2 {
> + regulator-name = "vdd_ehci";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> +};
> +
> --
> 1.8.3.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
On 09/24/2013 03:53 AM, Roger Quadros wrote:
> Provide RESET GPIO and Power regulator for the USB PHY,
> the USB Host port mode and the PHY device for the controller.
> Also provide pin multiplexer information for USB host pins.
>
> We also relocate omap3_pmx_core pin definations so that they
> are close to omap3_pmx_wkup pin definations.
>
> Signed-off-by: Roger Quadros
> ---
just using this thread, but a question ->
I am kernel * master dec8e46 Merge
tag 'arc-v3.13-rc1-part2' of
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
and I see that VAUX2 which supplies USB_1V8[1] is not enabled -> I did
a quick patch and it did seem to work (Usb keyboard, networking, mouse
etc on my ehci ports seems to come up good) - any suggestions how we'd
like to handle this?
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -169,6 +169,14 @@
bus-width = <8>;
};
+&vaux2 {
+ regulator-name = "HubPower";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+};
+
+
[1]
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf?raw=true
> arch/arm/boot/dts/omap3-beagle-xm.dts | 65
> -
> 1 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index afdb164..b081f5a 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -69,6 +69,23 @@
> };
>
> };
> +
> + /* HS USB Port 2 Power */
> + hsusb2_power: hsusb2_power_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb2_vbus";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
> + startup-delay-us = <7>;
> + };
> +
> + /* HS USB Host PHY on PORT 2 */
> + hsusb2_phy: hsusb2_phy {
> + compatible = "usb-nop-xceiv";
> + reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
> + vcc-supply = <&hsusb2_power>;
> + };
> };
>
> &omap3_pmx_wkup {
> @@ -79,6 +96,37 @@
> };
> };
>
> +&omap3_pmx_core {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &hsusbb2_pins
> + >;
> +
> + uart3_pins: pinmux_uart3_pins {
> + pinctrl-single,pins = <
> + 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
> uart3_rx_irrx.uart3_rx_irrx */
> + 0x170 (PIN_OUTPUT | MUX_MODE0) /*
> uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
> + >;
> + };
> +
> + hsusbb2_pins: pinmux_hsusbb2_pins {
> + pinctrl-single,pins = <
> + 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
> etk_d10.hsusb2_clk */
> + 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
> etk_d11.hsusb2_stp */
> + 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> etk_d12.hsusb2_dir */
> + 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> etk_d13.hsusb2_nxt */
> + 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> etk_d14.hsusb2_data0 */
> + 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> etk_d15.hsusb2_data1 */
> + 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi1_cs3.hsusb2_data2 */
> + 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi2_clk.hsusb2_data7 */
> + 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi2_simo.hsusb2_data4 */
> + 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi2_somi.hsusb2_data5 */
> + 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi2_cs0.hsusb2_data6 */
> + 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
> mcspi2_cs1.hsusb2_data3 */
> + >;
> + };
> +};
> +
> &i2c1 {
> clock-frequency = <260>;
>
> @@ -148,15 +196,6 @@
> power = <50>;
> };
>
> -&omap3_pmx_core {
> - uart3_pins: pinmux_uart3_pins {
> - pinctrl-single,pins = <
> - 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
> uart3_rx_irrx.uart3_rx_irrx */
> - 0x170 (PIN_OUTPUT | MUX_MODE0) /*
&
Re: [PATCH 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
On 07:53-20130706, Ruchika Kharwar wrote:
> When the initialization of usb3 phy fails, when enabled in the system
> the dwc3_probe deferral is further qualified by the maximum speed.
> In devices such as dra7xx, there are multiple dwc3 instances where the
> maximum_speed is different between the instances.
indentation.
>
> This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Dependencies must be stated in diffstat - it is better to post a
complete series unless this maybe a standalone - which it seems to be..
just my 2 cents.
>
> Signed-off-by: Ruchika Kharwar
> ---
> drivers/usb/dwc3/core.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 7b98e4f..05f2205 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
> if (ret == -ENXIO)
> return ret;
>
> - dev_err(dev, "no usb3 phy configured\n");
> - return -EPROBE_DEFER;
> + if (dwc->maximum_speed == USB_SPEED_SUPER) {
> + dev_err(dev, "no usb3 phy configured\n");
> + return -EPROBE_DEFER;
is deferal always the right solution? just curious if one does not
declare the phy node, would'nt there be an opportunity to giveup
earlier?
> + } else
> + dev_dbg(dev, "maximum speed is < super\n");
Checkpatch would have asked you to add {} on both branches of the if
condition ;)
> }
>
> usb_phy_set_suspend(dwc->usb2_phy, 0);
> --
> 1.7.9.5
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
On 16:49-20130702, Michael Trimarchi wrote: > Last question: > If one domain is in RET mode and not OFF mode what happen during SAR restore > in OFF mode? Without going to the depth of what TRM says already: SAR comes into play only if device-off sequence was triggered. Depending on which domain and what level of retention state was programmed, device-off sequence may not even start. Note: Generically speaking, not achieving device OFF may not mean other powerdomains cannot achieve OFF and loose context. Specific example of USB tied on core domain, the behavior could be different. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP-USB: Fix possible memory leak
On 20:03-20130502, Alexander Shiyan wrote:
>
> Signed-off-by: Alexander Shiyan
> ---
> arch/arm/mach-omap2/usb-host.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index aa27d7f..8d17a0d 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char *dev_id,
> char *dev_supply,
> supplies->dev_name = dev_id;
>
> reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
> - if (!reg_data)
> + if (!reg_data) {
> + kfree(supplies);
> return -ENOMEM;
> + }
>
> reg_data->constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
> reg_data->consumer_supplies = supplies;
> @@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char *dev_id,
> char *dev_supply,
>
> config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config),
> GFP_KERNEL);
> - if (!config)
> + if (!config) {
> + kfree(supplies);
> + kfree(reg_data);
> return -ENOMEM;
> + }
>
> config->supply_name = name;
> config->gpio = gpio;
> @@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char
> *dev_id, char *dev_supply,
>
> /* create a regulator device */
> pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> - if (!pdev)
> + if (!pdev) {
> + kfree(supplies);
> + kfree(reg_data);
> + kfree(config);
> return -ENOMEM;
> + }
>
> pdev->id = PLATFORM_DEVID_AUTO;
> pdev->name = reg_name;
> pdev->dev.platform_data = config;
>
> ret = platform_device_register(pdev);
> - if (ret)
> + if (ret) {
> pr_err("%s: Failed registering regulator %s for %s\n",
> __func__, name, dev_id);
> + kfree(supplies);
> + kfree(reg_data);
> + kfree(config);
> + }
Might be better to switch to devm_XXX managed functions?
>
> return ret;
> }
> --
> 1.8.1.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 2:48 AM, Roger Quadros wrote: > On 04/10/2013 08:39 PM, Nishanth Menon wrote: >> On 13:55-20130410, Roger Quadros wrote: >>> On 04/10/2013 11:06 AM, Mike Turquette wrote: >>>> Quoting Nishanth Menon (2013-04-09 13:49:00) >> Folks, this does seem to be the best compromise we can achieve at this >> point in time. feedback on this approach is much appreciated - if folks >> are ok, I can post this as an formal patch series. > > This looks fine to me. Minor comments below. Thanks on the review. will fix in my next post Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 1:46 PM, Mike Turquette wrote: > Quoting Nishanth Menon (2013-04-10 10:39:21) >> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c >> new file mode 100644 >> index 000..63a4cce >> --- /dev/null >> +++ b/drivers/clk/omap/clk.c >> @@ -0,0 +1,94 @@ >> +/* >> + * Texas Instruments OMAP Clock driver >> + * >> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ >> + * Nishanth Menon >> + * Tony Lindgren >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include > > Please use clk-provider.h. Otherwise this looks like an OK transitional k. thanks for checking up on this. will update. > solution. Hopefully this will be replaced with a more legitimate clock > driver for 3.11. I hope so too. At least we should start debate with the direction we'd like to take and start migrating towards that purpose. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Hi Tony,
On Wed, Apr 10, 2013 at 1:49 PM, Tony Lindgren wrote:
> * Nishanth Menon [130410 10:44]:
>> Details in the patch below (Tony, I have added you as collaborator for
>> helping in getting this working-clk_add_alias was'nt needed in the
>> internal patch discussion we had - I have taken a bit of freedom in
>> adding your contributions to the patch below)
>
> OK thanks. Noticed few minor things, see below.
Thanks on the checkup
>
>> Folks, this does seem to be the best compromise we can achieve at this
>> point in time. feedback on this approach is much appreciated - if folks
>> are ok, I can post this as an formal patch series.
>>
>> From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001
>> From: Nishanth Menon
>> Date: Tue, 9 Apr 2013 19:26:40 -0500
>> Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock
>> data
>>
>> OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
>> However, this presents an obstacle for using these clock nodes in
>> Device Tree definitions. There are many possible approaches to this
>> problem as discussed in the following thread:
>> http://marc.info/?t=13637032569&r=1&w=2
>
> It might be worth clarifying that this is especially for the board
> specific clocks initially. The fixed clocks are currently found via
> the clock aliases table.
Ack.
[...]
>
>> +Example #2: describing clock node for auxilary clock #3 on OMAP443x
>> platform:
>> +Ref: arch/arm/mach-omap2/cclock44xx_data.c
>> +describes the auxclk3 clock to be as follows:
>> + CLK(NULL, "auxclk3_ck", &auxclk3_ck,CK_443X),
>> +Corresponding binding will be:
>> + auxclk3: auxclk3 {
>> + #clock-cells = <1>;
>> + compatible = "ti,omap-clock";
>> + };
>> +And it's usage will be:
>> + clocks = <&auxclk3>;
>
> The #clock-cells in the auxclk3 example should also be 0 instead of 1
> AFAIK. We should only use #clock-cells = <1> when the same physical
> clock provides multiple outputs. I believe the auxclocks are all separate,
> but that needs to be verified.
Oops.. my bad. you are correct here - auxclk is single output. all of them.
will fix.
[...]
>> +static int omap_clk_probe(struct platform_device *pdev)
>> +{
>> + struct clk *clk;
>> + int res;
>> +
>> + const struct of_device_id *match;
>> + struct device_node *np = pdev->dev.of_node;
>> + char clk_name[32];
>> +
>> + match = of_match_device(omap_clk_of_match, &pdev->dev);
>> +
>> + /* Set up things so consumer can call clk_get() with name */
>> + snprintf(clk_name, 32, "%s_ck", np->name);
>> + clk = clk_get(NULL, clk_name);
>> + if (IS_ERR(clk)) {
>> + res = PTR_ERR(clk);
>> + dev_err(&pdev->dev, "could not get clock %s (%d)\n",
>> + clk_name, res);
>> + goto out;
>> + }
>
> It seems that at least for now we can assume the naming will stay
> that way, then if we need other rules for finding clocks, we can
> add omap_match_clock() function or something.
ack.
>
>> + /* This allows the driver to of_clk_get() */
>> + res = of_clk_add_provider(np, of_clk_src_simple_get, clk);
>> + if (res)
>> + dev_err(&pdev->dev, "could not add provider for %s (%d)\n",
>> + clk_name, res);
>> +
>> + clk_put(clk);
>> +out:
>> + return res;
>> +}
>
> We can avoid the concern of storing the struct clk * and do the
> look up lazily on consumer driver probe by setting a dummy struct
> clk * here. Then replace of_clk_src_simple_get() with a custom
> omap_clk_src_get() that does the lookup and replaces the struct
> clk * with the real one.
Hmm.. this is interesting. will give it a try. Thanks on the suggestion.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 13:55-20130410, Roger Quadros wrote: > On 04/10/2013 11:06 AM, Mike Turquette wrote: > > Quoting Nishanth Menon (2013-04-09 13:49:00) > >> On 10:43-20130409, Tony Lindgren wrote: > >>> * Tony Lindgren [130409 09:54]: > >>>> * Roger Quadros [130409 03:00]: > >>>>> On 04/05/2013 06:58 PM, Tony Lindgren wrote: > >>>>>> > >>>>>> Can't you just use the clock name there to get it? > >>>>> > >>>>> In device tree we don't pass around clock names. You can either get > >>>>> a phandle or an index to the clock. > >>>>> > >>>>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt > >>>> > >>>> Yes I understand that. But the driver/clock/omap driver can just > >>>> remap the DT device initially so the board specific clock is > >>>> found from the clock alias table. Basically initially a passthrough > >>>> driver that can be enhanced to parse DT clock bindings and load > >>>> data from /lib/firmware. > >>> > >>> Actually probably the driver/clock/omap can even do even less > >>> initially. There probably even no need to remap clocks there. > >>> > >>> As long as the DT clock driver understands that a board specific > >>> auxclk is specified in the DT it can just call clk_add_alias() so > >>> the driver will get the right auxclk from cclock44xx_data.c. > >>> > >>> Then other features can be added later on like to allocate a > >>> clock entirely based on the binding etc. > >> I did try to have an implementation for cpufreq using clock nodes. > >> unfortunately, device tree wont let me have arguments of strings :( > >> So, I am unable to do clock = <&clk mpu_dpll>; > >> instead, I am forced to do clock = <&clk 249>; > >> > > > > See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034 > > > > Awesome. Thanks for pointing this out Mike. > > Now all we need to do is create a named define for each clock index in the > header file. Approach #3: Thanks to Tony for collaborating on this: Works for cpufreq-cpu0 - additional patches: http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on beagleXM) Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing this. Details in the patch below (Tony, I have added you as collaborator for helping in getting this working-clk_add_alias was'nt needed in the internal patch discussion we had - I have taken a bit of freedom in adding your contributions to the patch below) Folks, this does seem to be the best compromise we can achieve at this point in time. feedback on this approach is much appreciated - if folks are ok, I can post this as an formal patch series. >From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Tue, 9 Apr 2013 19:26:40 -0500 Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock data OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569&r=1&w=2 Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. example clock = <&clk 5>; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral x uses <&clk 2>, kernel updates to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection and warning. Even though we can claim this is user error, such errors are hard to track down and fix. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. The driver introduced here to do
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 15:49-20130409, Nishanth Menon wrote:
> On 10:43-20130409, Tony Lindgren wrote:
> > * Tony Lindgren [130409 09:54]:
> > > * Roger Quadros [130409 03:00]:
> > > > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > > >
> > > > > Can't you just use the clock name there to get it?
> > > >
> > > > In device tree we don't pass around clock names. You can either get
> > > > a phandle or an index to the clock.
> > > >
> > > > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> > >
> > > Yes I understand that. But the driver/clock/omap driver can just
> > > remap the DT device initially so the board specific clock is
> > > found from the clock alias table. Basically initially a passthrough
> > > driver that can be enhanced to parse DT clock bindings and load
> > > data from /lib/firmware.
> >
> > Actually probably the driver/clock/omap can even do even less
> > initially. There probably even no need to remap clocks there.
> >
> > As long as the DT clock driver understands that a board specific
> > auxclk is specified in the DT it can just call clk_add_alias() so
> > the driver will get the right auxclk from cclock44xx_data.c.
> >
> > Then other features can be added later on like to allocate a
> > clock entirely based on the binding etc.
> I did try to have an implementation for cpufreq using clock nodes.
> unfortunately, device tree wont let me have arguments of strings :(
> So, I am unable to do clock = <&clk mpu_dpll>;
> instead, I am forced to do clock = <&clk 249>;
>
> Here is an attempt on beagleXM - adds every clock node to the list.
> Tons of un-necessary prints added to give an idea - see log:
> http://pastebin.com/F9A2zSTr
>
> Would an cleaned up version be good enough as a step #1 of transition?
>
Approach #2:
Here is yet another revision -> here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an "DT_ID" for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.
>From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)
Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.
Nyet-Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/clock/ti,clock.txt | 48 +++
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi|2 +
arch/arm/boot/dts/omap4.dtsi |5 ++
arch/arm/boot/dts/omap443x.dtsi|2 +
arch/arm/mach-omap2/cclock3xxx_data.c |5 +-
arch/arm/mach-omap2/cclock44xx_data.c |5 +-
arch/arm/mach-omap2/clock.h| 12 +++
arch/arm/mach-omap2/pm.c | 11 ++-
drivers/clk/Kconfig|6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 85
include/linux/clk/ti.h | 30 +++
13 files changed, 211 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt
b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be "ti,clock"
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a list of ID reservations
+across TI SoCs
+
+ Clock ID
+ --
+ cpu clock 1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already
done */
+clks: clocks {
+ compatible = "ti,clock";
+ #clock-cells = &l
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 10:43-20130409, Tony Lindgren wrote:
> * Tony Lindgren [130409 09:54]:
> > * Roger Quadros [130409 03:00]:
> > > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > > >
> > > > Can't you just use the clock name there to get it?
> > >
> > > In device tree we don't pass around clock names. You can either get
> > > a phandle or an index to the clock.
> > >
> > > e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
> >
> > Yes I understand that. But the driver/clock/omap driver can just
> > remap the DT device initially so the board specific clock is
> > found from the clock alias table. Basically initially a passthrough
> > driver that can be enhanced to parse DT clock bindings and load
> > data from /lib/firmware.
>
> Actually probably the driver/clock/omap can even do even less
> initially. There probably even no need to remap clocks there.
>
> As long as the DT clock driver understands that a board specific
> auxclk is specified in the DT it can just call clk_add_alias() so
> the driver will get the right auxclk from cclock44xx_data.c.
>
> Then other features can be added later on like to allocate a
> clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = <&clk mpu_dpll>;
instead, I am forced to do clock = <&clk 249>;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
>From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.
Dummy patch based on Roger's original idea
Nyet-Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi |2 +
arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
arch/arm/mach-omap2/cclock44xx_data.c |3 +-
arch/arm/mach-omap2/pm.c | 11 +++-
drivers/clk/Kconfig |6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 100 +
include/linux/clk/ti.h| 30 ++
9 files changed, 157 insertions(+), 5 deletions(-)
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = "counter_32k";
};
+ clks: clocks {
+ compatible = "ti,clock";
+ #clock-cells = <1>;
+ };
+
intc: interrupt-controller@4820 {
compatible = "ti,omap2-intc";
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
>;
clock-latency = <30>; /* From legacy driver */
+ clocks = <&clks 249>; /* index to cpufreq_ck */
+ clock-names = "cpu";
};
};
};
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "soc.h"
#include "iomap.h"
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c < omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c->cpu & cpu_clkflg) {
- clkdev_add(&c->lk);
+ ti_clk_node_add(&c->lk);
if (!__clk_init(NULL, c->lk.clk))
omap2_init_clk_hw_omap_clocks(c->lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "soc.h"
#i
[PATCH] usb: gadget: composite: fix kernel-doc warnings
A few trivial fixes for composite driver.
Fixes:
Warning(include/linux/usb/composite.h:165): No description found for parameter
'fs_descriptors'
Warning(include/linux/usb/composite.h:165): Excess struct/union/enum/typedef
member 'descriptors' description in 'usb_function'
Warning(include/linux/usb/composite.h:321): No description found for parameter
'gadget_driver'
Warning(drivers/usb/gadget/composite.c:1777): Excess function parameter 'bind'
description in 'usb_composite_probe'
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Jiri Kosina
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Nishanth Menon
---
drivers/usb/gadget/composite.c |5 +
include/linux/usb/composite.h |3 ++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 7c821de..c0d62b2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1757,10 +1757,7 @@ static const struct usb_gadget_driver
composite_driver_template = {
/**
* usb_composite_probe() - register a composite driver
* @driver: the driver to register
- * @bind: the callback used to allocate resources that are shared across the
- * whole device, such as string IDs, and add its configurations using
- * @usb_add_config(). This may fail by returning a negative errno
- * value; it should return zero on successful initialization.
+ *
* Context: single threaded during gadget setup
*
* This function is used to register drivers using the composite driver
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 3c671c1..8860594 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -60,7 +60,7 @@ struct usb_configuration;
* @name: For diagnostics, identifies the function.
* @strings: tables of strings, keyed by identifiers assigned during bind()
* and by language IDs provided in control requests
- * @descriptors: Table of full (or low) speed descriptors, using interface and
+ * @fs_descriptors: Table of full (or low) speed descriptors, using interface
and
* string identifiers assigned during @bind(). If this pointer is null,
* the function will not be available at full speed (or at low speed).
* @hs_descriptors: Table of high speed descriptors, using interface and
@@ -290,6 +290,7 @@ enum {
* after function notifications
* @resume: Notifies configuration when the host restarts USB traffic,
* before function notifications
+ * @gadget_driver: Gadget driver controlling this driver
*
* Devices default to reporting self powered operation. Devices which rely
* on bus powered operation should report this in their @bind method.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: fix trivial usb_device kernel-doc errors
Fix trivial kernel-doc warnings:
Warning(include/linux/usb.h:574): No description found for parameter
'usb3_lpm_enabled'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member
'usb_classdev' description in 'usb_device'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member
'usbfs_dentry' description in 'usb_device'
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Jiri Kosina
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Nishanth Menon
---
include/linux/usb.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 4d22d0f..52464fb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -469,14 +469,12 @@ struct usb3_lpm_parameters {
* @lpm_capable: device supports LPM
* @usb2_hw_lpm_capable: device can perform USB2 hardware LPM
* @usb2_hw_lpm_enabled: USB2 hardware LPM enabled
+ * @usb3_lpm_enabled: USB3 hardware LPM enabled
* @string_langid: language ID for strings
* @product: iProduct string, if present (static)
* @manufacturer: iManufacturer string, if present (static)
* @serial: iSerialNumber string, if present (static)
* @filelist: usbfs files that are open to this device
- * @usb_classdev: USB class device that was created for usbfs device
- * access from userspace
- * @usbfs_dentry: usbfs dentry entry for the device
* @maxchild: number of ports if hub
* @quirks: quirks of the whole device
* @urbnum: number of URBs submitted for the whole device
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
