Re: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000.
Hi Anil, On 03/17/2013 06:23 AM, Anil Kumar wrote: > Hi Benoit, > > On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson wrote: >> Hi, >> >> On 03/06/2013 06:53 PM, Tony Lindgren wrote: >>> * Anil Kumar [130305 18:40]: >>>> Hi Tony, >>>> >>>>>> From: linux-arm-kernel [mailto:linux-arm-kernel- >>>>>> boun...@lists.infradead.org] On Behalf Of Anil Kumar >>>>>> Sent: Wednesday, February 27, 2013 8:03 AM >>>>>> To: devicetree-disc...@lists.ozlabs.org; linux-o...@vger.kernel.org; >>>>>> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org >>>>>> Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant >>>>>> Likely; Anil Kumar; tho...@tomweber.eu >>>>>> Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for >>>>>> DevKit8000. >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> DevKit8000 is a beagle board clone from Timll, sold by >>>>>>> armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D, >>>>>>> S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and >>>>>>> JTAG interface. >>>>>>> >>>>>>> This patch adds the basic DT support for devkit8000. At this time, >>>>>> Information >>>>>>> of twl4030 (PMIC), MMC1, I2C1 and leds are added. >>>>>>> >>>>>>> Signed-off-by: Anil Kumar >>>>>>> Tested-by: Thomas Weber >>>>>> >>>>>> Gentle Ping. As there are no review comments on this patch, >>>>>> Could you please pull this patch ? >>>> >>>> Gentle Ping. >>>> >>>> This patch also got Reviewed-by: Manish Badarkhe >>>> >>>> and as patch "ARM: dts: omap3-devkit8000: Enable audio support" has >>>> already got >>>> "Acked-by: Peter Ujfalusi " but it is on the >>>> top of this patch. >>>> So, Could you please pull this patch in one of your omap branch? or >>>> you want me to >>>> do rebase this patch on top of v3.9-rc1 ? >>> >>> Let's wait for Benoit to queue it as he has a bunch of .dts >>> changesfor_3.10/dts already >>> applied. Too bad we missed v3.9 merge window for those, but hopefully >>> we can get them queued early for v3.10. >> >> Yep, sorry for having missed 3.9, I was a little bit sick at the wrong >> moment :-( >> >> I'm starting queuing the pending patches, and should have enough to push >> to you just after Linaro Connect. > > I think you missed below patch which is needed for gpmc nand to work fine. > > Jon Hunter:- > ARM: OMAP2+: Fix-up gpmc merge error > > I have re based my changes on top of your repository to make pull > easier for you. > I hope you will pull these changes for 3.10. > > The following changes since Commit a7f7881de9c0b58de3b3aea8f01a8aef906d4ade > > are available in the git repository at: > > git://gitorious.org/devkit8000-for_3-10/devkit8000-for_3-10.git > branch for_3.10/dts > > for you to fetch changes up to Commit 975abc8b2e7ec4ff7324d726c9775958945ccc5e Thanks, I pulled the patches and rebased that on top of -rc3 to get the missing fix from Jon. I cleaned as well some changelog / subject and pushed then in my for_3.10/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 03/20/2013 04:44 PM, Roger Quadros wrote: > Hi Tony, > > These patches provide the SoC side code required to support > the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > > Device tree support is added for Beagleboard only. I've removed > Panda device tree support till we have resolved the AUXCLK issue. > > NOTE: The first patch needs to be shared between the > OMAP tree and Felipe's USB tree. > > v4: > - Some more cleanup to usbhs_init_phys(). Moved repeated code into > another helper function usbhs_add_regulator(). > - Removed patch for Panda device tree support for USB host since > it is non functional. > > v3: > - Moved more functionality into usbhs_init_phys(). > > v2: > - Added helper function usbhs_init_phys() that can be used by board files > to simplify adding of PHY regulators for USB host ports. > > [1] MFD side changes to omap-usb-host and omap-usb-tll > https://lkml.org/lkml/2013/3/12/179 > [2] USB EHCI side changes to ehci-omap > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html > [3] USB PHY driver changes > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html > > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: > > Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) > > are available in the git repository at: > git://github.com/rogerq/linux.git usbhost-arm-next > > Roger Quadros (21): > usb: phy: nop: Add some parameters to platform data > ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() > ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes > ARM: OMAP3: Beagle: Adapt to ehci-omap changes > ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes > ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes > ARM: OMAP: AM3517crane: Adapt to ehci-omap changes > ARM: OMAP: AM3517evm: Adapt to ehci-omap changes > ARM: OMAP3: cm-t35: Adapt to ehci-omap changes > ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes > ARM: OMAP: devkit8000: Adapt to ehci-omap changes > ARM: OMAP3: igep0020: Adapt to ehci-omap changes > ARM: OMAP3: omap3evm: Adapt to ehci-omap changes > ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes > ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes > ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes > ARM: OMAP3: overo: Adapt to ehci-omap changes > ARM: OMAP: zoom: Adapt to ehci-omap changes > ARM: dts: OMAP4: Add HS USB Host IP nodes > ARM: dts: OMAP3: Add HS USB Host IP nodes > ARM: dts: omap3-beagle: Add USB Host support These 3 DTS patches are good to me, but I cannot applied them on top of the already existing patches I queued for 3.10. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Could you rebase these 3 ones only, and I will applied them. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 04/05/2013 10:30 AM, Benoit Cousson wrote: ... >> ARM: dts: OMAP4: Add HS USB Host IP nodes >> ARM: dts: OMAP3: Add HS USB Host IP nodes >> ARM: dts: omap3-beagle: Add USB Host support > > These 3 DTS patches are good to me, but I cannot applied them on top of > the already existing patches I queued for 3.10. > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.10/dts > > Could you rebase these 3 ones only, and I will applied them. Mmm, in fact, I've just seen the pull request from Tony :-( Tony, Don't you want to remove these DTS patches from the pull-request? Otherwise, I will have to rebase the whole DTS series on top of yours. That being said, if the branch is not supposed to be rebased, it is doable. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 23/24] ARM: OMAP2+: Allow clock alias provision from device tree
Hi Roger,
On 03/12/2013 12:43 PM, Roger Quadros wrote:
> Currently on OMAP, it is not possible to specify a clock consumer
> to any of the OMAP generated clocks using the device tree. This can pose
> a problem for external devices that run off an OMAP clock as we
> can't reliably provide a reference to the clock in the device tree.
I'm really confused by that statement... Why cannot you use the current
clock binding definition?
The point is that we should avoid defining temporary custom bindings.
Especially when a generic one already exist.
I know you already discussed that on the list, but I cannot really find
the rational in the previous thread.
Here is a quote from the original "Subject: Re: how to specify an OMAP
clock in device tree?" thread.
> /* provider */
> clks: omapclocks {
> compatible = "ti,omapclocks";
> #clock-cells = <1>;
> };
>
> /* consumer */
> hsusb1_phy: hsusb1_phy {
> compatible = "usb-nop-xceiv";
> clocks = <&clks "auxclk3_ck">; /* FREF_CLK3 */
> clock-names = "main-clk";
> };
>
> The only problem I see is that the argument to the clks phandle
> cannot be a string. It needs to be u32.
>
> In that case we need to map all clocks into a u32 index.
>
> If we can do that only for auxclks, my problem is solved for panda.
phandle is u32 as always, but you should not care about that.
What you care about is the clock node referenced by the phandle, not the
phandle itself.
What is missing right now is a proper of_clk_add_provider call to
declare a generic OMAP clock provider and thus allow OMAP clocks to be
used with DT.
The AUXCLOCKs are managed by the SCRM which is outside the PRCM, so you
should be able to add a clock providers dedicated to the SCRM clocks only.
Regards,
Benoit
> This patch allows device trees to provide a node that contains the
> clock identifier, clock alias and the device phandle. The board
> initialization code then creates a clock alias to this clock id,
> and associates it with the device whose phandle was supplied.
>
> Discussion
> http://www.spinics.net/lists/linux-omap/msg86241.html
>
> CC: Russell King
> CC: Rajendra Nayak
> CC: Santosh Shilimkar
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/clock/ti-clock-alias.txt | 26
> arch/arm/mach-omap2/board-generic.c| 67
>
> 2 files changed, 93 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/ti-clock-alias.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
> b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
> new file mode 100644
> index 000..87ef4c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
> @@ -0,0 +1,26 @@
> +* Clock alias provision for TI OMAP2+ boards
> +
> +This binding allows the board's device tree file to specify a clock name,
> +device phandle and clock alias so that that clock can be associated
> +to the device with the alias.
> +
> +This is required in cases where an external device is clocked by an
> +OMAP generated clock and needs to be assocated to it.
> +
> +NOTE: The node's name should be clock_alias
> +
> +Required properties
> +- clock-name: The clock identifier string. Should be one of the
> + clock ids defined in OMAP common clock data.
> +- clock-alias: A string specifying the alias that must be created to the
> clock.
> +- device: A phandle to the device this clock should be associated to.
> +
> +e.g. On the OMAP4 Panda board, the USB PHY device is clocked by the
> +FREF_CLK3 (auxclk3_ck) from the OMAP. The PHY driver expexts the clock to
> +be named "main_clk". This binding can be provided like so
> +
> +clock_alias {
> + clock-name = "auxclk3_ck";
> + clock-alias = "main_clk";
> + device = <&hsusb1_phy>;
> +};
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 0274ff7..2fc48f9 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
>
> @@ -35,12 +38,76 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = {
> { }
> };
>
> +static int __init omap_create_clk_alias(struct device_node *np)
> +{
> + int ret = 0;
> + const char *s, *alias;
> + char *clk_id;
> + struct device_node *dev_np;
> + struct platform_device *pdev;
> +
> + of_property_read_string(np, "clock-name", &s);
> + if (!s) {
> + pr_err("%s: couldn't find clock-name property in node %s\n",
> + __func__, np->name);
> + return -ENODEV;
> + }
> +
> + clk_id = kstrdup(s, GFP_KERNEL);
> + if (!clk_id)
> + return -ENOMEM;
> +
> + dev_np = of_parse_phandle(np, "device", 0);
> + if (!dev_np) {
> + pr_err("%s: couldn't find devic
Re: [PATCH 1/2] cpufreq: cpufreq-cpu0: support for clock which are not in DT yet.
Hi Guys,
On 03/12/2013 06:03 AM, Santosh Shilimkar wrote:
> On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
>> On certain SoCs like variants of OMAP, the clock conversion to DT
>> is not complete. In short, the ability to:
>> cpus {
>> cpu@0 {
>> clocks = <&cpuclk 0>;
>> };
>> };
>> is not possible. However, the clock node is registered.
>> Allow for clk names to be provided as string so as to be used when needed.
>> Example (for OMAP3630):
>> cpus {
>> cpu@0 {
>> clock-name = "cpufreq_ck";
>> };
>> };
>>
>> Cc: "Rafael J. Wysocki"
>> Cc: Santosh Shilimkar
>> Cc: Shawn Guo
>> Cc: linux-kernel@vger.kernel.org
>> Cc: cpuf...@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> Cc: linux-o...@vger.kernel.org
>>
>> Signed-off-by: Nishanth Menon
>> ---
> Seems a reasonable to me.
No, it is not...
You cannot add a temp binding just because the OMAP support is not
there, since the real binding already exist.
You need to register properly a clock provider to be able to reference
it.
If you do need a hacky temp code you could do it in OMAP code but not in
the binding.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
On 03/12/2013 06:07 AM, Santosh Shilimkar wrote: > On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote: >> commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) >> now forces platform device to be registered for allowing cpufreq-cpu0 >> to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c >> >> However, for SoCs that wish to link up using device tree, instead >> of platform device, provide compatibility string match: >> compatible = "cpufreq,cpu0"; You cannot add a non-HW relative binding... DT is supposed to represent the pure HW. AFAIK, cpufreq has nothing to do with the HW definition. >> >> Cc: "Rafael J. Wysocki" >> Cc: Santosh Shilimkar >> Cc: Shawn Guo >> Cc: linux-kernel@vger.kernel.org >> Cc: cpuf...@vger.kernel.org >> Cc: linux...@vger.kernel.org >> Cc: linux-o...@vger.kernel.org >> >> Signed-off-by: Nishanth Menon >> --- >> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++ >> drivers/cpufreq/cpufreq-cpu0.c |6 ++ >> 2 files changed, 9 insertions(+) >> > Looks fine to me. CC'ing dt list in case some one has > comments on binding updates. > > Acked-by: Santosh Shilimkar Not-Acked-by-me. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
On 03/12/2013 03:43 PM, Nishanth Menon wrote: > On 15:28-20130312, Benoit Cousson wrote: >> On 03/12/2013 06:07 AM, Santosh Shilimkar wrote: >>> On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote: >>>> commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) >>>> now forces platform device to be registered for allowing cpufreq-cpu0 >>>> to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c >>>> >>>> However, for SoCs that wish to link up using device tree, instead >>>> of platform device, provide compatibility string match: >>>> compatible = "cpufreq,cpu0"; >> >> You cannot add a non-HW relative binding... DT is supposed to represent >> the pure HW. >> AFAIK, cpufreq has nothing to do with the HW definition. > Ref: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/highbank-cpufreq.c#n61 > there is a need for a device of some sort. in the example above, we > register a dummy device for linking up with cpufreq-cpu0 driver. > what we do in this patch is to indicate that SoC CPUs are managed by > cpufreq-cpu0 driver. > > I am a bit curious to see how else would we represent drivers to manage > real h/w devices like CPU? Is the highbank style the recommended way to do > things? Yep, I don't think this is a very elegant way to do that, but until we do have a generic DVFS layer, I'm not sure we have any other approach. But maybe not. The CPU is the real device, but AFAIK, nobody beside OMAP is representing the CPU as the device. But I'd rather use a CPU device than a fake CPUFREQ device. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
Hi Javier,
On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
> On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit wrote:
>> Hi Matthias,
>>
>>
>> On 2/15/2013 10:35 AM, Matthias Brugger wrote:
>>>
>>> 2013/1/26 Javier Martinez Canillas :
>>>>
>>>> On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
>>>>
>>>> wrote:
>>>>>
>>>>> Hi Benoit,
>>>>>
>>>>> 2012/12/12 Benoit Cousson :
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> On 12/12/2012 04:33 PM, Matthias Brugger wrote:
>>>>>>>
>>>>>>> This patch is a follow-up patch for Javier Martinez effort adding
>>>>>>> initial
>>>>>>> device tree support to IGEP technology devices. [1]
>>>>>>>
>>>>>>> It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
>>>>>>> boards.
>>>>>>>
>>>>>>> [1] http://www.spinics.net/lists/linux-omap/msg83409.html
>>>>>>>
>>>>>>> Signed-off-by: Matthias Brugger
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/omap3-igep.dtsi | 24
>>>>>>> 1 file changed, 24 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
>>>>>>> b/arch/arm/boot/dts/omap3-igep.dtsi
>>>>>>> index 125fe00..c02e3c0 100644
>>>>>>> --- a/arch/arm/boot/dts/omap3-igep.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
>>>>>>> @@ -27,6 +27,20 @@
>>>>>>> };
>>>>>>>
>>>>>>> &omap3_pmx_core {
>>>>>>> + uart1_pins: pinmux_uart1_pins {
>>>>>>> + pinctrl-single,pins = <
>>>>>>> + 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
>>>>>>> MODE0
>>>>>>> */
>>>>>>> + 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
>>>>>>> MODE0 */
>>>>>>> + >;
>>>>>>> + };
>>>>>>> +
>>>>>>> + uart2_pins: pinmux_uart2_pins {
>>>>>>> + pinctrl-single,pins = <
>>>>>>> + 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
>>>>>>> MODE0
>>>>>>> */
>>>>>>> + 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
>>>>>>> MODE0 */
>>>>>>> + >;
>>>>>>> + };
>>>>>>> +
>>>>>>>uart3_pins: pinmux_uart3_pins {
>>>>>>>pinctrl-single,pins = <
>>>>>>>0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
>>>>>>> MODE0
>>>>>>> */
>>>>>>> @@ -77,6 +91,16 @@
>>>>>>>status = "disabled";
>>>>>>> };
>>>>>>>
>>>>>>> +&uart1 {
>>>>>>> + pinctrl-names = "default";
>>>>>>> + pinctrl-0 = <&uart1_pins>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&uart2 {
>>>>>>> + pinctrl-names = "default";
>>>>>>> + pinctrl-0 = <&uart2_pins>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &uart3 {
>>>>>>> pinctrl-names = "default";
>>>>>>> pinctrl-0 = <&uart3_pins>;
>>>>>>>
>>>>>>
>>>>>> That looks good to me. I'll apply it on top of javier's series for 3.9.
>>>>>
>>>>>
>>>>> Can you pin-point me to the repository where this patches are in right
>>>>> now? I tried to figure it out these days, but didn't found where to
>>>>> clone the repository from.
>>>>>
>>>>> Thanks,
>>>>> Matthias
>>>>>
>>>>
>>>> Hi Matthias,
>>>>
>>>> OMAP DT tree is:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>>>
>>>
>>> Hi all,
>>>
>>> unfortunately I can't find the patch in this tree.
>>
>>
>> Sorry about that. I've never pushed the latest branch, and was busy the past
>> month. I'll refresh the branch with all the pending patches.
>>
>> Regards,
>> Benoit
>>
>
> Hi Benoit,
>
> I realized that your for_3.9/dts branch has not landed in mainline yet
> and we are near to the end of the merge window.
>
> Are you still planing to include those changes for 3.9 or are you
> going to wait until the next release?
I'm really sorry about that. I was not available to push it at the proper time.
I've just rebased it on 3.9-rc2 and pushed it to a new branch.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
It includes the one from Matthias and yours as well. I'm still checking my
inbox to catch up on the new ones I missed.
I'm planning to push this ASAP to avoid missing the deadline again.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Hi Kishon, On 03/13/2013 10:11 AM, kishon wrote: > Benoit, > > Will you be queuing this patch series? I'm reviewing them right now. Regards, Benoit > > Thanks > Kishon > > On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: >> Hi Benoit, >> >> Here are the dt data patches to get usb device functional in OMAP >> platforms. >> >> All the patches deal with modifying arch/arm/boot except one which >> modifies >> Documentation/../usb/omap-usb.txt >> >> Changes from v2: >> * squashed the dt data for dwc3-omap with dwc3 core into a single patch. >> >> Changes from v1: >> Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties >> with >> names that has "_". It's replaced with a "-" here. >> >> This patch is developed on Linux 3.9-rc1. >> >> Kishon Vijay Abraham I (7): >>ARM: dts: omap: Add omap control usb data >>ARM: dts: omap: Add omap-usb2 dt data >>ARM: dts: omap: Add usb_otg and glue data >>ARM: dts: omap5: Add omap control usb data >>ARM: dts: omap5: Add ocp2scp data >>ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data >>ARM: dts: omap5: add dwc3 omap and dwc3 core dt data >> >> Documentation/devicetree/bindings/usb/omap-usb.txt |1 + >> arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ >> arch/arm/boot/dts/omap3-evm.dts|6 +++ >> arch/arm/boot/dts/omap3-overo.dtsi |6 +++ >> arch/arm/boot/dts/omap3.dtsi | 12 + >> arch/arm/boot/dts/omap4-panda.dts |6 +++ >> arch/arm/boot/dts/omap4-sdp.dts|6 +++ >> arch/arm/boot/dts/omap4.dtsi | 26 +++ >> arch/arm/boot/dts/omap5.dtsi | 48 >> >> arch/arm/boot/dts/twl4030.dtsi |2 +- >> 10 files changed, 118 insertions(+), 1 deletion(-) >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
+ Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: > Hi Benoit, > > Here are the dt data patches to get usb device functional in OMAP platforms. > > All the patches deal with modifying arch/arm/boot except one which modifies > Documentation/../usb/omap-usb.txt > > Changes from v2: > * squashed the dt data for dwc3-omap with dwc3 core into a single patch. > > Changes from v1: > Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with > names that has "_". It's replaced with a "-" here. > > This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Jon, You might have to rebase your series on top of the new HEAD before reposting. Thanks, Benoit > Kishon Vijay Abraham I (7): > ARM: dts: omap: Add omap control usb data > ARM: dts: omap: Add omap-usb2 dt data > ARM: dts: omap: Add usb_otg and glue data > ARM: dts: omap5: Add omap control usb data > ARM: dts: omap5: Add ocp2scp data > ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data > ARM: dts: omap5: add dwc3 omap and dwc3 core dt data > > Documentation/devicetree/bindings/usb/omap-usb.txt |1 + > arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ > arch/arm/boot/dts/omap3-evm.dts|6 +++ > arch/arm/boot/dts/omap3-overo.dtsi |6 +++ > arch/arm/boot/dts/omap3.dtsi | 12 + > arch/arm/boot/dts/omap4-panda.dts |6 +++ > arch/arm/boot/dts/omap4-sdp.dts|6 +++ > arch/arm/boot/dts/omap4.dtsi | 26 +++ > arch/arm/boot/dts/omap5.dtsi | 48 > > arch/arm/boot/dts/twl4030.dtsi |2 +- > 10 files changed, 118 insertions(+), 1 deletion(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 0/4] Add device tree data for omap5
Hi Sourav, While rebasing your series on top of Tony's lo/devel-dt, I realized that the keypad nodes are not located at the correct place :-( At the moment they are just floating at the top level of the dts while they belong to the ocp bus and thus should be put there. I fixed that since it was trivial and cleaned as well the changelog and the comments to aligned then properly. I added as well the physical address to the node name and a label for easy reference at board level. I did some basic test on my OMAP4 sdp, but that all I can do so far. Could you just check if this is still fine for OMAP5 before I ask Tony to pull that. I based that on top of Tony's DT patches due to conflict with the existing MMC patch in it. The following changes since commit 85d7ff9b907685b646905f1d961b3e8d47ad: Olof Johansson (1): ARM: omap: add dtb targets are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Sourav Poddar (6): arm/dts: omap5-evm: Add I2C support arm/dts: omap5-evm: Add tmp102 sensor support arm/dts: omap5-evm: Add keypad data arm/dts: omap5-evm: Add bmp085 sensor support arm/dts: omap4-sdp: Add keypad data Documentation: dt: i2c: trivial-devices: Update for tmp102 .../devicetree/bindings/i2c/trivial-devices.txt|1 + arch/arm/boot/dts/omap4-sdp.dts| 70 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/boot/dts/omap5-evm.dts| 33 + arch/arm/boot/dts/omap5.dtsi | 40 +++ 5 files changed, 149 insertions(+), 0 deletions(-) Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
> With the new devices (like, AM33XX and OMAP5) we now only support
> DT boot mode of operation and now it is the time to start killing
> slowly the dependency on hwmod, so with this patch, we are starting
> with device resources.
Thanks for working on that.
> The idea here is implemented considering to both boot modes -
> - DT boot mode
> OF framework will construct the resource structure (currently
> does for MEM & IRQ resource) and we should respect/use these
> resources, killing hwmod dependency.
> If pdev->num_resources > 0, we assume that MEM & IRQ resources
> have been allocated by OF layer already (through DTB).
>
> Once DMA resource is available from OF layer, we should
> kill filling any resources from hwmod.
Yeap, I did a similar patch some months ago and decided to drop it
because I was expected the DMA binding to be there and wanted to avoid
adding more code that we are going to remove later.
The other potential issue is that when the binding will be there, we
will have to update all the drivers and DTS first before being able to
change the hwmod code from hwmod DMA to DTS DMA.
I was thinking of something smoother that will check if DMA is in DTS
and fall back to hwmod if not to avoid that.
But again, I'm not sure it worth the effort.
> - Non-DT boot mode
> Here, pdev->num_resources = 0, and we should get all the
> resources from hwmod (following existing steps)
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> ---
> This patch is tested on BeagleBone and AM37xEVM.
I'll try to do more testing on Panda next week.
> Why RFC?
> Still we have function duplication omap_device_fill_resources() and
> omap_device_fill_dma_resources(), we can actually split the function
> into 3 resources and avoid duplication -
> - omap_device_fill_dma_resources()
> - omap_device_fill_mem_resources()
> - omap_device_fill_irq_resources()
>
> Actually I wanted to clean it further but thought of getting
> feedback first and then proceed further.
Well, that's anyway temporary code that should be gone in 6 months from
now (ideally). So that looks pretty good to me.
> arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> arch/arm/plat-omap/omap_device.c | 72 +
> 3 files changed, 88 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 31ec283..edabfb3 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3330,6 +3330,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> struct resource *res)
> }
>
> /**
> + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> + * @oh: struct omap_hwmod *
> + * @res: pointer to the array of struct resource to fill
> + *
> + * Fill the struct resource array @res with dma resource data from the
> + * omap_hwmod @oh. Intended to be called by code that registers
> + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> + * number of array elements filled.
> + */
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res)
> +{
> + int i, sdma_reqs_cnt;
> + int r = 0;
> +
> + sdma_reqs_cnt = _count_sdma_reqs(oh);
> + for (i = 0; i < sdma_reqs_cnt; i++) {
> + (res + r)->name = (oh->sdma_reqs + i)->name;
> + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->flags = IORESOURCE_DMA;
> + r++;
> + }
> +
> + return r;
> +}
> +
> +/**
> * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> * @oh: struct omap_hwmod * to operate on
> * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 9b9646c..0533073 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
>
> int omap_hwmod_count_resources(struct omap_hwmod *oh);
> int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res);
> int omap_hwmod_get_resource_byname(struct oma
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On 08/31/2012 05:36 PM, Hiremath, Vaibhav wrote: > On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote: ... > I think you are getting confused between Vaibhav B and Vaibhav H :) > We have two Vaibhav's roaming around here ;-) Oops, sorry, this is the very first time I realized that two different Vaibhav were sending patches on very similar topic... That's why you were so good generating a lot of patches :-) You have a dual channel of patches :-) > I was not there during LPC this time, it was Vaibhav B who attended it. > I will sync up with him and try to get more info on it. Sorry again for the confusion. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm/dts: omap: Add omap-usb2 dt data
Hi Kishon,
On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote:
> Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
> connected to ocp2scp, omap-usb2 dt data is added as a child node
> of ocp2scp.
Could you add more details about the omap-usb2?
You must update the Documentation binding with that compatible name.
Is it already part of the driver serie? The MUSB driver is referring to
"ti,musb-omap2430" only.
>
> Acked-by: Felipe Balbi
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Applies on
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
> arch/arm/boot/dts/omap4.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 8a780b2..bdc21f1 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -302,6 +302,11 @@
> #size-cells = <1>;
> ranges;
> ti,hwmods = "ocp2scp_usb_phy";
There is no ocp2scp_usb_phy in the current omap4.dtsi?
What base did you used?
You have to use lo/devel-dt branch as a base. All the latest DTS patches
an in there for 3.7.
Regards,
Benoit
> + usb2phy@4a0ad080 {
> + compatible = "ti,omap-usb2";
> + reg = <0x4a0ad080 0x58>,
> + <0x4a002300 0x4>;
> + };
> };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] arm/dts: omap: add dt data for MUSB
On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote: > No major change from the previous version. Just removed the > omap-usb2 dt data and sent that as a separate patch. Well, I think you'd better keep them in the same series :-) > Rebased on > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb Since it is DTS stuf, you should rebase that on top of the latest lo/devel-dt branch. All the latest DTS patches an in there for 3.7. While you are there, could you please rename the patches with "ARM: dts" prefix. It seems that this is the new convention :-) Regards, Benoit > > Kishon Vijay Abraham I (3): > arm/dts: Add twl6030-usb data > arm/dts: Add twl4030-usb data > arm/dts: omap: Add usb_otg and glue data > > arch/arm/boot/dts/omap3-beagle.dts |6 ++ > arch/arm/boot/dts/omap3-evm.dts|6 ++ > arch/arm/boot/dts/omap3.dtsi |8 > arch/arm/boot/dts/omap4-panda.dts | 10 ++ > arch/arm/boot/dts/omap4-sdp.dts| 10 ++ > arch/arm/boot/dts/omap4.dtsi |8 > arch/arm/boot/dts/twl4030.dtsi | 21 + > arch/arm/boot/dts/twl6030.dtsi |5 + > 8 files changed, 74 insertions(+) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] arm/dts: omap: add dt data for MUSB
On 09/11/2012 10:44 AM, ABRAHAM, KISHON VIJAY wrote: > Hi Benoit, > > On Tue, Sep 11, 2012 at 1:55 PM, Benoit Cousson wrote: >> On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote: >>> No major change from the previous version. Just removed the >>> omap-usb2 dt data and sent that as a separate patch. >> >> Well, I think you'd better keep them in the same series :-) >> >>> Rebased on >>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb >> >> Since it is DTS stuf, you should rebase that on top of the latest >> lo/devel-dt branch. All the latest DTS patches an in there for 3.7. > > The ocp2scp data is not in linux-omap :-( And omap-usb2 has to be a > child of ocp2scp. So I used arm-soc tree to which ocp2scp stuff was > pulled into. Mmm, but from what tree? It did not go through Tony? What arm-soc branch exactly? In that case we need to merge Tony's devel-dt into arm-soc to have a common base or ask Tony to rebase on top of arm-soc. I added a bunch of change inside OMAP4.dtsi, so we can expect some nice conflicts. That's why it is better to push DTS patches using a single channel. Tony, What will make more sense to avoid merge conflict later? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On 09/11/2012 11:09 AM, Kishon Vijay Abraham I wrote:
> The mailbox register for usb otg in omap is present in control module.
> On detection of any events VBUS or ID, this register should be written
> to send the notification to musb core.
>
> Till we have a separate control module driver to write to control module,
> omap2430 will handle the register writes to control module by itself. So
> a new address space to represent this control module register is added
> to usb_otg_hs.
>
> Signed-off-by: Kishon Vijay Abraham I
Acked-by: Benoit Cousson
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 242aee4..3c19120 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
> omap44xx_usb_otg_hs_addrs[] = {
> .pa_end = 0x4a0ab003,
> .flags = ADDR_TYPE_RT
> },
> + {
> + /* XXX: Remove this once control module driver is in place */
> + .pa_start = 0x4a00233c,
> + .pa_end = 0x4a00233f,
> + .flags = ADDR_TYPE_RT
> + },
> { }
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] arm/dts: Add twl6030-usb data
On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote:
> Add twl6030-usb data node in twl6030 device tree file
>
> Acked-by: Felipe Balbi
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/omap4-panda.dts |4
> arch/arm/boot/dts/omap4-sdp.dts |4
> arch/arm/boot/dts/twl6030.dtsi|5 +
> 3 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 9880c12..2999eba 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -126,3 +126,7 @@
> ti,non-removable;
> bus-width = <4>;
> };
> +
> +&twlusb {
> + usb-supply = <&vusb>;
> +};
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 72216e9..d8290c0 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -226,3 +226,7 @@
> bus-width = <4>;
> ti,non-removable;
> };
> +
> +&twlusb {
> + usb-supply = <&vusb>;
> +};
> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
> index 3b2f351..8e3aac9 100644
> --- a/arch/arm/boot/dts/twl6030.dtsi
> +++ b/arch/arm/boot/dts/twl6030.dtsi
> @@ -83,4 +83,9 @@
> clk32kg: regulator@12 {
> compatible = "ti,twl6030-clk32kg";
> };
> +
> + twlusb: twl6030-usb {
That name should be a generic device class name is possible.
What is twl6030-usb exactly? an USB PHY?
> + compatible = "ti,twl6030-usb";
> + interrupts = < 4 10 >;
If this is for two interrupts, you'd better split them to avoid
confusion with irq specifiers that requires several attributes like for
the GIC.
+ interrupts = <4>, <10>; /* IRQ1 blabla, IRQ2 blabla*/
The comments are not mandatory assuming the binding is documented.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] arm/dts: omap: add dt data for MUSB
On 09/11/2012 11:16 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Tue, Sep 11, 2012 at 2:41 PM, Benoit Cousson wrote:
>> On 09/11/2012 10:44 AM, ABRAHAM, KISHON VIJAY wrote:
>>> Hi Benoit,
>>>
>>> On Tue, Sep 11, 2012 at 1:55 PM, Benoit Cousson wrote:
>>>> On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote:
>>>>> No major change from the previous version. Just removed the
>>>>> omap-usb2 dt data and sent that as a separate patch.
>>>>
>>>> Well, I think you'd better keep them in the same series :-)
>>>>
>>>>> Rebased on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb
>>>>
>>>> Since it is DTS stuf, you should rebase that on top of the latest
>>>> lo/devel-dt branch. All the latest DTS patches an in there for 3.7.
>>>
>>> The ocp2scp data is not in linux-omap :-( And omap-usb2 has to be a
>>> child of ocp2scp. So I used arm-soc tree to which ocp2scp stuff was
>>> pulled into.
>>
>> Mmm, but from what tree? It did not go through Tony?
>> What arm-soc branch exactly?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
> (or) ocp2scp
OK, here it is:
+
+ ocp2scp {
+ compatible = "ti,omap-ocp2scp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "ocp2scp_usb_phy";
+ };
In order to be consistent with the OMAP4 data now, you should update it
to add the reg, and IRQ if applicable.
But for that we do need a proper base with ocp2scp + devel-dt.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] arm/dts: Add twl6030-usb data
On 09/11/2012 11:39 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Tue, Sep 11, 2012 at 2:56 PM, Benoit Cousson wrote:
>> On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote:
>>> Add twl6030-usb data node in twl6030 device tree file
>>>
>>> Acked-by: Felipe Balbi
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> arch/arm/boot/dts/omap4-panda.dts |4
>>> arch/arm/boot/dts/omap4-sdp.dts |4
>>> arch/arm/boot/dts/twl6030.dtsi|5 +
>>> 3 files changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda.dts
>>> b/arch/arm/boot/dts/omap4-panda.dts
>>> index 9880c12..2999eba 100644
>>> --- a/arch/arm/boot/dts/omap4-panda.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda.dts
>>> @@ -126,3 +126,7 @@
>>> ti,non-removable;
>>> bus-width = <4>;
>>> };
>>> +
>>> +&twlusb {
>>> + usb-supply = <&vusb>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 72216e9..d8290c0 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -226,3 +226,7 @@
>>> bus-width = <4>;
>>> ti,non-removable;
>>> };
>>> +
>>> +&twlusb {
>>> + usb-supply = <&vusb>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
>>> index 3b2f351..8e3aac9 100644
>>> --- a/arch/arm/boot/dts/twl6030.dtsi
>>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>>> @@ -83,4 +83,9 @@
>>> clk32kg: regulator@12 {
>>> compatible = "ti,twl6030-clk32kg";
>>> };
>>> +
>>> + twlusb: twl6030-usb {
>>
>> That name should be a generic device class name is possible.
>> What is twl6030-usb exactly? an USB PHY?
>
> Of late we are calling it the comparator as it's used only to detect
> VBUS/ID events.
> Should it be like usb-comparator? What should be the label?
usb-comparator looks good and generic enough.
The label is useless until you reference it somewhere else. But in the
case of the label, it can be more specific.
But you can just use "twl-usb-comparator" for example.
>>
>>> + compatible = "ti,twl6030-usb";
>>> + interrupts = < 4 10 >;
>>
>> If this is for two interrupts, you'd better split them to avoid
>> confusion with irq specifiers that requires several attributes like for
>> the GIC.
>
> yeah. Thats for 2 interrupts.
>>
>> + interrupts = <4>, <10>; /* IRQ1 blabla, IRQ2 blabla*/
>>
>> The comments are not mandatory assuming the binding is documented.
>
> It's documented *usb: twl6030: Add dt support for twl6030 usb*
Yeah, sorry for that, but it is indeed very confusing to review the DTS
without having the binding documentation already merged :-(
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] arm/dts: Add twl4030-usb data
On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote:
> Add twl4030-usb data node in twl4030 device tree file.
IIRC, the usb part on twl4030 was doing more than it does on twl6030.
Could you describe what part of the USB is really done by the TWL in
that case?
> Acked-by: Felipe Balbi
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/twl4030.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
> index 22f4d13..761a5a5 100644
> --- a/arch/arm/boot/dts/twl4030.dtsi
> +++ b/arch/arm/boot/dts/twl4030.dtsi
> @@ -37,6 +37,18 @@
> regulator-max-microvolt = <315>;
> };
>
> + vusb1v5: regulator-vusb1v5 {
> + compatible = "ti,twl4030-vusb1v5";
> + };
> +
> + vusb1v8: regulator-vusb1v8 {
> + compatible = "ti,twl4030-vusb1v8";
> + };
> +
> + vusb3v1: regulator-vusb3v1 {
> + compatible = "ti,twl4030-vusb3v1";
> + };
> +
> twl_gpio: gpio {
> compatible = "ti,twl4030-gpio";
> gpio-controller;
> @@ -44,4 +56,13 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> };
> +
> + twl4030-usb {
Same comment than before about the name. Is it the usb-comparator as well?
> + compatible = "ti,twl4030-usb";
> + interrupts = < 10 4 >;
> + usb1v5-supply = <&vusb1v5>;
> + usb1v8-supply = <&vusb1v8>;
> + usb3v1-supply = <&vusb3v1>;
> + usb_mode = <1>;
Is this a TI only attribute or something generic?
If this is TI only, it should be prefix with "ti," otherwise, it is fine.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] arm/dts: omap: Add usb_otg and glue data
On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote:
> Add usb otg data node in omap4/omap3 device tree file. Also update
> the node with board specific setting in omapx-.dts file.
> Acked-by: Felipe Balbi
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/omap3-beagle.dts |6 ++
> arch/arm/boot/dts/omap3-evm.dts|6 ++
> arch/arm/boot/dts/omap3.dtsi |8
> arch/arm/boot/dts/omap4-panda.dts |6 ++
> arch/arm/boot/dts/omap4-sdp.dts|6 ++
> arch/arm/boot/dts/omap4.dtsi |8
> 6 files changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index cdcb98c..6d6a7a4 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -67,3 +67,9 @@
> &mmc3 {
> status = "disabled";
> };
> +
> +&usb_otg_hs {
> + interface_type = <0>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index f349ee9..c4ac75e 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -46,3 +46,9 @@
> reg = <0x5c>;
> };
> };
> +
> +&usb_otg_hs {
> + interface_type = <0>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 8109471..2501416 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -220,5 +220,13 @@
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> };
> +
> + usb_otg_hs: usb_otg_hs {
> + compatible = "ti,omap3-musb";
> + ti,hwmods = "usb_otg_hs";
> + multipoint = <1>;
> + num_eps = <16>;
> + ram_bits = <12>;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 2999eba..8cded95 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -130,3 +130,9 @@
> &twlusb {
> usb-supply = <&vusb>;
> };
> +
> +&usb_otg_hs {
> + interface_type = <1>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index d8290c0..24f4bfd 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -230,3 +230,9 @@
> &twlusb {
> usb-supply = <&vusb>;
> };
> +
> +&usb_otg_hs {
> + interface_type = <1>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 04cbbcb..5db3d6a 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -295,5 +295,13 @@
> interrupt-parent = <&gic>;
> ti,hwmods = "dmic";
> };
> +
> + usb_otg_hs: usb_otg_hs {
After rebasing your series on top of devel-dt, you should as well add
the missing reg/irq entries that are now supported thanks to Vaibhav.
Regards,
Benoit
> + compatible = "ti,omap4-musb";
> + ti,hwmods = "usb_otg_hs";
> + multipoint = <1>;
> + num_eps = <16>;
> + ram_bits = <12>;
> + };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] arm/dts: omap: add dt data for MUSB
Hi Kishon, Beside minor comments and the lack of explicit changelog to explain what part of the HW you are addressing, this series looks good. I guess that series should be rebased on top of lo/devel-dt without much trouble. On 09/11/2012 08:36 AM, Kishon Vijay Abraham I wrote: > No major change from the previous version. Just removed the > omap-usb2 dt data and sent that as a separate patch. Indeed that one will be trickier to merge properly, so my second thought is it is better to have it separated. Regards, Benoit > > Rebased on > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git musb > > Kishon Vijay Abraham I (3): > arm/dts: Add twl6030-usb data > arm/dts: Add twl4030-usb data > arm/dts: omap: Add usb_otg and glue data > > arch/arm/boot/dts/omap3-beagle.dts |6 ++ > arch/arm/boot/dts/omap3-evm.dts|6 ++ > arch/arm/boot/dts/omap3.dtsi |8 > arch/arm/boot/dts/omap4-panda.dts | 10 ++ > arch/arm/boot/dts/omap4-sdp.dts| 10 ++ > arch/arm/boot/dts/omap4.dtsi |8 > arch/arm/boot/dts/twl4030.dtsi | 21 + > arch/arm/boot/dts/twl6030.dtsi |5 + > 8 files changed, 74 insertions(+) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Hi Paul, On 09/12/2012 12:28 AM, Paul Walmsley wrote: > Hi Kishon, Benoît, > > On Fri, 7 Sep 2012, Kishon Vijay Abraham I wrote: > >> Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this >> ocp2scp module does not have any fck but does have a single opt_clock, >> it is added as the main_clk for ocp2scp. Also removed phy_48m as the >> optional clock since it is now made as the main clock. By this the >> driver need not enable/disable phy_48m clk separately and >> runtime_get/runtime_put will take care of that. > > Looking at this patch, it doesn't seem to make sense from a hardware point > of view. If you look at the OMAP4430 TRM Rev. AE, Table 23-1166 "Clocks > and Resets", the 48MHz clock input is listed as an "Optional functional > clock". The main functional clock is listed as "INIT_960M_FCLK", which > according to the same TRM, Section 3.6.3.9.1 "Overview", is an alias for > the clock we call "dpll_usb_clkdcoldo_ck". > > So if any clock should be the main functional clock in the hwmod data, > shouldn't it be dpll_usb_clkdcoldo_ck? The goal with the hwmod data > is/was to have it match the hardware. In this case, the ocp2scp IP is just the *bus controller* to access the real USB_UTMI_PHY IP. The TRM diagram does not show that level of detail unfortunately. You can check the PRCM spec (Figure 78 : CD_L3_INIT_USB clock scheme) to see the two modules. So considering phy_48m as the main clock is still correct for the ocp2scp IP. The INIT_960M_FCLK will be a fck associated with the child of the ocp2scp nodes which is the usb_phy. Upgrading the opt_clk to fck does make sense as soon as we don't have any other functional clock and as soon as this clock is *mandatory*. The optional aspect in that case is just a wrong PRCM naming for a clock that is mandatory. It is similar to the DSS case that does have only optional clocks that are mandatory. I do agree that we must stick to the HW definition as far as we can. But the optional attribute is something that is wrong/inaccurate for a couple of IPs. HW folks agreed on that point and will fix that in the future. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctrl. Is
> there a better place to select default pin configuration; maybe when
> instantiating platform device?
Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named "get_select_default" and not "get" only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.
There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.
But, maybe I'm missing your point.
Regards,
Benoit
>
> Thanks.
>
>>
>> Cc: Felipe Balbi
>> Cc: Dmitry Torokhov
>> Signed-off-by: Sourav Poddar
>> ---
>> v1->v2
>> - Added "PROBE_DEFER" check
>> drivers/input/keyboard/omap4-keypad.c | 11 +++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/omap4-keypad.c
>> b/drivers/input/keyboard/omap4-keypad.c
>> index c05f98c..502b832 100644
>> --- a/drivers/input/keyboard/omap4-keypad.c
>> +++ b/drivers/input/keyboard/omap4-keypad.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -76,6 +77,7 @@ enum {
>>
>> struct omap4_keypad {
>> struct input_dev *input;
>> +struct pinctrl *pins;
>>
>> void __iomem *base;
>> unsigned int irq;
>> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct
>> platform_device *pdev)
>> goto err_release_mem;
>> }
>>
>> +keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
>> +if (IS_ERR(keypad_data->pins)) {
>> +if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>> +
>> +dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
>> +PTR_ERR(keypad_data->pins));
>> +keypad_data->pins = NULL;
>> +}
>>
>> /*
>> * Enable clocks for the keypad module so that we can read
>> --
>> 1.7.1
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Linus, On 10/23/2012 11:13 AM, Linus Walleij wrote: > On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov > wrote: >> Hi Sourav, >> >> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: >>> Adapt keypad to use pinctrl framework. >>> >>> Tested on omap4430 sdp with 3.7-rc1 kernel. >> >> I do not see anything in the driver that would directly use pinctrl. Is >> there a better place to select default pin configuration; maybe when >> instantiating platform device? > > The option is to use pinctrl hogs. Then the pins will be taken, > muxed and configured by the pin controller itself. > > Another option (not implemented) is to use bus notifiers. > > (I wrote about this in some other thread but can't find it now.) > > Each approach above come with its own set of problems. > > If the driver need to handle multiple states like default/idle/sleep > it is IMO better to put the handling into the driver, so if that > is what is going to happen also to this driver it could be a good > idea to actually implement that code upfront and include in > this submission so as to show that this driver is really going > to exercise its pins. > > But it's also a question of conformity: if other drivers in the > system is using different states and this is the only one > using a single "default" state, then it doesn't make sense > to have just one driver get its pins using hogs, it's just > inconsistent. > > So Sourav, please tell us a bit about your plans for this > and other drivers! Yeah, this idea is to handle pinctrl from all the drivers, and potentially change the mode during suspend when it is relevant. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 04:49 PM, Jon Hunter wrote:
> Hi Seb,
>
> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
>> OMAP5
>>
>> Signed-off-by: Sebastien Guiriec
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 42c78be..9e39f9f 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -104,6 +104,8 @@
>>
>> gpio1: gpio@4ae1 {
>> compatible = "ti,omap4-gpio";
>> +reg = <0x4ae1 0x200>;
>> +interrupts = <0 29 0x4>;
>> ti,hwmods = "gpio1";
>> gpio-controller;
>> #gpio-cells = <2>;
>
> I am wondering if we should add the "interrupt-parent" property to add
> nodes in the device-tree source. I know that today the interrupt-parent
> is being defined globally, but when device-tree maps an interrupt for a
> device it searches for the interrupt-parent starting the current device
> node.
>
> So in other words, for gpio1 it will search the gpio1 binding for
> "interrupt-parent" and if not found move up a level and search again. It
> will keep doing this until it finds the "interrupt-parent".
>
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.
That being said, it might be interesting to benchmark that to see what
is the real impact.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 05:59 PM, Jon Hunter wrote:
>
> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>> Hi Seb,
>>>
>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>>> Add base address and interrupt line inside Device Tree data for
>>>> OMAP5
>>>>
>>>> Signed-off-by: Sebastien Guiriec
>>>> ---
>>>> arch/arm/boot/dts/omap5.dtsi | 16
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>>> index 42c78be..9e39f9f 100644
>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>> @@ -104,6 +104,8 @@
>>>>
>>>>gpio1: gpio@4ae1 {
>>>>compatible = "ti,omap4-gpio";
>>>> + reg = <0x4ae1 0x200>;
>>>> + interrupts = <0 29 0x4>;
>>>>ti,hwmods = "gpio1";
>>>>gpio-controller;
>>>>#gpio-cells = <2>;
>>>
>>> I am wondering if we should add the "interrupt-parent" property to add
>>> nodes in the device-tree source. I know that today the interrupt-parent
>>> is being defined globally, but when device-tree maps an interrupt for a
>>> device it searches for the interrupt-parent starting the current device
>>> node.
>>>
>>> So in other words, for gpio1 it will search the gpio1 binding for
>>> "interrupt-parent" and if not found move up a level and search again. It
>>> will keep doing this until it finds the "interrupt-parent".
>>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent defined in each node.
>>
>> Mmm, I'm not that sure. it will increase the size of the blob, so
>> increase the time to load it and then to parse it. Where in the current
>> case, it is just going up to the parent node using the already
>> un-flatten tree in memory and thus that should not take that much time.
>
> Yes it will definitely increase the size, so that could slow things down.
>
>> That being said, it might be interesting to benchmark that to see what
>> is the real impact.
>
> Right, I wonder what the key functions are we need to benchmark to get
> an overall feel for what is best? Right now I am seeing some people add
> the interrupt-parent for device nodes and others not. Ideally we should
> be consistent, but at the same time it is probably something that we can
> easily sort out later. So not a big deal either way.
For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 06:15 PM, Sebastien Guiriec wrote:
> Hi Benoit and John,
>
> On 10/23/2012 06:07 PM, Benoit Cousson wrote:
>> On 10/23/2012 05:59 PM, Jon Hunter wrote:
>>>
>>> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>>>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>>>> Hi Seb,
>>>>>
>>>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>>>>> Add base address and interrupt line inside Device Tree data for
>>>>>> OMAP5
>>>>>>
>>>>>> Signed-off-by: Sebastien Guiriec
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap5.dtsi | 16
>>>>>> 1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>>> index 42c78be..9e39f9f 100644
>>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>>> @@ -104,6 +104,8 @@
>>>>>>
>>>>>> gpio1: gpio@4ae1 {
>>>>>> compatible = "ti,omap4-gpio";
>>>>>> +reg = <0x4ae1 0x200>;
>>>>>> +interrupts = <0 29 0x4>;
>>>>>> ti,hwmods = "gpio1";
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>
>>>>> I am wondering if we should add the "interrupt-parent" property to add
>>>>> nodes in the device-tree source. I know that today the
>>>>> interrupt-parent
>>>>> is being defined globally, but when device-tree maps an interrupt
>>>>> for a
>>>>> device it searches for the interrupt-parent starting the current
>>>>> device
>>>>> node.
>>>>>
>>>>> So in other words, for gpio1 it will search the gpio1 binding for
>>>>> "interrupt-parent" and if not found move up a level and search
>>>>> again. It
>>>>> will keep doing this until it finds the "interrupt-parent".
>>>>>
>>>>> Therefore, I believe it will improve search time and hence, boot
>>>>> time if
>>>>> we have interrupt-parent defined in each node.
>>>>
>>>> Mmm, I'm not that sure. it will increase the size of the blob, so
>>>> increase the time to load it and then to parse it. Where in the current
>>>> case, it is just going up to the parent node using the already
>>>> un-flatten tree in memory and thus that should not take that much time.
>>>
>>> Yes it will definitely increase the size, so that could slow things
>>> down.
>>>
>>>> That being said, it might be interesting to benchmark that to see what
>>>> is the real impact.
>>>
>>> Right, I wonder what the key functions are we need to benchmark to get
>>> an overall feel for what is best? Right now I am seeing some people add
>>> the interrupt-parent for device nodes and others not. Ideally we should
>>> be consistent, but at the same time it is probably something that we can
>>> easily sort out later. So not a big deal either way.
>>
>> For consistency, I'd rather not add it at all for the moment.
>> Later, when we will only support DT boot, people will start complaining
>> about the boot time increase and then we will start optimizing a little
>> bit :-)
>
> I just do it like that to be consistent with what is inside OMAP4 dtsi
> for those IPs (GPIO/UART/MMC/I2C). Now after checking Peter already add
> the interrupt-parent for all audio IPs (OMAP3/4/5). But here we need
> also interrupts name. So here we should try to be consistent.
>
> So I can send back the series for OMAP5 and update the OMAP4 with
> interrupts-parent = <&gic>
No, you should not, as explained previously. You'd better remove the one
already in audio IPs for consistency.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
Hi Seb, Sorry, I missed your previous email, your v2 was the right one. We do have a single INTC in every OMAP, there is no point to repeat the same data hundred times. The DTS are already big enough. On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: > Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the > address space > and interrupt line description inside dtsi file for OMAP5. This serie is > updating the > current OMAP5 IP with missing entry. > > It has been tested on OMAP5 with 3.7-audio-display feature tree. > - MMC is probing and functional > - TWL6041 probing (GPIO/I2C) > - booting (UART) > > Update since v1: > - Add Ack and review > - Fix up commit messages. > > Update since v2: > - Add interrupt-parent. I will take the previous one to avoid the duplication of attributes. On top of that I will remove the ones introduce in audio IPs for consistency on OMAP3/4/5 platforms. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
On 10/24/2012 11:27 AM, Sebastien Guiriec wrote: > Hi Benoit, > > On 10/24/2012 11:15 AM, Benoit Cousson wrote: >> Hi Seb, >> >> Sorry, I missed your previous email, your v2 was the right one. >> We do have a single INTC in every OMAP, there is no point to repeat the >> same data hundred times. >> The DTS are already big enough. > > So in such case we should send a series for audio IP interrupt-parent > removal for OMAP3/4/5 dtsi file in order to be coherent. Yes. AM33xx was as well using that in some other IPs. > Do you want me to do it? Thanks, but I've just done the patch, I'll sent it in a couple of minutes. Benoit > >> >> On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: >>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can >>> add the address space >>> and interrupt line description inside dtsi file for OMAP5. This serie >>> is updating the >>> current OMAP5 IP with missing entry. >>> >>> It has been tested on OMAP5 with 3.7-audio-display feature tree. >>> - MMC is probing and functional >>> - TWL6041 probing (GPIO/I2C) >>> - booting (UART) >>> >>> Update since v1: >>> - Add Ack and review >>> - Fix up commit messages. >>> >>> Update since v2: >>> - Add interrupt-parent. >> >> I will take the previous one to avoid the duplication of attributes. >> >> On top of that I will remove the ones introduce in audio IPs for >> consistency on OMAP3/4/5 platforms. >> >> Regards, >> Benoit >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dmitry, On 10/24/2012 06:14 PM, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: >> Hi, >> >> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote: >>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote: >>>> Hi Dimitry, >>>> >>>> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote: >>>>> Hi Sourav, >>>>> >>>>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: >>>>>> Adapt keypad to use pinctrl framework. >>>>>> >>>>>> Tested on omap4430 sdp with 3.7-rc1 kernel. >>>>> >>>>> I do not see anything in the driver that would directly use pinctrl. Is >>>>> there a better place to select default pin configuration; maybe when >>>>> instantiating platform device? >>>> >>>> Why? >>>> The devm_pinctrl_get_select_default is using the pinctrl. >>> >>> No, I guess we ihave different understanding of what "directly use" means. >>> This particular driver does directly use interrupts: it requests it and >>> performs some actions when interrupt arrives. Same goes for IO memory - >>> it gets requested, then we access it. With pinctrl we do not do anything >>> - we just ask another layer to configure it and that is it. >> >> this is true for almost anything we do: >> >> - we ask another layer to allocate memory for us >> - we ask another layer to call our ISR once the IRQ line is asserted >> - we ask another layer to handle the input events we just received >> - we ask another layer to transfer data through DMA for us >> - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. That's not really true. You select a pin mode and thanks to that you get the signal from an external pin that goes to your IP. And thanks to that the IP is doing what your are expecting it to do. Without that your IP will not get any input signal, which will make it a little bit useless, isn't it? >> and so on. This is just how abstractions work, we group common parts in >> a framework so that users don't need to know the details, but still need >> to tell the framework when to fiddle with those resources. >> >>> I have seen just in a few days 3 or 4 drivers having exactly the same >>> change - call to devm_pinctrl_get_select_default(), and I guess I will >>> receive the same patches for the rest of input drivers shortly. >>> This suggests that the operation is done at the wrong level. Do the >>> pin configuration as you parse DT data, the same way you set up i2c >>> devices registers in of_i2c.c, and leave the individual drivers that do >>> not care about specifics alone. >> >> Makes no sense to hide that from drivers. The idea here is that driver >> should know when it needs its pins to muxed correctly. > > The driver also needs memory controller to be initialized, gpio chip be > ready and registered, DMA subsystem ready, input core reade, etc, etc, > etc. You however do not have every driver explicitly initialize any of > that; you expect certain working environment to be already operable. The > driver does manage resources it controls, it has ultimate knowledge > about, pin configuration is normally is not it. We just need to know > that we wired/muxed properly, otherwise we won't work. So please let > parent layers deal with it. > >> 95% of the time >> it will be done during probe() but then again, so what ? >> >> doing that when parsing DT, or on bus notifiers is just plain wrong. >> Drivers should be required to handle all of their resources. > > All of _their_ resources, exactly. They do not own nor control pins so > they should not be bothered with them either. Look, when you see that > potentially _every_ driver in the system needs to set up the same object > that it doe snot use otherwise you should realize that individual driver > is not the proper place to do that. What your are missing as well in that case is the explicit dependency that this API is creating with the pinctrl driver that we are going to miss otherwise. Hence the following code. + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER) + return -EPROBE_DEFER; If the pinctrl is not already there you defer the probe until it is th
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi Kishon,
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
> Includes few minor fixes in dwc3-omap like populating the compatible
> string in a correct way, extracting the utmi-mode property properly and
> changing the index of get_irq since irq of core is removed from hwmod
> entry.
> Also updated the documentation with dwc3-omap device tree binding
> information.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/dwc3/dwc3-omap.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index b84ddf3..10aad46 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> struct resource *res;
> struct device *dev = &pdev->dev;
>
> - int size;
> int ret = -ENOMEM;
> int irq;
>
> - const u32 *utmi_mode;
> + u32 utmi_mode;
> u32 reg;
>
> void __iomem*base;
> @@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
>
> platform_set_drvdata(pdev, omap);
>
> - irq = platform_get_irq(pdev, 1);
> + irq = platform_get_irq(pdev, 0);
Cannot you use the name of the resource to avoid that kind of trick?
This is for that reason that we added the resource name in DTS :-)
> if (irq < 0) {
> dev_err(dev, "missing IRQ resource\n");
> return -EINVAL;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
Same here.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
> Used of_platform_populate() to populate dwc3 core platform_device
> from device tree data. Since now the allocation of unique device id is
> handled by of_*, removed the call to dwc3_get_device_id.
Just for my understanding: How are these devices organized exactly?
Do we have : omap_wrapper -> dwc3-omap -> dwc3-core ?
The DT binding is mentioning some wrapper, but I'm not sure where it
should be located.
Maybe you should add more documentation on that. Or maybe you do have a
other series to add that part?
Regards,
Benoit
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/dwc3/dwc3-omap.c | 50
> +-
> 1 file changed, 10 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index d51c69c..4aaeec4 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -133,7 +134,6 @@ struct dwc3_omap {
> /* device lock */
> spinlock_t lock;
>
> - struct platform_device *dwc3;
> struct platform_device *usb2_phy;
> struct platform_device *usb3_phy;
> struct device *dev;
> @@ -276,12 +276,10 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> struct dwc3_omap_data *pdata = pdev->dev.platform_data;
> struct device_node *node = pdev->dev.of_node;
>
> - struct platform_device *dwc3;
> struct dwc3_omap*omap;
> struct resource *res;
> struct device *dev = &pdev->dev;
>
> - int devid;
> int size;
> int ret = -ENOMEM;
> int irq;
> @@ -324,34 +322,19 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> - devid = dwc3_get_device_id();
> - if (devid < 0)
> - return -ENODEV;
> -
> - dwc3 = platform_device_alloc("dwc3", devid);
> - if (!dwc3) {
> - dev_err(dev, "couldn't allocate dwc3 device\n");
> - goto err1;
> - }
> -
> context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
> if (!context) {
> dev_err(dev, "couldn't allocate dwc3 context memory\n");
> - goto err2;
> + return -ENOMEM;
> }
>
> spin_lock_init(&omap->lock);
> - dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
>
> - dwc3->dev.parent = dev;
> - dwc3->dev.dma_mask = dev->dma_mask;
> - dwc3->dev.dma_parms = dev->dma_parms;
> omap->resource_size = resource_size(res);
> omap->context = context;
> omap->dev = dev;
> omap->irq = irq;
> omap->base = base;
> - omap->dwc3 = dwc3;
>
> reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
>
> @@ -396,7 +379,7 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> if (ret) {
> dev_err(dev, "failed to request IRQ #%d --> %d\n",
> omap->irq, ret);
> - goto err2;
> + return ret;
> }
>
> /* enable all IRQs */
> @@ -415,28 +398,16 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
>
> dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_1, reg);
>
> - ret = platform_device_add_resources(dwc3, pdev->resource,
> - pdev->num_resources);
> - if (ret) {
> - dev_err(dev, "couldn't add resources to dwc3 device\n");
> - goto err2;
> - }
> -
> - ret = platform_device_add(dwc3);
> - if (ret) {
> - dev_err(dev, "failed to register dwc3 device\n");
> - goto err2;
> + if (node) {
> + ret = of_platform_populate(node, NULL, NULL, dev);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to add create dwc3 core\n");
> + return ret;
> + }
> }
>
> return 0;
> -
> -err2:
> - platform_device_put(dwc3);
> -
> -err1:
> - dwc3_put_device_id(devid);
> -
> - return ret;
> }
>
> static int __devexit dwc3_omap_remove(struct platform_device *pdev)
> @@ -446,7 +417,6 @@ static int __devexit dwc3_omap_remove(struct
> platform_device *pdev)
> platform_device_unregister(omap->usb2_phy);
> platform_device_unregister(omap->usb3_phy);
>
> - dwc3_put_device_id(omap->dwc3->id);
> device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core);
>
> return 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-in
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
>
> Matt,
>
> Can you build SPI DT patch with DMA support on top of SPI DT patch
> I submitted [1]. With the patch [1] SPI can work on PIO mode.
> So we can have basic SPI support available in 3.8.
>
> Benoit,
> Can you accept the SPI DT patch [1]
Yes, I've just applied it in for_3.8/dts branch
> In case if you want I will resubmit a patch with subject line modified.
No, that's fine.
Thanks,
Benoit
>
> Current subject line
> arm/dts: AM33XX: Add SPI device tree data
>
> 1. https://patchwork.kernel.org/patch/1470661/
>
> Thanks
> Avinash
>
>>>
>>> Signed-off-by: Matt Porter
>>> ---
>>> arch/arm/boot/dts/am335x-bone.dts | 17 +++
>>> arch/arm/boot/dts/am335x-evm.dts |9
>>> arch/arm/boot/dts/am33xx.dtsi | 43
>>> +
>>> 3 files changed, 69 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>>> b/arch/arm/boot/dts/am335x-bone.dts
>>> index 5510979..23edfd8 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>> @@ -18,6 +18,17 @@
>>> reg = <0x8000 0x1000>; /* 256 MB */
>>> };
>>>
>>> + am3358_pinmux: pinmux@44e10800 {
>>> + spi1_pins: pinmux_spi1_pins {
>>> + pinctrl-single,pins = <
>>> + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
>>> OUTPUT_PULLUP | MODE3 */
>>> + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
>>> INPUT_PULLUP | MODE3 */
>>> + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
>>> OUTPUT_PULLUP | MODE3 */
>>> + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
>>> OUTPUT_PULLUP | MODE3 */
>>> + >;
>>> + };
>>> + };
>>> +
>>
>> Change to am33xx_pinmux.
>>
>>> ocp {
>>> uart1: serial@44e09000 {
>>> status = "okay";
>>> @@ -84,3 +95,9 @@
>>> &mmc1 {
>>> vmmc-supply = <&ldo3_reg>;
>>> };
>>> +
>>> +&spi1 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi1_pins>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>>> b/arch/arm/boot/dts/am335x-evm.dts
>>> index d63fce8..8d5f660 100644
>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>> @@ -124,3 +124,12 @@
>>> &mmc1 {
>>> vmmc-supply = <&vmmc_reg>;
>>> };
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> + spi-flash@0 {
>>> + compatible = "spansion,s25fl064k", "m25p80";
>>> + spi-max-frequency = <2400>;
>>> + reg = <0>;
>>> + };
>>> +};
>>
>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
>> profiles).
>> So can you drop this changes as if I understood correctly, am335x-evm.dts
>> will be
>> populated for devices present only on profile #0.
>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index 26a6af7..063ecea 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -40,6 +40,15 @@
>>> };
>>> };
>>>
>>> + am3358_pinmux: pinmux@44e10800 {
>>> + compatible = "pinctrl-single";
>>> + reg = <0x44e10800 0x0238>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-single,register-width = <32>;
>>> + pinctrl-single,function-mask = <0x7f>;
>>> + };
>>> +
>>
>> Pin ctrl support already submitted
>> http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
>>
>> Thanks
>> Avinash
>>
>>> /*
>>> * XXX: Use a flat representation of the AM33XX interconnect.
>>> * The real AM33XX interconnect network is quite complex.Since
>>> @@ -261,6 +270,40 @@
>>> status = "disabled";
>>> };
>>>
>>> + spi0: spi@4803 {
>>> + compatible = "ti,omap4-mcspi";
>>> + ti,hwmods = "spi0";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x4803 0x400>;
>>> + interrupt-parent = <&intc>;
>>> + interrupt = <65>;
>>> + dmas = <&edma 16
>>> + &edma 17
>>> + &edma 18
>>> + &edma 19>;
>>> + dma-names = "tx0", "rx0", "tx1", "rx1";
>>> + ti,spi-num-cs = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + spi1: spi@481a {
>>> + compatible = "ti,omap4-mcspi";
>>> + ti,hwmods = "spi1";
>>> + #address-cell
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On 10/31/2012 11:16 AM, Benoit Cousson wrote:
> Hi Avinash,
>
> On 10/30/2012 10:41 AM, Philip, Avinash wrote:
>> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
>>
>> Matt,
>>
>> Can you build SPI DT patch with DMA support on top of SPI DT patch
>> I submitted [1]. With the patch [1] SPI can work on PIO mode.
>> So we can have basic SPI support available in 3.8.
>>
>> Benoit,
>> Can you accept the SPI DT patch [1]
>
> Yes, I've just applied it in for_3.8/dts branch
Well, in fact I did not, it does not apply :-(
Can you rebase on top of the for_3.8/dts branch? I've just applied the
RTC patch on top that was OK.
Thanks,
Benoit
>
>> In case if you want I will resubmit a patch with subject line modified.
>
> No, that's fine.
>
> Thanks,
> Benoit
>
>>
>> Current subject line
>> arm/dts: AM33XX: Add SPI device tree data
>>
>> 1. https://patchwork.kernel.org/patch/1470661/
>>
>> Thanks
>> Avinash
>>
>>>>
>>>> Signed-off-by: Matt Porter
>>>> ---
>>>> arch/arm/boot/dts/am335x-bone.dts | 17 +++
>>>> arch/arm/boot/dts/am335x-evm.dts |9
>>>> arch/arm/boot/dts/am33xx.dtsi | 43
>>>> +
>>>> 3 files changed, 69 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>>>> b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 5510979..23edfd8 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>> @@ -18,6 +18,17 @@
>>>>reg = <0x8000 0x1000>; /* 256 MB */
>>>>};
>>>>
>>>> + am3358_pinmux: pinmux@44e10800 {
>>>> + spi1_pins: pinmux_spi1_pins {
>>>> + pinctrl-single,pins = <
>>>> + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
>>>> INPUT_PULLUP | MODE3 */
>>>> + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + >;
>>>> + };
>>>> + };
>>>> +
>>>
>>> Change to am33xx_pinmux.
>>>
>>>>ocp {
>>>>uart1: serial@44e09000 {
>>>>status = "okay";
>>>> @@ -84,3 +95,9 @@
>>>> &mmc1 {
>>>>vmmc-supply = <&ldo3_reg>;
>>>> };
>>>> +
>>>> +&spi1 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&spi1_pins>;
>>>> +};
>>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>>>> b/arch/arm/boot/dts/am335x-evm.dts
>>>> index d63fce8..8d5f660 100644
>>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>>> @@ -124,3 +124,12 @@
>>>> &mmc1 {
>>>>vmmc-supply = <&vmmc_reg>;
>>>> };
>>>> +
>>>> +&spi0 {
>>>> + status = "okay";
>>>> + spi-flash@0 {
>>>> + compatible = "spansion,s25fl064k", "m25p80";
>>>> + spi-max-frequency = <2400>;
>>>> + reg = <0>;
>>>> + };
>>>> +};
>>>
>>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
>>> profiles).
>>> So can you drop this changes as if I understood correctly, am335x-evm.dts
>>> will be
>>> populated for devices present only on profile #0.
>>>
>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>>> index 26a6af7..063ecea 100644
>>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>>> @@ -40,6 +40,15 @@
>>>>};
>>>>};
>>>>
>>>> + am3358_pinmux: pinmux@44e10800 {
>>>> +
Re: [PATCH v2] ARM: dts: am33xx: rtc node
Hi Afzal,
On 10/30/2012 10:34 AM, Afzal Mohammed wrote:
> Add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed
> ---
> Hi Benoit,
>
> This is based on your for_3.8/dts branch.
I've just applied it in the branch with a slight change in the subject.
Thanks,
Benoit
>
> This has been tested on Beagle Bone.
>
> Bindings along with driver changes for DT has been picked by Andrew
> Morton and is now present in linux-next.
>
> Regards
> Afzal
>
> v2
> 1. Remove interrupt parent in rtc node.
> 2. Modify subject as per new convention.
>
>
> arch/arm/boot/dts/am33xx.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 70d24b8..97a7bd3 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -291,5 +291,13 @@
> ti,hwmods = "timer7";
> ti,timer-pwm;
> };
> +
> + rtc@44e3e000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x44e3e000 0x1000>;
> + interrupts = <75
> + 76>;
> + ti,hwmods = "rtc";
> + };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> Tested-by: Matt Porter
> ---
Applied in for_3.8/dts
Thanks,
Benoit
> Changes since v2:
> - Commit message corrected.
> - Rebase on top of for_3.8/dts
>
> Changes since v1:
> - Corrected reg offset in reg DT entry.
>
> :100644 100644 97a7bd3... 6e04789... March/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 97a7bd3..6e04789 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -299,5 +299,29 @@
> 76>;
> ti,hwmods = "rtc";
> };
> +
> + spi0: spi@4803 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4803 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi0";
> + status = "disabled";
> + };
> +
> + spi1: spi@481a {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi1";
> + status = "disabled";
> + };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Panto, On 10/31/2012 07:09 PM, Tony Lindgren wrote: > * Pantelis Antoniou [121031 11:05]: >> Hi Tony, >> >> On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote: >> >>> * Pantelis Antoniou [121031 10:26]: It is painless to move the adapter DT devices to arch/arm/mach-omap2 However I got bit by the __init at omap_build_device family functions. If you don't remove it, crashes every time you instantiate a device at runtime, or you load the cape driver as a module. >>> >>> Hmm I think you misunderstood me. You only need to create the >>> platform_device under arch/arm/mach-omap2. The device creation >>> happens only at __init, so omap_build_device can stay as __init. >>> The driver itself should be under drivers. >>> >>> But is this bus on non-device-tree omaps? If not, just make it >>> device tree only. >>> >> >> I'm afraid that's not the case. The whole notion of capebus is that >> instantiation of the devices doesn't just happen early at the boot >> sequence. >> >> It is perfectly valid for a cape to be instantiated via loading >> a module, or by making an override by writing a sysfs file. >> >> When having the __init there, the function has been long removed >> and you get a crash by calling into the weeds. >> >> So the sequence is: >> >>Register the adapter driver. > > OK this is always there for the hardware, and done during > the __init and this one should have an omap_device.. > >> insmod bone-geiger-cape >> call omap_build_device >> >> Please look into the capebus patches for the details. > > ..but it seems that the devices connected to capebus should > not have anything to do with omap_device and hwmod? Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> Tested-by: Matt Porter
I've just realized the interrupt-parent was still there, so I removed both.
Please find below the updated version.
Regards,
Benoit
>From 9fd3c748aac9418cd377249ca463050783d2198f Mon Sep 17 00:00:00 2001
From: Philip, Avinash
Date: Wed, 31 Oct 2012 16:21:09 +0530
Subject: [PATCH] ARM: dts: AM33XX: Add SPI node
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash
Tested-by: Matt Porter
[b-cous...@ti.com: Remove interrupt-parent]
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/am33xx.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..5dfd682 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,27 @@
76>;
ti,hwmods = "rtc";
};
+
+ spi0: spi@4803 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4803 0x400>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+ };
+
+ spi1: spi@481a {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a 0x400>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM33XX: Add usbss node
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
> From: Ajay Kumar Gupta
>
> Device tree node for usbss on AM33XX. There are two musb
> controllers on am33xx platform so have port0-mode and
> port1-mode data.
>
> [af...@ti.com: reg & interrupt property addition]
>
> Signed-off-by: Ajay Kumar Gupta
> Signed-off-by: Santhapuri, Damodar
> Signed-off-by: Ravi Babu
> Signed-off-by: Afzal Mohammed
> ---
>
> Hi Benoit,
>
> This is based on your "for_3.8/dts" branch.
>
> This is made on top of "usb: musb: am335x support"
> (http://marc.info/?l=linux-omap&m=135187391904863&w=2)
> and has been tested on Beagle Bone.
That looks good to me, I just like to get an Ack from Felipe for the
accuracy of the data part.
Regards,
Benoit
>
> Regards
> Afzal
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 5dfd682..78340a5 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -321,5 +321,22 @@
> ti,hwmods = "spi1";
> status = "disabled";
> };
> +
> + usb_otg_hs@4740 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> + };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
> Add keypad data node in omap5-evm.
>
> Based on I2C support patch for omap5, which has been
> already posted as a different series.
>
> Tested on omap5430 evm with 3.7-rc1 kernel.
>
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
>
> Tested on omap5430 sdp with 3.7-rc1 kernel.
>
> Signed-off-by: Sourav Poddar
> ---
> arch/arm/boot/dts/omap5-evm.dts | 95
> +++
> 1 files changed, 95 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index c663eba..b812d6d 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -140,3 +140,98 @@
> &mcbsp3 {
> status = "disabled";
> };
> +
> +&i2c5 {
> + clock-frequency = <40>;
> +
> + smsc@38 {
> + compatible = "smscece1099";
> + reg = <0x38>;
> + clock = <0x13>;
What does that "clock" mean?
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: add AM33XX EDMA support
Hi Sebastian,
Is this patch different from that one:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92176.html
Lokesh just pointed me this patch because it was missing for the
SHAM/AES series from Mark Greer.
Bottom-line, I've just applied the original one along with a second one
that was adding EDMA in SPI.
Regards,
Benoit
On 23/08/2013 21:06, Sebastian Andrzej Siewior wrote:
From: Matt Porter
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
Signed-off-by: Sebastian Andrzej Siewior
---
Could someone please pick this up?
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: add AM33XX EDMA support
- minus all the TI emails which are not working anymore :-(
I've just sent my previous email too soon...
Now the patch is different :-) I'll take that one.
Thanks,
Benoit
On 26/08/2013 10:29, Sebastian Andrzej Siewior wrote:
From: Matt Porter
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
Signed-off-by: Sebastian Andrzej Siewior
---
Could someone please pick this up?
v1..v2:
- s/edma@/dma-controller@/
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};
+ edma: dma-controller@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Sebatian,
On 27/08/2013 15:02, Javier Martinez Canillas wrote:
[cc'ing Benoit Cousson (OMAP DT maintainer)]
On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
wrote:
On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb
("usb: musb: dsps: use proper child nodes") from the tree and
commit 63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and
device nodes") from the arm-soc tree.
I fixed it up (probably incorrectly - see below) and can carry the
fix as necessary (no action is required).
You added the OCP node back and the USB nodes as I had them which
should be fine.
How do we solve the conflict for the merge window? Is it possible for
the ARM-SOC tree to create a topic branch for this commit?
Greg: I do have a pending pull / patches [0] which also change the dts
nodes according to the latest feedback + enabling an additional USB
port in bone.
If you take this in I could update the nodes later (with the topic
branch merged) accordingly to the way it has been done in the ARM-SOC
tree - unless you have other preferences.
I think that the proper way to handle this is to split the patch-set
in two and merge all the OMAP DT related changes
(arch/arm/boot/dts/am*) through Benoit's tree and the USB changes
(drivers/usb/*) through Greg tree to prevent these kind of merge
conflicts.
Yes. DT patches are an endless source of merge conflicts if they are
merge throught different trees.
What was discussed with Olof and Arnd during Connect is that we should
avoid merging DT patches outside arm-soc tree to avoid that kind of
situation.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
+ Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:24 PM, Benoit Cousson wrote: Hi Sebatian, Hi Benoit, Yes. DT patches are an endless source of merge conflicts if they are merge throught different trees. Usually there are small conflicts because two people added / changed a node nearby. This patch turned the .dts file almost upside down. Yes, that's true. What was discussed with Olof and Arnd during Connect is that we should avoid merging DT patches outside arm-soc tree to avoid that kind of situation. I am aware of this now. However these changes belonged together because a) they belonged together and b) would break the driver until the .dts changes and driver code is in-sync. In future I am going to ask you for a topic branch so I can get my changes in one piece without breaking stuff in the middle. What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? Regards Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Olof, On 27/08/2013 18:12, Olof Johansson wrote: On Tue, Aug 27, 2013 at 05:25:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 05:01 PM, Kevin Hilman wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? Unfortunately, the next/dt branch of arm-soc is not necessarily stable so should *not* be merged. In fact none of the arm-soc branches should be considered stable. As was already mentioned, this should be split up into driver changes and DTS changes through arm-soc. They'll both merge for v3.12. But splitting will break the driver until .dts & code is in sync again. BTW, how did this patch get merged without a signoff/ack from the OMAP DT maintainer in the first place? Hmm, looks like Benoit was not copied nor was linux-omap or linux-arm-kernel copied in the original mails. Hmm. I had Benoit's okay [0] to do the change "as long as Felipe is fine with it". I indeed forgot to Cc Benoit on the dts changes. For the phy-rename Felipe pinged you and we did the topic-branch, here I forgot. No. Read that email again. What Benoit said was that if Felipe was fine with the change _HE_ would take it. Huge difference, and one that would have avoided this situation. The only way to solve these things in the future is to make the driver handle both the new and the old binding. Bindings are not supposed to change in incompatible ways any more, unless for special circumstances and/or when the old binding was completely broken. The only way forward here, since Greg runs a stable tree that he doesn't rebase, is for us to rebuild without the OMAP DT branch, and ask Benoit to take out the conflicting changes. Benoit, I know this is none of your fault, but would you mind preparing a new copy of the DT branch without the conflicting patches, and hold those to 3.13? I haven't looked to see how many those were. OK, I'll do that ASAP and check how many should be removed to avoid a conflict with usb-next. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Felipe On 27/08/2013 21:56, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 04:05 PM, Benoit Cousson wrote: On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Please be aware that I have no response so far regarding [0] from Greg. [0] http://www.spinics.net/lists/linux-usb/msg92595.html Nor will you, given that I am not the one to take these patches, Felipe is. I noticed now that you said "please route around Felipe", but sorry, no, I'm not going to do that unless there's a really good reason. Felipe seems to be around at the moment, please work with him on this. If you will still take a 'part2' pull request from me, I can send you urgent bugfixes by friday. If I have some time left, I can even try to get that sorted out by tomorrow. For 3.12 stuff, like "fixes", sure, I can take them this week, that should give us a week or so for linux-next testing, right? that's correct. I have most of them already queued up, let me just go over my linux-usb maildir again and make sure I got all the important stuff in. cheers, thanks for opening this 'window'. There are two patches in my DTS tree that conflict with the usb-next. I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) , as suggested by Olof, since it is the biggest source of conflict from my tree. The second one is easily fixable, and Stephen already did it, but it will be even better it you could take it in your tree. This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix reg property size). Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
On 29/08/2013 16:23, Felipe Balbi wrote: On Thu, Aug 29, 2013 at 12:06:32PM +0200, Benoit Cousson wrote: Hi Felipe On 27/08/2013 21:56, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 04:05 PM, Benoit Cousson wrote: On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Please be aware that I have no response so far regarding [0] from Greg. [0] http://www.spinics.net/lists/linux-usb/msg92595.html Nor will you, given that I am not the one to take these patches, Felipe is. I noticed now that you said "please route around Felipe", but sorry, no, I'm not going to do that unless there's a really good reason. Felipe seems to be around at the moment, please work with him on this. If you will still take a 'part2' pull request from me, I can send you urgent bugfixes by friday. If I have some time left, I can even try to get that sorted out by tomorrow. For 3.12 stuff, like "fixes", sure, I can take them this week, that should give us a week or so for linux-next testing, right? that's correct. I have most of them already queued up, let me just go over my linux-usb maildir again and make sure I got all the important stuff in. cheers, thanks for opening this 'window'. There are two patches in my DTS tree that conflict with the usb-next. I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) , as suggested by Olof, since it is the biggest source of conflict from my tree. The second one is easily fixable, and Stephen already did it, but it will be even better it you could take it in your tree. This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix reg property size). I'm done with Pull requests for Greg. If the conflict is easy to solve, what's the problem in having the conflict to start with ? Well, it is mainly the other one that is a pain to fix. Since I was about to send another pull-request, I was wondering if you'll be OK to take it. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb2_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 19 0>; /* gpio_147 */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb2_reset>;
+ reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
regulator-boot-on;
>>> +};
>>> +
>>> +ldo2_reg: ldo2 {
>>> +/* VDD_RTCIO */
>>> +/* LDO2 -> VDDSHV5, LDO2 also goes to
>>> CAN_PHY_3V3 */
>>> +regulator-name = "ldo2";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo3_reg: ldo3 {
>>> +/* VDDA_1V8_PHY */
>>> +regulator-name = "ldo3";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo9_reg: ldo9 {
>>> +/* VDD_RTC */
>>> +regulator-name = "ldo9";
>>> +regulator-min-microvolt = <105>;
>>> +regulator-max-microvolt = <105>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldoln_reg: ldoln {
>>> +/* VDDA_1V8_PLL */
>>> +regulator-name = "ldoln";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> + };
>>> +
>>> +ldousb_reg: ldousb {
>>> +/* VDDA_3V_USB: VDDA_USBHS33 */
>>> +regulator-name = "ldousb";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
Nit: Extra blank line not needed.
>>> +};
>>> +};
>>> +};
>>> };
Nit: You have an extra level on indentation not needed.
>>> &i2c2 {
>>>
>> Acked-by: Nishanth Menon
Beside the two minors nits, the patch looks good to me.
Since, you've been waiting for some time for it, I fixed it myself and pulled
it.
I even fixed the changelog... Lucky you :-)
You can check the updated version below.
Sorry for the delay.
Thanks,
Benoit
---
>From 3b8f02a2df475c7a48e12eb1911c014f8060b167 Mon Sep 17 00:00:00 2001
From: Keerthy
Date: Mon, 26 Aug 2013 11:06:51 +0530
Subject: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
Add DT nodes for TPS659038 PMIC on DRA7 boards.
It is based on top of:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.
Documentation:
- Documentation/devicetree/bindings/mfd/palmas.txt
- Documentation/devicetree/bindings/regulator/palmas-pmic.txt
Boot Tested on DRA7 d1 Board.
Signed-off-by: Keerthy
Acked-by: Nishanth Menon
[bcous...@baylibre.com: Fix indentation and changelog]
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/dra7-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ca5dab2..fbbe406 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,118 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ tps659038: tps659038@58 {
+ compatible = "ti,tps659038";
+ reg = <0x58>;
+
+ tps659038_pmic {
+ compatible = "ti,tps659038-pmic";
+
+ regulators {
+ smps123_reg: smps123 {
+ /* VDD_MPU */
+ regulator-name = "smps123";
+ regulator-min-microvolt = < 85>;
+ regulator-max-microvolt = <125>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ /* VDD_DSPEVE *
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming
consistent
Could you rebase it?
Thanks,
Benoit
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 15:58, Roger Quadros wrote:
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming consistent
Could you rebase it?
Looks like it was already applied before. Could you please skip that and use
the rest?
I've checked that the remaining patches apply fine on top of your for_3.13/dts
branch.
Indeed, it was already there :-)
Sorry for the noise.
Benoit
cheers,
-roger
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM33XX: add ethernet alias's for am33xx
Hi Dan, On 03/10/2013 01:39, Mugunthan V N wrote: On Wednesday 02 October 2013 12:58 PM, Dan Murphy wrote: Set the alias for ethernet0 and ethernet1 so that uBoot can set the MAC address appropriately. Currently uBoot cannot find the alias and there for does not set the MAC address. Signed-off-by: Dan Murphy Tested this with beagle bone black. Tested-by: Mugunthan V N Regards Mugunthan V N Thanks, pulled in my for_3.13/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/9] am33xx: dts: Fix AES interrupt number
On 30/09/2013 17:13, Joel Fernandes wrote: Signed-off-by: Joel Fernandes Even if this is obvious, a small changelog is always recommended. Thanks, Benoit --- arch/arm/boot/dts/am33xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 0daa1b2..d7be90a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -724,7 +724,7 @@ compatible = "ti,omap4-aes"; ti,hwmods = "aes"; reg = <0x5350 0xa0>; - interrupts = <102>; + interrupts = <103>; dmas = <&edma 6 &edma 5>; dma-names = "tx", "rx"; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
Hi Tony,
On 13/09/2013 17:27, Tony Lindgren wrote:
* Koen Kooi [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 0d95d54..bc8d1a2 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -113,6 +113,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
>;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins = <
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ >;
+ };
};
ocp {
Here you can now use just the defines to make it a bit shorter:
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
Considering that Koen has just disappeared for a 3 weeks honeymoon, I'll
fix the patch. GIT does complain about various trailing spaces and end
of file issue for this patch as well :-(
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes
Hi Koen, On 12/09/2013 20:35, Koen Kooi wrote: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 I've just applied it on top of Joel's one. Thanks, Benoit Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v3: Addressed Nishants nitpicks for commit messages Addressed Russ' comments about moving LDO3 for mmc1 out of the common dtsi Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernel&m=137889435710552&w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 1 - arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: add AM33XX EDMA support
Hi Joel,
On 31/08/2013 03:19, Joel Fernandes wrote:
Hi Benoit,
On 08/26/2013 03:36 AM, Benoit Cousson wrote:
- minus all the TI emails which are not working anymore :-(
I've just sent my previous email too soon...
Now the patch is different :-) I'll take that one.
Unfortunately this patch is still missing from your latest pull request:
Indeed, it was supposed to be applied on 3.13 only. It just came too
late for 3.12.
Regards,
Benoit
Subject "[GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2"
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
tags/for_3.12/dts_signed (commit 4843be165c10f9886c87eeb20acf19a3ddec6653)
Below is a scissor patch that cleanly applies on above branch.
Thanks,
-Joel
--->8
From: Matt Porter
Subject: [PATCH] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
v2 changes:
Drop DT entries that are non-hardware-description Joel Fernandes
Discussion in [1].
v3 changes: Changed node name from "edma: edma@" to "edma: dma-controller@"
by Sebastian Andrzej Siewior
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5996d63..f5869ed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -101,6 +101,18 @@
reg = <0x4820 0x1000>;
};
+ edma: dma-controller@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13
Hi Joel, Thanks for the repost. I'll applied that one now. Regards, Benoit On 10/09/2013 21:24, Joel Fernandes wrote: Here are last few patches required to add EDMA and MMC/SPI support for AM33xx. Now that all dependent DMA patches and fixes are in linux next or mainline, except for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and SPI support and this patch series enables it. These are originally Matt Porter's patches with changes to make it work with recent kernels, addition of irq, memory resources and enable other extra properties. These patches should cleanly apply on master branch after Koen's patch [2] for basic BBB DT support is applied. MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC support for BBB is intentionally not added due to custom fixes and other patches that are in Koen's tree and which will be separately submitted by him. [1] http://marc.info/?l=linux-omap&m=137883926226451&w=2 [2] http://comments.gmane.org/gmane.linux.kernel.stable/63648 Matt Porter (3): ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support ARM: dts: add AM33XX MMC support and documentation .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- arch/arm/boot/dts/am335x-bone.dts | 11 arch/arm/boot/dts/am335x-evm.dts | 7 +++ arch/arm/boot/dts/am335x-evmsk.dts | 7 +++ arch/arm/boot/dts/am33xx.dtsi | 60 ++ 5 files changed, 110 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] AM33XX crypto DTS patches
Hi Joel, n 05/10/2013 21:04, Joel Fernandes wrote: These patches are some minor fixups and changes to commit messages to the AM33XX crypto (aes, sham) patches with reference to the comments at: http://comments.gmane.org/gmane.linux.drivers.devicetree/45961 Joel Fernandes (1): ARM: dts: AM33XX: Fix AES interrupt number Mark A. Greer (2): ARM: dts: AM33XX: Add SHAM data and documentation ARM: dts: AM33XX: Add AES data and documentation .../devicetree/bindings/crypto/omap-aes.txt| 31 ++ .../devicetree/bindings/crypto/omap-sham.txt | 28 +++ arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-evm.dts | 8 ++ arch/arm/boot/dts/am335x-evmsk.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 19 + 6 files changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt I've just applied this series and the remaining ones from the previous version. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] arm/dts: AM33XX: Add reg and interrupt property for all nodes
Hi Vaihbav, On 08/27/2012 02:31 PM, Vaibhav Hiremath wrote: > This series is trivial patch-series and should be considered as > preparation for the future where we supposed to get rid of > hwmod dependency. > > 1/2: Converts all hex numbers to lowercase, fixing inconsistency > 2/2: Add reg and interrupt property to all device/module nodes inside > DTS files. > > Although currently hwmod overwrites resources, I have validated this > patch series by changing the omap_device layer to respect DT resources > and boot Tested on BeagleBone platform. > I will be submitting the changes for omap_device layer as well, still > needs to fix on certain things. > > Vaibhav Hiremath (2): > arm/dts: AM33XX: Convert all hex numbers to lower-case > arm/dts: AM33XX: Specify reg and interrupt property for all nodes > > arch/arm/boot/dts/am335x-bone.dts |2 +- > arch/arm/boot/dts/am335x-evm.dts |2 +- > arch/arm/boot/dts/am33xx.dtsi | 62 > +++-- > 3 files changed, 54 insertions(+), 12 deletions(-) I'll queue that along with the other DT stuff for 3.7. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: OMAP: hwmod: revise deassert sequence
Hi Omar,
On 08/22/2012 07:42 AM, Omar Ramirez Luna wrote:
> For a reset sequence to complete cleanly, a module needs its
> associated clocks to be enabled, otherwise the timeout check
> in prcm code can print a false failure (failed to hardreset)
> that occurs because the clocks aren't powered ON and the status
> bit checked can't transition without them.
>
> Signed-off-by: Omar Ramirez Luna
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index eaedc33..b65e021 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
> const char *name)
> {
> struct omap_hwmod_rst_info ohri;
> int ret = -EINVAL;
> + int hwsup = 0;
>
> if (!oh)
> return -EINVAL;
> @@ -1520,10 +1521,46 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
> const char *name)
> if (IS_ERR_VALUE(ret))
> return ret;
>
> + if (oh->clkdm) {
> + /*
> + * A clockdomain must be in SW_SUP otherwise reset
> + * might not be completed. The clockdomain can be set
> + * in HW_AUTO only when the module become ready.
> + */
> + hwsup = clkdm_in_hwsup(oh->clkdm);
> + ret = clkdm_hwmod_enable(oh->clkdm, oh);
> + if (ret) {>
> + WARN(1, "omap_hwmod: %s: could not enable clockdomain
> %s: %d\n",
> + oh->name, oh->clkdm->name, ret);
> + return ret;
> + }
> + }
> +
> + _enable_clocks(oh);
> + if (soc_ops.enable_module)
> + soc_ops.enable_module(oh);
> +
> ret = soc_ops.deassert_hardreset(oh, &ohri);
> +
> + if (soc_ops.disable_module)
> + soc_ops.disable_module(oh);
> + _disable_clocks(oh);
> +
> if (ret == -EBUSY)
> pr_warning("omap_hwmod: %s: failed to hardreset\n", oh->name);
>
> + if (!ret) {
> + /*
> + * Set the clockdomain to HW_AUTO, assuming that the
> + * previous state was HW_AUTO.
> + */
> + if (oh->clkdm && hwsup)
> + clkdm_allow_idle(oh->clkdm);
> + } else {
> + if (oh->clkdm)
> + clkdm_hwmod_disable(oh->clkdm, oh);
> + }
> +
> return ret;
> }
>
The sequence is good, I'm just a little bit concern about the
duplication of code compared to _enable sequence.
That being said, this is the consequence of removing the hardreset
sequence outside of the main _enable/_shutdown sequence.
So I'm not sure I have any better way of doing that :-(
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] OMAP: hwmod: fix hardreset handling
Hi Omar, On 09/03/2012 04:29 PM, Omar Ramirez Luna wrote: > On 22 August 2012 00:42, Omar Ramirez Luna wrote: >> From: Omar Ramirez Luna >> >> The patch to expose hwmod assert/deassert functions through omap_device >> has been accepted and queued for 3.7[1], however these two patches are >> needed to make the API functional. Hence a revised version is being sent >> according to previous comments: >> >> - ARM: OMAP: hwmod: revise deassert sequence >> Now it uses enable|disable_module to handle the configuration of the >> modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the >> one associated with ipu_mmu will be removed along with the iommu hwmod >> migration[2]. >> >> - ARM: OMAP: hwmod: partially un-reset hwmods might not be properly >> enabled >> More infomation added in the patch description[3]. >> >> [1] http://patchwork.kernel.org/patch/1266731/ >> [2] http://patchwork.kernel.org/patch/1201791/ >> [3] http://patchwork.kernel.org/patch/1201801/ >> >> Omar Ramirez Luna (2): >> ARM: OMAP: hwmod: partially un-reset hwmods might not be properly >> enabled >> ARM: OMAP: hwmod: revise deassert sequence >> >> arch/arm/mach-omap2/omap_hwmod.c | 74 >> ++ >> 1 file changed, 59 insertions(+), 15 deletions(-) > > Ping. Oops, sorry, I forgot your series. Beside the concern about the duplication of code, that looks good to me. I'll sync with Paul to see who will push that series. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
The following patch is hacing some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func__, res_count);
CHECK: Alignment should match open parenthesis
#171: FILE: arch/arm/plat-omap/omap_device.c:593:
+ memcpy(res, pdev->resource,
+ sizeof(struct resource) * pdev->num_resources);
CHECK: Alignment should match open parenthesis
#173: FILE: arch/arm/plat-omap/omap_device.c:595:
+ omap_device_fill_dma_resources(od,
+ &res[pdev->num_resources]);
CHECK: Alignment should match open parenthesis
#176: FILE: arch/arm/plat-omap/omap_device.c:598:
+ dev_dbg(&pdev->dev, "%s(): using resources from hwmod
%d\n",
+ __func__, res_count);
total: 0 errors, 0 warnings, 4 checks, 130 lines checked
Since I was in a nice mood, because the week-end is almost there, I fixed them
myself.
Please note that I had to rename the API becasue it was way too long to do a
proper alignement.
omap_device_fill_dma_resources -> _od_fill_dma_resources
In fact I realized that some private APIs should probably be renamed as well
like that for
consistency.
Just let me know if you have any issue with that version.
Regards,
Benoit
---
>From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath
Date: Wed, 29 Aug 2012 15:18:11 +0530
Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources allocated
by OF layer
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Kevin Hilman
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap_device.c | 71 +
3 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..7768804 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
}
/**
+ * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
+ * @oh: struct omap_hwmod *
+ * @res: pointer to the array of struct resource to fill
+ *
+ * Fill the struct resource array @res with dma resource data from the
+ * omap_hwmod @oh. Intended to be called by code that registers
+ * omap_devices. See also omap_hwmod_count_resources(). Returns the
+ * number of array elements filled.
+ */
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res)
+{
+ int i, sdma_reqs_cnt;
+ int r = 0;
+
+ sdma_reqs_cnt = _count_sdma_reqs(oh);
+ for (i = 0; i < sdma_reqs_cnt; i++) {
+ (res + r)->name = (oh->sdma_reqs + i)->name;
+ (res + r)->start = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->end = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->flags = IORESOURCE_DMA;
+ r++;
+ }
+
+ return r;
+}
+
+/**
* omap_hwmod_get_resource_byname - fetch IP block integration data by name
* @oh: struct omap_hwmod * to operate on
* @type: one of the IORESOURCE_* constants from include/linux/ioport.h
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6132972..5857b9c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
+int omap_hwm
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
The following patch is having some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func__, res_count);
CHECK: Alignment should match open parenthesis
#171: FILE: arch/arm/plat-omap/omap_device.c:593:
+ memcpy(res, pdev->resource,
+ sizeof(struct resource) * pdev->num_resources);
CHECK: Alignment should match open parenthesis
#173: FILE: arch/arm/plat-omap/omap_device.c:595:
+ omap_device_fill_dma_resources(od,
+ &res[pdev->num_resources]);
CHECK: Alignment should match open parenthesis
#176: FILE: arch/arm/plat-omap/omap_device.c:598:
+ dev_dbg(&pdev->dev, "%s(): using resources from hwmod
%d\n",
+ __func__, res_count);
total: 0 errors, 0 warnings, 4 checks, 130 lines checked
Since I was in a nice mood, because the week-end is almost there, I
fixed them myself.
Please note that I had to rename the API becasue it was way too long to
do a proper alignement.
omap_device_fill_dma_resources -> _od_fill_dma_resources
In fact I realized that some private APIs should probably be renamed as
well like that for
consistency.
Just let me know if you have any issue with that version.
Regards,
Benoit
---
>From b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath
Date: Wed, 29 Aug 2012 15:18:11 +0530
Subject: [PATCH] ARM: OMAP: omap_device: Do not overwrite resources
allocated by OF layer
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Kevin Hilman
[b-cous...@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap_device.c | 71
+
3 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..7768804 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3158,6 +3158,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod
*oh, struct resource *res)
}
/**
+ * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
+ * @oh: struct omap_hwmod *
+ * @res: pointer to the array of struct resource to fill
+ *
+ * Fill the struct resource array @res with dma resource data from the
+ * omap_hwmod @oh. Intended to be called by code that registers
+ * omap_devices. See also omap_hwmod_count_resources(). Returns the
+ * number of array elements filled.
+ */
+int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct
resource *res)
+{
+ int i, sdma_reqs_cnt;
+ int r = 0;
+
+ sdma_reqs_cnt = _count_sdma_reqs(oh);
+ for (i = 0; i < sdma_reqs_cnt; i++) {
+ (res + r)->name = (oh->sdma_reqs + i)->name;
+ (res + r)->start = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->end = (oh->sdma_reqs + i)->dma_req;
+ (res + r)->flags = IORESOURCE_DMA;
+ r++;
+ }
+
+ return r;
+}
+
+/**
* omap_hwmod_get_resource_byname - fetch IP block integration data by name
* @oh: struct omap_hwmod * to operate on
* @type: one of the IORESOURCE_* constants from include/linux/ioport.h
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6132972..5857b9c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
int omap_hwmod_count_resources(struct omap_hwmod *oh);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
+int omap_hwmod_fill
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi Felipe,
On 09/10/2012 05:58 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
>> * Felipe Balbi [120906 10:23]:
>>> Hi,
>>>
>>> On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
>>>>>
>>>>>
>>>>> On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
>>>>>> The mailbox register for usb otg in omap is present in control module.
>>>>>> On detection of any events VBUS or ID, this register should be written
>>>>>> to send the notification to musb core.
>>>>>>
>>>>>> Till we have a separate control module driver to write to control module,
>>>>>> omap2430 will handle the register writes to control module by itself. So
>>>>>> a new address space to represent this control module register is added
>>>>>> to usb_otg_hs.
>>>>>>
>>>>>> Cc: Benoit Cousson
>>>>>> Signed-off-by: Kishon Vijay Abraham I
>>>>>> ---
>>>>>> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
>>>>>> 1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> index 242aee4..02341bc 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>>>>> @@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
>>>>>> omap44xx_usb_otg_hs_addrs[] = {
>>>>>> .pa_end = 0x4a0ab003,
>>>>>> .flags = ADDR_TYPE_RT
>>>>>> },
>>>>>> +{
>>>>>> +.pa_start = 0x4a00233c,
>>>>>> +.pa_end = 0x4a00233f,
>>>>>> +.flags = ADDR_TYPE_RT
>>>>>> +},
>>>>>
>>>>> I do not have any objection/comment here, but I believe this is control
>>>>> module address space required for USB module, right?
>>>>> I am not sure this is right way of accessing control module space.
>>>>> Actually Control Module Access required for drivers is one of the
>>>>> blocking issue we have currently.
>>>>>
>>>>> Also there was some effort put up by 'Konstantine' to convert Control
>>>>> module to MFD driver, I haven't seen any further update on it. But it
>>>>> would be good to check with him.
>>>>
>>>> this was an agreement with Benoit since we already lost a couple merge
>>>> windows for this patchset. We agreed to wait until -rc4 for SCM driver
>>>> and if it wasn't ready, we'd go ahead with this and SCM author would fix
>>>> it up on a patch converting users to new SCM driver.
>>>
>>> Tony, can I get your Acked-by to this patch so I can take it together
>>> with the rest of the series ? Thanks
>>>
>>> ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
>>> to merge it into your tree once I apply.
>>
>> It would be best if this got acked by Benoit and Paul as they may
>> have some other patches queued up. I'll ack if they ack ;)
>
> Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
Then you sign the patch with your blood and that should be fine for me :-).
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
+ Tony
Hi Matt,
30 minutes too late for my pull request :-(
There are a couple of am33xx patches under discussion, so I'll take them
and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
On 09/10/2012 06:20 PM, Matt Porter wrote:
> On AM33xx, the datasheet and TRM refer to four GPIO instances that
> are 0-based, GPIO0-3.
Or maybe you should just update the spec to use a 1-based GPIO number
like OMAP :-)
Regards,
Benoit
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am33xx.dtsi |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..1369bfc 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -62,7 +62,7 @@
> reg = <0x4820 0x1000>;
> };
>
> - gpio1: gpio@44e07000 {
> + gpio0: gpio@44e07000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio1";
> gpio-controller;
> @@ -74,7 +74,7 @@
> interrupts = <96>;
> };
>
> - gpio2: gpio@4804c000 {
> + gpio1: gpio@4804c000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio2";
> gpio-controller;
> @@ -86,7 +86,7 @@
> interrupts = <98>;
> };
>
> - gpio3: gpio@481ac000 {
> + gpio2: gpio@481ac000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio3";
> gpio-controller;
> @@ -98,7 +98,7 @@
> interrupts = <32>;
> };
>
> - gpio4: gpio@481ae000 {
> + gpio3: gpio@481ae000 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio4";
> gpio-controller;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM33XX: fix gpio node numbering to match hardware
On 09/10/2012 06:52 PM, Matt Porter wrote:
> On Mon, Sep 10, 2012 at 06:34:20PM +0200, Benoit Cousson wrote:
>> + Tony
>>
>> Hi Matt,
>>
>> 30 minutes too late for my pull request :-(
>>
>> There are a couple of am33xx patches under discussion, so I'll take them
>> and send a for_3.7/dts-part2 pull request if this is not too late for Tony.
>
> Yeah, believe me, I did a faceplant when I saw your pull request come by
> at the same time I discovered this issue. ;) In particular, AnilKumar's
> user leds patch would need to be adjusted for this change. I can
> resubmit with the user leds dts changes adjusted as well if that
> discussion comes to a conclusion and his patches accepted.
Yeah, I was wondering if the gpios label were already used somewhere.
I've just added this patch on top of my current series.
So you or Anil should just post the missing patches whenever they'll be
available and accepted.
>> On 09/10/2012 06:20 PM, Matt Porter wrote:
>>> On AM33xx, the datasheet and TRM refer to four GPIO instances that
>>> are 0-based, GPIO0-3.
>>
>> Or maybe you should just update the spec to use a 1-based GPIO number
>> like OMAP :-)
>
> I am powerless here. :)
That's too bad :-(
Benoit
>
> -Matt
>
>>> Signed-off-by: Matt Porter
>>> ---
>>> arch/arm/boot/dts/am33xx.dtsi |8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index bb31bff..1369bfc 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -62,7 +62,7 @@
>>> reg = <0x4820 0x1000>;
>>> };
>>>
>>> - gpio1: gpio@44e07000 {
>>> + gpio0: gpio@44e07000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio1";
>>> gpio-controller;
>>> @@ -74,7 +74,7 @@
>>> interrupts = <96>;
>>> };
>>>
>>> - gpio2: gpio@4804c000 {
>>> + gpio1: gpio@4804c000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio2";
>>> gpio-controller;
>>> @@ -86,7 +86,7 @@
>>> interrupts = <98>;
>>> };
>>>
>>> - gpio3: gpio@481ac000 {
>>> + gpio2: gpio@481ac000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio3";
>>> gpio-controller;
>>> @@ -98,7 +98,7 @@
>>> interrupts = <32>;
>>> };
>>>
>>> - gpio4: gpio@481ae000 {
>>> + gpio3: gpio@481ae000 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio4";
>>> gpio-controller;
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote: > IGEP technology devices are TI OMAP3 SoC based industrial embedded > and computer-on-module boards. This patch-set adds initial device > tree support for these devices. > > The device tree allows to boot from an MMC/SD and are working all > the components that already have device tree support on OMAP3 SoCs: That's cool to have one more board DT converted. That series looks good to me, I just have a comment on the DT mux stuff. Regards, Benoit > > - MMC/SD > - UARTs > - GPIO LEDs > - TWL4030 codec audio > - pinmux/pinconf pinctrl > > Some peripheral are still not working such as Flash storage and > Ethernet but support for these will also be included once the > OMAP GPMC device tree binding patches hit mainline. > > This is a v2 of the patch-set that solves issues pointed out by > Enric Balletbo and it is composed of the following patches: > > [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices > [PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board > [PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module > > Best regards, > Javier > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote:
> Add a generic .dtsi device tree source file for the
> common characteristics across IGEP Technology devices.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Matthias Brugger
> ---
> arch/arm/boot/dts/omap3-igep.dtsi | 93
> +
> 1 files changed, 93 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
> b/arch/arm/boot/dts/omap3-igep.dtsi
> new file mode 100644
> index 000..a093bff
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -0,0 +1,93 @@
> +/*
> + * Device Tree Source for IGEP Technology devices
> + *
> + * Copyright (C) 2012 Javier Martinez Canillas
> + * Copyright (C) 2012 Enric Balletbo i Serra
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB */
> + };
> +
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "igep2";
> + ti,mcbsp = <&mcbsp2>;
> + ti,codec = <&twl_audio>;
> + };
> +};
> +
> +&omap3_pmx_core {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &mcbsp2_pins
> + >;
Tony made a comment to avoid associating these data inside the pmx_core
and instead do that in the dedicated device part.
> +
> + uart3_pins: pinmux_uart3_pins {
> + pinctrl-single,pins = <
> + 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
> + 0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
> + >;
> + };
> +
> + mcbsp2_pins: pinmux_mcbsp2_pins {
> + pinctrl-single,pins = <
> + 0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
> + >;
> + };
BTW, in this case, the UART3 does not seems to have any connection with
the pins settings. Sine your don't have it in the pmx_core you should
have it in side the UART3 node.
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
The rational is that, the mux will be done only if the driver is probed
and not unconditionally during pmx_core probe like it will be the case
otherwise.
Regards,
Benoit
> +};
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> +
> + vsim: regulator@10 {
> + compatible = "ti,twl4030-vsim";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <300>;
> + };
> +
> + twl_audio: audio {
> + compatible = "ti,twl4030-audio";
> + codec {
> + };
> + };
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + vmmc_aux-supply = <&vsim>;
> + bus-width = <8>;
> +};
> +
> +&mmc2 {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + status = "disabled";
> +};
> +
> +&twl_gpio {
> + ti,use-leds;
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
Hi Avinash,
This look good to me except the: status = "disabled".
The "disabled" should be reserved for variant that does not contain the IP.
Is it the case here?
Regards,
Benoit
On 09/18/2012 07:30 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> Tested-by: Matt Porter
> ---
> Changes since v1:
> - Corrected reg offset in reg DT entry.
>
> :100644 100644 ff3badb... 065fd54... March/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 25 +
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ff3badb..065fd54 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -219,5 +219,30 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + spi0: spi@4803 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4803 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi0";
> + status = "disabled";
> +
> + };
> +
> + spi1: spi@481a {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi1";
> + status = "disabled";
> + };
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
Hi Matt,
On 10/19/2012 01:30 PM, Matt Porter wrote:
> On Fri, Oct 19, 2012 at 10:24:15AM +0200, Benoit Cousson wrote:
>> Hi Avinash,
>>
>> This look good to me except the: status = "disabled".
>>
>> The "disabled" should be reserved for variant that does not contain the IP.
>> Is it the case here?
>
> http://comments.gmane.org/gmane.linux.drivers.devicetree/18968 is what
> I've been going by with the DTS support in the EDMA dmaengine series. It
> does make the most sense to only enable what you need in the
> .dts.
Thanks, I missed that thread. That being said, there is no real rational
:-)
It seems to be a preference more than anything else.
I'm curious now, why powerpc was not really using that approach?
I'd rather explicitly disable an IP than assuming than it is disabled by
default and then enabling it in the board file. But again it is just a
different view point, since at the end it will have the same effect.
If we really want the disabled state to be the default state, why is it
not disabled in the DT fmwk by default?
Regards,
Benoit
>
> -Matt
>
>> On 09/18/2012 07:30 AM, Philip, Avinash wrote:
>>> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
>>> as the driver) is reused from OMAP4.
>>>
>>> Signed-off-by: Philip, Avinash
>>> Tested-by: Matt Porter
>>> ---
>>> Changes since v1:
>>> - Corrected reg offset in reg DT entry.
>>>
>>> :100644 100644 ff3badb... 065fd54... M arch/arm/boot/dts/am33xx.dtsi
>>> arch/arm/boot/dts/am33xx.dtsi | 25 +
>>> 1 files changed, 25 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index ff3badb..065fd54 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -219,5 +219,30 @@
>>> interrupt-parent = <&intc>;
>>> interrupts = <91>;
>>> };
>>> +
>>> + spi0: spi@4803 {
>>> + compatible = "ti,omap4-mcspi";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x4803 0x400>;
>>> + interrupt-parent = <&intc>;
>>> + interrupt = <65>;
>>> + ti,spi-num-cs = <2>;
>>> + ti,hwmods = "spi0";
>>> + status = "disabled";
>>> +
>>> + };
>>> +
>>> + spi1: spi@481a {
>>> + compatible = "ti,omap4-mcspi";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x481a 0x400>;
>>> + interrupt-parent = <&intc>;
>>> + interrupt = <125>;
>>> + ti,spi-num-cs = <2>;
>>> + ti,hwmods = "spi1";
>>> + status = "disabled";
>>> + };
>>> };
>>> };
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
Hi Sourav,
On 10/22/2012 09:29 AM, Sourav Poddar wrote:
> Currently, omap4 keypad mux settings are done in the board file.
> Populate the mux settings in the dts file for the keypad to
> work via dt.
Have you changed the driver to handle properly the dependency with the
pinctrl and thus return EPROBE_DEFER if this is not ready?
Seb Guiriec has just sent a patch to do that for the omap-i2c driver
([PATCH] i2c: omap: adopt pinctrl support).
> Cc: Felipe Balbi
> Tested on omap4430 sdp with 3.7-rc1.
>
> Signed-off-by: Sourav Poddar
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 26 ++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5b7e04f..5efb059 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -194,6 +194,27 @@
> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
> | MODE0 */
> >;
> };
> +
> + keypad_pins: pinmux_keypad_pins {
> + pinctrl-single,pins = <
> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
Alway use lower case for hexa value.
> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + >;
> + };
> };
>
> &i2c1 {
> @@ -406,3 +427,8 @@
> &mcbsp3 {
> status = "disabled";
> };
> +
> +&keypad {
> +pinctrl-names = "default";
> +pinctrl-0 = <&keypad_pins>;
> +};
Otherwise that looks good.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
On 10/22/2012 10:23 AM, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 01:15 PM, Benoit Cousson wrote:
>> Hi Sourav,
>>
>> On 10/22/2012 09:29 AM, Sourav Poddar wrote:
>>> Currently, omap4 keypad mux settings are done in the board file.
>>> Populate the mux settings in the dts file for the keypad to
>>> work via dt.
>> Have you changed the driver to handle properly the dependency with the
>> pinctrl and thus return EPROBE_DEFER if this is not ready?
> I have send a patch[1] to the mailing list on the driver changes.
> http://www.spinics.net/lists/linux-omap/msg79985.html.
Yeah, sorry, I've just seen it :-(.
> Though, I see I have missed the following EPROBE_DEFER check..
Yes, indeed.
> + if (PTR_ERR(dev->pins) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> Will add for the above patch.
Thanks,
Benoit
>> Seb Guiriec has just sent a patch to do that for the omap-i2c driver
>> ([PATCH] i2c: omap: adopt pinctrl support).
>>
>>> Cc: Felipe Balbi
>>> Tested on omap4430 sdp with 3.7-rc1.
>>>
>>> Signed-off-by: Sourav Poddar
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 26 ++
>>> 1 files changed, 26 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5b7e04f..5efb059 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -194,6 +194,27 @@
>>> 0xbc 0x100/* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT |
>>> MODE0 */
>>> >;
>>> };
>>> +
>>> +keypad_pins: pinmux_keypad_pins {
>>> +pinctrl-single,pins = <
>>> +0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>> Alway use lower case for hexa value.
> Ok. Will fix and send a new version.
>>> +0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +>;
>>> +};
>>> };
>>> &i2c1 {
>>> @@ -406,3 +427,8 @@
>>> &mcbsp3 {
>>> status = "disabled";
>>> };
>>> +
>>> +&keypad {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <&keypad_pins>;
>>> +};
>> Otherwise that looks good.
>>
>> Thanks,
>> Benoit
> Thanks,
> Sourav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
> Hi Grant
>
> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
>
>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
>> wrote:
>
> [ snip ]
>>
>> g.
>
> Since we've started talking about longer term goals, and the versioning
> provision seems to stand, I hope we address how much the fragment versioning
> thing is similar to the way board revisions progress.
>
> If a versioning syntax is available then one could create a single DT
> file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = "ti,panda-version", "panda";
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
compatible-version = "ti,panda-version", "panda";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
"AFMR", "Line In";
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
&sound {
ti,model = "PandaBoardES";
compatible-version = "ti,panda-version", "panda-es";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
"AFMR", "Line In";
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/07/2012 12:02 PM, Pantelis Antoniou wrote:
> Hi Benoit,
>
> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
>
>> Hi Panto,
>>
>> On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
>>> Hi Grant
>>>
>>> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
>>>
>>>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
>>>> wrote:
>>>
>>> [ snip ]
>>>>
>>>> g.
>>>
>>> Since we've started talking about longer term goals, and the versioning
>>> provision seems to stand, I hope we address how much the fragment versioning
>>> thing is similar to the way board revisions progress.
>>>
>>> If a versioning syntax is available then one could create a single DT
>>> file for a bunch of 'almost' similar board and board revisions.
>>
>> I even think that the version issue is probably much more important for the
>> short term than the overlay aspect. Well at least as important. We start
>> having as well a bunch a panda board version with different HW setup.
>>
>> Having a single board-XXX.dts that will support all these versions is
>> probably the best approach to avoid choosing that from the bootloader.
>>
>> We need to figure out a format + mechanism compatible with the current
>> non-versioned format to allow filtering the nodes at runtime to keep only
>> the relevant one.
>>
>> Something that can find the driver that will provide the proper board
>> version or subsystem version or whatever like that:
>>
>> compatible-version = "ti,panda-version", "panda";
>>
>> Then at runtime we should create only the node with the correct match
>> between the driver version and the string version.
>>
>>
>
> This is exactly what we need. FWIW the capebus syntax is a little bit
> different.
>
>> /* regular panda audio routing */
>> sound: sound {
>> compatible = "ti,abe-twl6040";
>> ti,model = "PandaBoard";
>> compatible-version = "ti,panda-version", "panda";
>>
>> /* Audio routing */
>> ti,audio-routing =
>> "Headset Stereophone", "HSOL",
>> "Headset Stereophone", "HSOR",
>> "Ext Spk", "HFL",
>> "Ext Spk", "HFR",
>> "Line Out", "AUXL",
>> "Line Out", "AUXR",
>> "HSMIC", "Headset Mic",
>> "Headset Mic", "Headset Mic Bias",
>> "AFML", "Line In",
>> "AFMR", "Line In";
>> };
>>
>>
>> /* Audio routing is different between PandaBoard4430 and PandaBoardES */
>> &sound {
>> ti,model = "PandaBoardES";
>> compatible-version = "ti,panda-version", "panda-es";
>>
>> /* Audio routing */
>> ti,audio-routing =
>> "Headset Stereophone", "HSOL",
>> "Headset Stereophone", "HSOR",
>> "Ext Spk", "HFL",
>> "Ext Spk", "HFR",
>> "Line Out", "AUXL",
>> "Line Out", "AUXR",
>> "AFML", "Line In",
>> "AFMR", "Line In";
>> };
>>
>
> We use this syntax for capebus (totally non-standard of-course),
>
> sound: sound {
> compatible = "ti,abe-twl6040";
>
>
> model@0 {
> ti,model = "PandaBoard";
> ti,audio-routing =
> "Headset Stereophone", "HSOL",
> "Headset Stereophone", "HSOR",
> "Ext Spk", "HFL",
> "Ext Spk", "HFR",
> "Line Out", "AUXL",
> "Line Out", "AUXR",
> "HSMIC", "Headset Mic",
> "Headset Mic", "Headset Mic Bias",
> "AFML", "Line In",
> "AFMR", "Line In";
> };
>
> model@1 {
> ti
Re: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 02:01 PM, Felipe Balbi wrote: > Hi, > > +Sricharan who commited that > > On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: >> On 12/19/2012 11:45 AM, Luciano Coelho wrote: Well, we still haven't got the foggiest idea what the actual problem is beyond that it's probably related to the 32kHz clock in some way (unless it was one of the other reverts that coincidentally made a difference, but we don't know what they were) so it's unlikely that just randomly implementing clock support is going to fix anything immediately here. >>> >>> This is exactly what I had to revert (as I mentioned in the other email, >>> I had to revert the other patches otherwise compilation would break): >>> >>> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings" >>> e76ab829 "regulator: twl: Remove references to the twl4030 regulator" >>> 029dd3ce "regulator: twl: Remove another unused variable warning" >> >> Yeah. 32k clock is not provided by twl. >> >> As I said I need to take a look at CCF to see if it already there. If it is >> clock driver + mapping + patch for wl12xx should fix the issue you are >> facing. >> >>> Let me know if you need more info. >> >> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg >> added there: >> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. >> >> Which means that _essential_ clocks and pads are no longer configured. > > anything essential you can list ? Yeah, that u-boot version is just unusable at all with any mainline kernel, since we are still missing pads conf for every drivers. Regarding the 32k clock, I noticed as well that the OMAP4460 panda u-boot is the only one to enable it at boot time, and thus this is the only board that can probe the wilink chip properly as of today. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 32kHz clock removal causes problems omap_hsmmc
On 12/19/2012 02:58 PM, Luciano Coelho wrote: > On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: >> On 12/19/2012 02:01 PM, Felipe Balbi wrote: >>> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: >>>> BTW: have you happened to ubdate u-boot recently? There is a nice easter >>>> egg >>>> added there: >>>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. >>>> >>>> Which means that _essential_ clocks and pads are no longer configured. >>> >>> anything essential you can list ? >> >> Yeah, that u-boot version is just unusable at all with any mainline >> kernel, since we are still missing pads conf for every drivers. >> >> Regarding the 32k clock, I noticed as well that the OMAP4460 panda >> u-boot is the only one to enable it at boot time, and thus this is the >> only board that can probe the wilink chip properly as of today. > > Do you mean that with the latest mainline u-boot all boards will have > trouble except panda? I don't know since the u-boot mainline has never ever supported properly the SDP4430, I stopped wasting my time with that code a long time ago. But the braves who tried using the latest u-boot mainline code that does not configure anything anymore had some troubles... Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 4/6] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 06/18/2013 03:16 PM, Eduardo Valentin wrote:
Benoit
On 07-06-2013 16:46, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
Could you please have a look on patch 3 and 4 of this series? I have
changed this one accordingly to your recommendation on v2. If nothing
else, please let me know if they can still be queued for 3.11.
I've just applied both of them in my tree for 3.11. I'll send the pull
request to Tony tomorrow.
Regards,
Benoit
I would need to rebase patch 01 to refresh on top of the thermal tree.
Thanks.
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..ea97201 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
<0 55 0x4>;
ti,hwmods = "debugss";
};
+
+ bandgap {
+ reg = <0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18>;
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ gpios = <&gpio3 22 0>; /* tshut */
+ };
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb1_reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 30 0>; /* gpio_62 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
If this is the case, I don't think it should be represented as a regulator.
Regards,
Benoit
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb1_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio1 1 0>; /* gpio_1 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ reset-supply = <&hsusb1_reset>;
+ vcc-supply = <&hsusb1_power>;
+ /**
+* FIXME:
+* put the right clock phandle here when available
+* clocks = <&auxclk3>;
+* clock-names = "main_clk";
+*/
+ clock-frequency = <1920>;
+ };
};
&omap4_pmx_wkup {
@@ -83,6 +119,7 @@
&mcbsp1_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &hsusbb1_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -133,6 +170,23 @@
>;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins = <
+ 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+ 0x84 (PIN_OUTPUT | MUX_MODE4) /*
usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+ 0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+ 0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+ 0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+ 0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+ 0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+ 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+ 0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+ 0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+ 0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+ 0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+ >;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins = <
0xe2 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
@@ -283,3 +337,11 @@
mode = <3>;
power = <50>;
};
+
+&usbhshost {
+ port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: dts: AM33XX: Add PWMSS device tree nodes
Hi Sebastian, On 06/18/2013 08:36 AM, Sebastian Andrzej Siewior wrote: On 06/12/2013 06:40 PM, Felipe Balbi wrote: On Wed, Jun 12, 2013 at 06:10:32PM +0200, Sebastian Andrzej Siewior wrote: On 06/06/2013 03:52 PM, Sebastian Andrzej Siewior wrote: From: Philip Avinash Add PWMSS device tree nodes in relation with ECAP & EHRPWM DT nodes to AM33XX SoC family. Also populates device tree nodes for ECAP & EHRPWM by adding necessary properties like pwm-cells, base reg & set disabled as status. Can someone please grab #2 till #4? Paul took just #1 as far as I can tell. DTS should be Benoit Cousson So, Benoit. Would you please be so kind and pick up the dts pieces? That's done. Patches are available in git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to
abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my
point of view. pinctrl can handle pin configuration and this is what the
pbias is in the case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep
doing that :-)
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using
the regulator in the future for controlling a gpio line.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
> Add bandgap device DT entry for OMAP5 dtsi.
>
> Cc: "Benoît Cousson"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-o...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> Signed-off-by: J Keerthy
> ---
> arch/arm/boot/dts/omap5.dtsi | 8
> 1 file changed, 8 insertions(+)
> ---
>
> Benoit,
>
> Sorry for this very late request, but can you please consider
> these patches for 3.11 still?
>
> I completely forgot to send these on my "Enable TI SoC thermal driver" series.
>
> All best,
>
> Eduardo
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 2ad63c4..5ede6e1 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -615,5 +615,13 @@
> interrupts = <0 80 0x4>;
> ti,hwmods = "wd_timer2";
> };
missing blank line
> + bandgap {
You must use the first address in that case. Otherwise DT will affect a random
number and provide a non-standard device name. That does not really matter in
theory, but it will looks ugly in the /sys/devices list.
> + reg = <0x4a0021e0 0xc
> + 0x4a00232c 0xc
> + 0x4a002380 0x2c
> + 0x4a0023C0 0x3c>;
> + interrupts = <0 126 4>; /* talert */
Not well aligned and should use the macros.
> + compatible = "ti,omap5430-bandgap";
> + };
> };
> };
>
I did the update for you :-)
Here is the version I've just applied.
Benoit
>From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren
Cc: Russell King
Signed-off-by: Eduardo Valentin
Signed-off-by: J Keerthy
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = ;
};
};
+
+ bandgap@4a0021e0 {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c>;
+ interrupts = ;
+ compatible = "ti,omap5430-bandgap";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM43x EPOS EVM support
Hi Afzal,
On 06/14/2013 09:03 AM, Afzal Mohammed wrote:
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get
it booting. Also include it in omap2plus dtbs and document bindings.
The hardware is under development.
Signed-off-by: Afzal Mohammed
---
Hi Benoit,
This is based on your for_3.11/dts branch.
Ideally I wanted to split this into 3 patches - first doc, second dts
and last adding build support. As changes in total is trivial, it was
made a single one.
That's fine for me. I've just applied it.
Thanks,
Benoit
Regards
Afzal
Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43x-epos-evm.dts| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
+
+- AM43x EPOS EVM
+ compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..05da469 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -155,7 +155,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
- am3517_mt_ventoux.dtb
+ am3517_mt_ventoux.dtb \
+ am43x-epos-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
new file mode 100644
index 000..74174d4
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+
+/* AM43x EPOS EVM */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+
+/ {
+ model = "TI AM43x EPOS EVM";
+ compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 06:03 AM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
Well, at that time, it was not available either. The point is still that
using a existing fmwk that has nothing to do with the signal you need to
handle just because it works is not a very good justification.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
Maybe, but it is not the right thing to do.
Can you explain me the commonality between a reset line and a regulator???
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my point of
view. pinctrl can handle pin configuration and this is what the pbias is in the
case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep doing
that :-)
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
Well, I don't think so. Again, you are abusing the regulator fmwk to
enable at boot time a GPIO line that should reset the IP. I doubt the
regulator fmwk was done for that. Otherwise Mark would have named it
"miscellaneous fmwk" or "regulator & reset" fmwk.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
regulator in the future for controlling a gpio line.
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
Yes, it will. It will give explicitly the reset control to the driver
that knows and needs it. Moreover, it will avoid abusing a fmwk that was
not done for that purpose.
Regards,
Benoit
--
To unsubscribe from this list: send the line &quo
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator
was not the right fmwk to do that :-)
Thanks for the pointer Florian.
I guess that series should be merged for 3.11? Based on the thread, it
should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding
that a new solution will be available soon as a disclaimer.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, sounds good.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = "regulator-fixed";
+regulator-name = "hsusb1_reset";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+gpio = <&gpio2 30 0>;/* gpio_62 */
+startup-delay-us = <7>;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, I've just done it myself while applying your series.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
On 05/29/2013 11:58 AM, Mohammed, Afzal wrote: > Hi Benoit, > > On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote: >> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: >>> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: > > If you are adding more compatibility strings, then this implies that the > AM43x timers are not 100% compatible with any other device listed (such > as am335x or any omap device). That's fine but you should state that in > the changelog. If the AM43x timer registers are 100% compatible with > existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. >>> >>> Stephen took words out of my finger ;) >>> >>> Some explanations,I don;t >>> >>> 1. first compatible should be exact device [A], followed by compatible >>> model (if one) >>> 2. Minor effort in getting DT right the first time may help prevent >>> difficult effort later modifying it (if a necessity comes), considering >>> the fact that DT sources has to move out of Kernel at some point of >>> time. And DT is not supposed to be modified, which may cause difficulty >>> for the users (I had been a minor victim of this during rebase). >>> >>> As we both were in GPMC land earlier, an example, >>> >>> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip >>> select, but one is not pinned out. Now assume that same IP is integrated >>> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible >>> for both, driver cannot handle it properly (w/o knowledge about platform). >>> But if exact compatible is mentioned, without modifying DT (which should >>> be considered as a firmware) just by modifying Kernel, deciding based on >>> compatible would help achieve what is required. >> >> That's true for the DTS itself, but here your are changing the binding >> documentation which is supposed to reflect the driver "interface" in the >> Device Tree model description. >> >> Since the driver does not support any new compatible string, you should >> not update the binding. > > I have a different opinion: Binding documentation is to be considered an > entity that is not a part of the Kernel, but currently is a part of the > Kernel for want of a better place. And binding is to be considered OS > agnostic being ignorant of any piece of software (driver here). OK, that part is correct, but instead of driver I should have said HW device. The binding is supposed to identify a specific HW device revision or family if some HW registers are there to identify the version. > Binding has the authority to allow its usage in DT sources. And in this case, you do not introduce any new revision. There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP. I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing. The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings. >> The driver and the binding will have to be changed the day you will have >> to update the driver to handle a bug / feature specific to that revision >> (ti,am4372-timer). >> >> Since this series does not seems to update the driver, you should not >> update the bindings. > > I believe that updating binding is a prerequisite for making a new > DTS change, hence binding was updated first, then DTS. I don't think so, as soon as you still use at least one documented compatible binding in the DTS description. It is not anyway really armless, it just adds much more confusion that real useful information for my point of view. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
Hi Pekon,
On 05/20/2013 06:44 AM, Gupta, Pekon wrote:
>
>
> am33xx_pinmux: pinmux@44e10800 {
> pinctrl-names = "default";
> - pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
> + pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0
> + &nandflash_pins_s0>;
Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.
>>>
>>> Yes we should have all the pinctrl entries under the related drivers.
>>> This makes it easy remux pins during runtime if needed, and also
>>> allows unloading pinctrl-single.ko for development.
>>>
>> Yes, accepted. This has been already fixed in v3 of this patch set.
>> If all fine, then please pull this for next merge..
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046712.html
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046814.html
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2013-May/046710.html
>>
>>
>> with regards, pekon
>
> Request you to please accept | provide feedbacks on this patch series.
> These are waiting acceptance since Jan-2013, and are necessary for
> DT based configs for board having NAND support.
>
> with regards, pekon
Sorry, I missed that series.
I'm applying it right now.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
On 05/30/2013 09:31 AM, Gupta, Pekon wrote: >> Sorry, I missed that series. >> >> I'm applying it right now. >> > No issues.. Please pick newer v4 versions of this series. > Following are rebased, updated and tested on linux-3.10-rc3 > > [PATCH v4,0/3] http://www.spinics.net/lists/linux-omap/msg91165.html > > [PATCH v4,1/3] http://www.spinics.net/lists/linux-omap/msg91166.html > > [PATCH v4,2/3] (please skip this one) > instead pick http://www.spinics.net/lists/linux-omap/msg91161.html > > [PATCH v4,3/3] http://www.spinics.net/lists/linux-omap/msg91167.html Could you please rebase on for_3.11/dts and repost the whole stuff. It looks like Tony already pulled the GPMC node, and the two other ones cannot apply anymore. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Stephen, On 05/29/2013 05:27 PM, Stephen Warren wrote: > On 05/29/2013 02:39 AM, Benoit Cousson wrote: >> Hi Afzal, >> >> On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: >>> Hi Jon, >>> >>> On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: >>>> On 05/28/2013 03:25 PM, Jon Hunter wrote: >>> >>>>>> ti,am335x-timer (applicable to AM335x devices) >>>>>> ti,am335x-timer-1ms (applicable to AM335x >>>>>> devices) >>>>>> +"ti,am4372-timer-1ms", "ti,am335x-timer-1ms" >>>>>> for AM43x 1ms timer >>>>>> +"ti,am4372-timer", "ti,am335x-timer" for AM43x >>>>>> timers other than 1ms one >>> >>>>> If you are adding more compatibility strings, then this implies that the >>>>> AM43x timers are not 100% compatible with any other device listed (such >>>>> as am335x or any omap device). That's fine but you should state that in >>>>> the changelog. If the AM43x timer registers are 100% compatible with >>>>> existing devices you should not add these. >>>> >>>> I'm not sure that's true; .dts files should always include a compatible >>>> value that describes the most specific model of the HW, plus any >>>> baseline compatible value that the HW is compatible with. This allows >>>> any required quirks/fixes/... to be applied for the specific HW model >>>> later even if nobody knows right now they'll be needed. Hence, defining >>>> new compatible values doesn't necessarily mean incompatible HW. >>> >>> Stephen took words out of my finger ;) >>> >>> Some explanations,I don;t >>> >>> 1. first compatible should be exact device [A], followed by compatible >>> model (if one) >>> 2. Minor effort in getting DT right the first time may help prevent >>> difficult effort later modifying it (if a necessity comes), considering >>> the fact that DT sources has to move out of Kernel at some point of >>> time. And DT is not supposed to be modified, which may cause difficulty >>> for the users (I had been a minor victim of this during rebase). >>> >>> As we both were in GPMC land earlier, an example, >>> >>> If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip >>> select, but one is not pinned out. Now assume that same IP is integrated >>> in another SoC (probably OMAP4 has rev 6). Here if we use same compatible >>> for both, driver cannot handle it properly (w/o knowledge about platform). >>> But if exact compatible is mentioned, without modifying DT (which should >>> be considered as a firmware) just by modifying Kernel, deciding based on >>> compatible would help achieve what is required. >> >> That's true for the DTS itself, but here your are changing the binding >> documentation which is supposed to reflect the driver "interface" in the >> Device Tree model description. >> >> Since the driver does not support any new compatible string, you should >> not update the binding. > > I don't agree here; the DT binding should define all the required and/or > allowed values that must/should/can be present in the DT - the entire > legal schema. The set of all compatible values is included in that, > irrespective of whether a particular value actually (currently) defines > a different HW interface or not. Well, I tend to agree on the principle, but so far it was never really done like that. That's not necessarily a good excuse, but if we start adding new bindings for the huge number of OMAP|AM variants TI has been introduced for 10 years, I'd rather use a wildcard than a exhaustive list of all the devices. Something like ti,[omap|am]*-timer for example . Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 05/29/2013 01:20 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> A1-A3 = gpio_wk7clean
> ES = gpio_110
>
> There is no change to LED D2
>
> Abstract away the pinmux and the LED definitions for the two boards into
> the respective DTS files.
>
> Signed-off-by: Dan Murphy
That patch was good... until Florian introduces some new constant to
improve the readability of the DTS [1].
Could you rebase on the lastest for_3.11/dts and use the macros for the
GPIO and pinctrl nodes?
Thanks,
Benoit
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89684.html
> ---
> v7 - Update headline to add spaces -
> https://patchwork.kernel.org/patch/2583661/
> v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
> v5 - Provide pincrtl phandle to the gpio-led driver -
> https://patchwork.kernel.org/patch/2573981/
>
> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
> arch/arm/boot/dts/omap4-panda-es.dts | 28
> 2 files changed, 43 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..5fd59b3 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -16,8 +16,13 @@
> reg = <0x8000 0x4000>; /* 1 GB */
> };
>
> - leds {
> + leds: leds {
> compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &led_wkgpio_pins
> + >;
> +
> heartbeat {
> label = "pandaboard::status1";
> gpios = <&gpio1 7 0>;
> @@ -137,6 +142,15 @@
> };
> };
>
> +&omap4_pmx_wkup {
> + led_wkgpio_pins: pinmux_leds_wkpins {
> + pinctrl-single,pins = <
> + 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
> + >;
> + };
> +};
> +
> &i2c1 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index f1d8c21..c968a3b 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,3 +34,31 @@
> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
> >;
> };
> +
> +&omap4_pmx_core {
> + led_gpio_pins: gpio_led_pmx {
> + pinctrl-single,pins = <
> + 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
> + >;
> + };
> +};
> +
> +&led_wkgpio_pins {
> + pinctrl-single,pins = <
> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
> + >;
> +};
> +
> +&leds {
> + pinctrl-0 = <
> + &led_gpio_pins
> + &led_wkgpio_pins
> + >;
> +
> + heartbeat {
> + gpios = <&gpio4 14 0>;
> + };
> + mmc {
> + gpios = <&gpio1 8 0>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Afzal, On 06/03/2013 09:49 AM, Mohammed, Afzal wrote: > Hi Benoit, > > On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote: > >> And in this case, you do not introduce any new revision. >> >> There is no point to update the binding each time we add a new SoC >> variant that will contain the exact same IP. >> >> I think it will mainly confuse the user that will wonder what is >> different in that version compare to the previous one, moreover we can >> end up with hundred of entries for the exact same IP for nothing. >> >> The real problem is due to the introduction of the SoC name in the >> device compatible name. That does introduced a SoC level information >> that is mostly irrelevant at device level. I can understand why it was >> done for practical aspect when the IP version is not well identified, >> but that can lead to this proliferation of new pointless bindings. > > As opinions on $subject seems not yet to be conclusive, I plan to > rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes > use of C preprocessor on OMAP DTS) and post separately dropping > 11-14 patches, is that okay ? Yes, that sounds good to me. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: dts: AM43x: initial support
On 06/03/2013 03:19 PM, Afzal Mohammed wrote:
> DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
> represented here are the minimal DT nodes necessary to get kernel
> booting.
>
> In DT nodes, "ti,hwmod" property has not been added, this would be
> added along with PRCM support for AM43x.
>
> Signed-off-by: Ankur Kishore
> Signed-off-by: Afzal Mohammed
Thanks Afzal. I've just applied it in my branch.
Regards,
Benoit
> ---
>
> v3: Make use of C preprocessor, rebased over Benoit's 'for_3.11/dts' branch
> v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
>
> arch/arm/boot/dts/am4372.dtsi | 68
> +++
> 1 file changed, 68 insertions(+)
> create mode 100644 arch/arm/boot/dts/am4372.dtsi
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> new file mode 100644
> index 000..ddc1df7
> --- /dev/null
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -0,0 +1,68 @@
> +/*
> + * Device Tree Source for AM4372 SoC
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "ti,am4372", "ti,am43";
> + interrupt-parent = <&gic>;
> +
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + cpus {
> + cpu@0 {
> + compatible = "arm,cortex-a9";
> + };
> + };
> +
> + gic: interrupt-controller@48241000 {
> + compatible = "arm,cortex-a9-gic";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0x48241000 0x1000>,
> + <0x48240100 0x0100>;
> + };
> +
> + ocp {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + uart0: serial@44e09000 {
> + compatible = "ti,am4372-uart","ti,omap2-uart";
> + reg = <0x44e09000 0x2000>;
> + interrupts = ;
> + };
> +
> + timer1: timer@44e31000 {
> + compatible =
> "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
> + reg = <0x44e31000 0x400>;
> + interrupts = ;
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> + compatible = "ti,am4372-timer","ti,am335x-timer";
> + reg = <0x4804 0x400>;
> + interrupts = ;
> + };
> +
> + counter32k: counter@44e86000 {
> + compatible =
> "ti,am4372-counter32k","ti,omap-counter32k";
> + reg = <0x44e86000 0x40>;
> + };
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/2] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 05/31/2013 05:44 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> A1-A3 = gpio_wk7
> ES = gpio_110
>
> There is no change to LED D2
>
> Abstract away the pinmux and the LED definitions for the two boards into
> the respective DTS files.
>
> Signed-off-by: Dan Murphy
Thanks, I've just applied it in my branch.
Regards,
Benoit
> ---
> v10 - Update gpio entries to use gpio macros -
> https://patchwork.kernel.org/patch/2644561/
> v9 - Removed comments for mux config -
> https://patchwork.kernel.org/patch/2644391/
> v8 - Rebase to latest and use pinctrl macros -
> https://patchwork.kernel.org/patch/2629351/
> v7 - Update headline to add spaces -
> https://patchwork.kernel.org/patch/2583661/
> v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
> v5 - Provide pincrtl phandle to the gpio-led driver -
> https://patchwork.kernel.org/patch/2573981/
> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
> arch/arm/boot/dts/omap4-panda-es.dts | 28
> 2 files changed, 43 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index d5d144a..800fa4e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -16,8 +16,13 @@
> reg = <0x8000 0x4000>; /* 1 GB */
> };
>
> - leds {
> + leds: leds {
> compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &led_wkgpio_pins
> + >;
> +
> heartbeat {
> label = "pandaboard::status1";
> gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> @@ -157,6 +162,15 @@
> };
> };
>
> +&omap4_pmx_wkup {
> + led_wkgpio_pins: pinmux_leds_wkpins {
> + pinctrl-single,pins = <
> + 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
> + 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
> + >;
> + };
> +};
> +
> &i2c1 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 5cfdf19..56c4354 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,3 +34,31 @@
> 0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
> >;
> };
> +
> +&omap4_pmx_core {
> + led_gpio_pins: gpio_led_pmx {
> + pinctrl-single,pins = <
> + 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
> + >;
> + };
> +};
> +
> +&led_wkgpio_pins {
> + pinctrl-single,pins = <
> + 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
> + >;
> +};
> +
> +&leds {
> + pinctrl-0 = <
> + &led_gpio_pins
> + &led_wkgpio_pins
> + >;
> +
> + heartbeat {
> + gpios = <&gpio4 14 GPIO_ACTIVE_HIGH>;
> + };
> + mmc {
> + gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition
Hi Dan, On 05/31/2013 06:12 PM, Florian Vaussard wrote: > Hello Dan, > > On 05/31/2013 05:45 PM, Dan Murphy wrote: >> Update the dt property ti,audpwron-gpio to use the >> gpio macro definition for GPIO_ACTIVE_HIGH. >> >> Signed-off-by: Dan Murphy >> --- >> arch/arm/boot/dts/omap4-panda-common.dtsi |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi >> b/arch/arm/boot/dts/omap4-panda-common.dtsi >> index 800fa4e..00cbaa5 100644 >> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi >> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi >> @@ -190,7 +190,7 @@ >> /* IRQ# = 119 */ >> interrupts = ; /* >> IRQ_SYS_2N cascaded to gic */ >> interrupt-parent = <&gic>; >> -ti,audpwron-gpio = <&gpio4 31 0>; /* gpio line 127 */ >> +ti,audpwron-gpio = <&gpio4 31 GPIO_ACTIVE_HIGH>; /* gpio >> line 127 */ >> >> vio-supply = <&v1v8>; >> v2v1-supply = <&v2v1>; >> > > I missed it during the conversion, thank you. > > Reviewed-by: Florian Vaussard I've just applied it with Florian's Reviewed-by. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Hi Tony, On 06/24/2013 12:19 PM, Tony Lindgren wrote: > Hi, > > For merging this series, I suggest the following sets: > > * Joel A Fernandes [130620 14:13]: >> >> Joel A Fernandes (3): >> edma: config: Enable config options for EDMA >> da8xx: config: Enable MMC and FS options >> ARM: davinci: Fix compiler warnings in devices-da8xx >> >> Matt Porter (8): >> dmaengine: edma: Add TI EDMA device tree binding >> ARM: edma: Add DT and runtime PM support to the private EDMA API >> ARM: edma: Add EDMA crossbar event mux support >> dmaengine: edma: enable build for AM33XX > > Sekhar should queue the above patches, I've acked the > mach-omap2/Kconfig change. > >> spi: omap2-mcspi: add generic DMA request support to the DT binding >> spi: omap2-mcspi: convert to dma_request_slave_channel_compat() > > > The spi changes should get merged via the driver list. > >> ARM: dts: add AM33XX EDMA support >> ARM: dts: add AM33XX SPI DMA support > > Benoit should queue the .dts changes. I'll do that, but do you consider them for 3.11? Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
