Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
* Eliad Peller el...@wizery.com [150310 10:01]: On Tue, Mar 10, 2015 at 6:18 PM, Tony Lindgren t...@atomide.com wrote: * Eliad Peller el...@wizery.com [150310 09:11]: On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote: On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote: On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote: I was expecting you to remove all calls to legacy_init_wl12xx from this file, including the ones for wl12xx aside from the wl18xx ones you removed, but if that's enough to clean out the platform_data handling from the wlcore driver, it's good enough as a start. not sure i'm following - can you elaborate? i'll summarize the way i see it. please correct me if i'm wrong. both wl18xx and wl12xx use the platform data to get the irq number. wl12xx (only) also needs some additional clock definitions to be passed. there's currently some issue with specifying some the of clock sources, so i preferred starting only with (the simpler) wl18xx bindings. for platforms with wl18xx, we can remove the pdata-quirk, as all the data (i.e. irq) can be passed by the new DT bindings. however, for platforms with wl12xx, we still need to pass the clock definitions (along with the irq), so we have to keep legacy_init_wl12xx for the time being (and that's also why we have to currently keep the platform_data handling in the wlcore driver) do you have something else in mind? I think what Arnd is saying is we've now removed all the wl12xx using legacy platforms, so all of them can boot with just data from dts. Right, that was my idea. I don't think that's the case (unless i'm missing something). e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which initializes wl12xx device. This one is just like the igep0030, as Tony was saying: the board boots from device tree already, so now that we have a binding for it, we can remove the wl12xx_set_platform_data() for it. i think the wl12xx_set_platform_data() name created some confusion - it is used to pass platform data for both wl12xx and wl18xx devices. (this confusion is all around the wlcore driver as well, due to the code evolution) the binding i added is for wl18xx only (there is no wl12xx binding yet). the remaining boards, AFAICT, have wl12xx (rather than wl18xx) cards. so i don't see how we can remove these wl12xx_set_platform_data() calls before we have wl12xx bindings in-place as well. What is missing for that binding then? I keep getting confused here, but I thought that they share the implementation that looks at the platform data. they both get the same wl12xx_platform_data struct, but only wl12xx cares about the clocks-related fields. the bindings i added parses only the irq. (Luca tried previously to upstream wl12xx DT support along with the required clock DT changes, but got some rejections, mainly wrt. clock stuff. e.g. http://thread.gmane.org/gmane.linux.kernel/1520752 that's why i preferred starting with easier wl18xx bindings only) I believe we did not have clock bindings back then, now it's simple to get the clock. If it's some internal clock to the wl12xx, then that's a different story, it should be just hidden behind a compatible flag then. i'm really not familiar with the common clock framework, but there still doesn't seem to be a way to determine whether a clock is XTAL or not (which is what Luca's patch was about). should we use compatible flag in such case? i'm not sure it sounds right. anyway, i'd really prefer, if possible, starting with the wl18xx bindings, and defer the wl12xx complications to later on. (i also need to find some wl12xx card in order to actually test the patches once i'll have them...) we do have to make sure these wl18xx bindings are future-compatible with the wl12xx ones, but i think the current bindings are pretty much standard (and are actually a subset of the bindings needed by wl12xx), so it should be fine. Well how about add just the parsing of the clock and assume it's always WL12XX_REFCLOCK_38 for now as that's the only thing we're currently using. Then we can add a property or compatible value if using something else as needed. Regards, Tony -- 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
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
Hi Dave, On 03/06/2015 07:45 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150306 09:28]: On 03/05/2015 06:41 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150305 12:24]: * Dave Gerlach d-gerl...@ti.com [150305 11:53]: On 03/05/2015 12:49 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150305 10:16]: On Thu, 5 Mar 2015, Dave Gerlach wrote: Introduce a dt property, ti,no-init, that prevents hwmod initialization. Even if a dt node is marked as disabled, hwmod still at least enables the hwmod and programs the sysconfig before attempting to idle it at boot. If an IP has been disabled by the hardware configuration on a platform, this will cause a hang due to writing to inactive registers. This property prevents that from happening by marking the hwmod as _HWMOD_STATE_DISABLED during init. I'm kind of wondering if hwmod should even touch a device if it's marked as disabled in the DT. Tony, what do you think? Well nothing happens if a device is status = disabled. No dev entry gets created for it at all and hwmod won't have any data for the device populated. The only way hwmod code could see that device if the device gets it's data from the legacy omap_hwmod_*_data.c instead of DT. We still need this for the sysconfig programming, correct? hwmod programs that regardless of dt status and then idles the IP, Well hwmod does not even know about the IP IO addresses if it's marked with status = disabled.. Which IP are you having problems with? which is why I needed the ti,no-init for the epos evm. It isn't just a matter of we shouldnt write to it because we don't want to use it; we can't write to it because the module is held off so it causes an external abort if we do. Well hard to say not knowing which module this is.. Pretty much all the modules have drivers and the driver just does pm_runtime_get() on it? Heh OK this thread is about the RTC driver, so I assume that's the problem :) So if you set the rtc to status = disabled how can the hwmod code do anything as AFAIK it won't even get the rtc IO address? Or am I missing something here? Perhaps I am mistaken, but from what I understand, all hwmods have _init and _setup called on them, and all hwmods read the IO address regardless of DT status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets called which calls _enable for the hwmod, and this calls both _enable_sysc and _update_sysc_cache which touch the sysconfig register of the IP. Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(), sorry. Looks like the hwmod IO address data does get populated even for status = disabled although the dev entry won't get created and omap_device_build_from_dt() never gets called. Normally this is fine regardless of whether or not we are using an IP because the module will wake up for a moment, have it's sysc programmed, and then be put back to sleep later, potentially never to be woken again if we bind no driver for it, which is fine for 99% of cases. In the case of am43x epos evm, you can take the same piece of silicon that will boot happily on the gp evm with the rtc hwmod in place and it will hang during boot on the epos evm because the board uses a pin to hold the RTC IP in reset. There is no way to detect this in software, the module can be turned on as normal using the clk_ctrl, but if you touch any of the IP registers you get an abort. OK sounds like some dts property is needed to signal this. As I understand, there is device RTC and this device has status 'disabled', so there is reasonable question why do we need to touch it at all? The HWMOD is some kind of SoC description, which was needed before DT. Now with DT in place it seems unreasonable to touch any IP block which: - are not defined in DT - has status 'disabled'. in above cases the u-boot has to dial with IP block if it's invisible for Kernel. The HWMOD framework intended to reset and put in some predefined states IPs which are visible for the Kernel, so then proper driver can start working with IP or IP will be kept in some low-power state if there is no driver. Such kind of changes really confused :(, because when I'm looking on DT and see - status='disabled' I suppose that such IP will not be touched by Kernel. But it's NOT really 'disabled'. It's kinda 'partially disabled' or 'not present' or 'unused' .. (if someone will decide to continue with such approach - it could be more useful to define new value for 'status' parameter :P). Also, just imaging that OMAP kernel is used with Xen as DomU and how hard will it be to find and cut off all such tricks :( Did I miss something? So we need to prevent this from happening but of course we can't selectively choose when the rtc hwmod gets added based on which board we are using so it seemed a DT flag was appropriate to indicate that we do not want to init the rtc IP at all only on this board.
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
On Wed, Mar 11, 2015 at 3:21 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Wed, Mar 11, 2015 at 2:17 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 11 March 2015 14:07:11 Javier Martinez Canillas wrote: Right now it seems that all boards in mainline with a WiLink6 part are using internal clocks. So as a first step I think that adding an optional refclock-frequency and tcxoclock-frequency properties should be enough. It would be good if the driver supports getting the refclock and tcxoclock from an external provider in case a board gets these from external clocks but that can be done as a followup if there are boards in the future using that design. But please bear in mind that I'm not familiar with the clock handling in WiLink6 since the WiLink8 part used in the IGEP boards does not need these clocks and I only looked at Luciano's previous patches and the WiLink today driver today. So it would be good if Eliad can double check my assumptions to see if those are correct. sounds right. that's what i know as well. Sounds good. I'd also be fine with not implementing the case for external clocks in the code until we need (and can test) it, but I think it should be specified in the binding from the start. Agreed. great. so i'll implement the internal clocks case only. thanks, Eliad. -- 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
Re: [PATCH v5 2/3] wl18xx: add basic device-tree support
On Wednesday 11 March 2015 11:05:47 Javier Martinez Canillas wrote:
On Wed, Mar 11, 2015 at 10:51 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 11 March 2015 01:34:19 Javier Martinez Canillas wrote:
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+ struct wl12xx_platform_data *pdata;
+
+ /* first, look for DT data */
I thought it was the opposite, that platform data should over-rule DT.
That way you can still use the data filled in
arch/arm/mach-omap2/pdata-quirks.c even after the driver supports your
new DT binding.
No, the pdata-quirks stuff for this driver must die, it was a hack
that only exists because we previously could not attach data to an
sdio function.
Ok sorry, I misunderstood and thought that the output from the
discussion in patch 3/3 was that the pdata could not still be removed
due not having a way to configure the clocks for wl12xx.
I think that is still the case, but we should never have both pdata
and DT, and if we ever did, I think the DT should take precedence
so we can be sure that the pdata is not used and can be removed.
Arnd
--
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
Re: [PATCH v5 0/5] Add support for Fujitsu USB host controller
On Sun, Feb 22, 2015 at 12:25:35PM +0800, Sneeker Yeh wrote: These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 4 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Successfully tested on Fujitsu mb86s7x board. Changes since v4 (RFC): [https://lkml.org/lkml/2015/2/17/13] - based on Felipe's comment, rename dwc3-mb86s70.c to dwc3-fujitsu.c which is more generic. - based on Mathias's comment, remove unhelpful comment, and change the function name of xhci_try_to_clear_csc() to xhci_late_csc_clear_quirk() which is more appropriate. Changes since v3 (RFC): [https://lkml.org/lkml/2015/1/25/8] - based on Mathias's comment, fix bug and using xhci_port_state_to_neutral() helper function to mask out some RW1C bits, prevent writing back all the bits read from the PORTSC register. Changes since v2 (RFC): [https://lkml.org/lkml/2015/1/19/55] - based on Felipe's comment, re-order patches to avoid breaking bisectability, - based on Felipe's comment, add comment to structure's member, and sort it alphabetically, - based on Felipe's comment, add another v2.90 revision number in dwc3 IP. Changes since v1 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue, - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma mask, remove unnecessary comment, and refactor suspend/resume handler in Fujitsu Specific Glue layer in dwc3, - based on Felipe's comment, add more commit log and comments in Synopsis quirk implementation, and separate it into four patches. Sneeker Yeh (5): xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core xhci: Platform: Set Synopsis device disconnection quirk based on platform data usb: dwc3: add revision number DWC3_REVISION_290A and DWC3_REVISION_300A usb: dwc3: Add quirk for Synopsis device disconnection errata usb: dwc3: add Fujitsu Specific Glue layer Mathias, if you want me to take this series I need your Acked-by, otherwise I can give you mine, just let me know. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
On Wednesday 11 March 2015 02:00:59 Javier Martinez Canillas wrote: Hello Tony, On Tue, Mar 10, 2015 at 6:35 PM, Tony Lindgren t...@atomide.com wrote: we do have to make sure these wl18xx bindings are future-compatible with the wl12xx ones, but i think the current bindings are pretty much standard (and are actually a subset of the bindings needed by wl12xx), so it should be fine. Well how about add just the parsing of the clock and assume it's always WL12XX_REFCLOCK_38 for now as that's the only thing we're currently using. Then we can add a property or compatible value if using something else as needed. What do you mean by parsing here? IIUC there isn't a clock driver for these clocks and are setup directly in the drivers/net/wireless/ti/wl12xx/main.c driver. So you can't make the WLAN chip dev node a consumer of these clocks by adding a phandle to a clock provider and clock specifiers since there isn't a provider to be referenced in the DT. Or did I misunderstand? As I understand it, the clock signal is provided by an external oscillator, which we can easily model in DT, and then you call clk_get_rate on that. If there is no external clock provider for this chip and the clocks are provided by the device itself, then all we need is a clock-frequency property in the device node. Arnd -- 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
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
On Wednesday 11 March 2015 14:07:11 Javier Martinez Canillas wrote: Right now it seems that all boards in mainline with a WiLink6 part are using internal clocks. So as a first step I think that adding an optional refclock-frequency and tcxoclock-frequency properties should be enough. It would be good if the driver supports getting the refclock and tcxoclock from an external provider in case a board gets these from external clocks but that can be done as a followup if there are boards in the future using that design. But please bear in mind that I'm not familiar with the clock handling in WiLink6 since the WiLink8 part used in the IGEP boards does not need these clocks and I only looked at Luciano's previous patches and the WiLink today driver today. So it would be good if Eliad can double check my assumptions to see if those are correct. Sounds good. I'd also be fine with not implementing the case for external clocks in the code until we need (and can test) it, but I think it should be specified in the binding from the start. Arnd -- 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
Re: [PATCH v3 1/2] remoteproc: use a flag to detect the presence of IOMMU
On Fri, Jan 9, 2015 at 11:21 PM, Suman Anna s-a...@ti.com wrote: The remoteproc driver core currently relies on iommu_present() on the bus the device is on, to perform MMU management. However, this logic doesn't scale for multi-arch, especially for processors that do not have an IOMMU. Replace this logic instead by using a h/w capability flag for the presence of IOMMU in the rproc structure. This issue is seen on OMAP platforms when trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend / resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. The existing platform implementation drivers - OMAP remoteproc, STE Modem remoteproc and DA8xx remoteproc, are updated as well to properly configure the newly added rproc field. Cc: Robert Tivy rt...@ti.com Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Suman Anna s-a...@ti.com Applied to remoteproc's for-next branch. Thanks, Ohad. -- 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
Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
Hi Tony,
On 03/11/2015 11:26 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150310 12:55]:
Tony,
On 03/10/2015 11:09 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150309 16:59]:
On 03/05/2015 10:57 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150305 08:47]:
On 03/05/2015 09:40 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150304 20:14]:
Dave,
Looks like the commit message disappeared during your patch preparation.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..086415c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -77,10 +77,23 @@
*/
soc {
compatible = ti,omap-infra;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0x0 0x44d0 0x4000,
+ 0x8 0x44d8 0x2000;
+
I think putting the ranges here will cause issues for adding
ranges for anything else.
How about do something like this instead (untested):
ocp {
l4_wkup: l4_wkup@44c0 {
compatible = am335-l4-wkup, simple-bus;
ranges = 0 0x44c0 0x3f;
wkup_m3: wkup_m3@44d0 {
compatible = ti,am3353-wkup-m3;
reg = 0x100 0x4000, /* M3 UMEM */
0x18 0x2000; /* M3 DMEM */
ti,hwmods = wkup_m3;
ti,pm-firmware = am335x-pm-firmware.elf;
};
...
};
};
That way we can start moving also the other l4_wkup components there
eventuallly without having to redo the ranges again for wkup_m3.
You can also look at how the scm_conf was done for dm816x.dtsi for an
example, and the recent large set of patches posted by Tero.
I have taken a look at both the above. The L4_WKUP range includes the
PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0
etc. What all do we want to move here eventually?
Well eventually all the children of L4_WKUP, but that can be done
slowly as some of the drivers have weird hacks and may not work
properly if moved around.
For example, anything with reg entries for something like SCM area will
break as that's not going to be in the L4_WKUP area ny longer :p And
that's actually good as it will protect us from spaghetti code
automatically later on for new code.
Depending on that, we may have to use 2 address cells like in Tero's
PRCM cleanup series rather than the single cell translation used by
you in dm816x.dtsi so that we can retain the relative addresses
w.r.t the existing node bases in the derivative child nodes.
Hmm OK, care to paste a dts snippet example for that?
Suman and I have been looking at this together, so I can comment here. An
implementation like this is what Suman is referring to:
+ l4_wkup: l4_wkup@44c0 {
+ compatible = am335-l4-wkup, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x44c0 0x10,
+1 0x0 0x44d0 0x4000,
+2 0x8 0x44d8 0x2000;
Actually, this would be slightly different, something like
+ ranges = 0 00x44c0 0x10,
+1 00x44d0 0x10,
+2 00x44e0 0x4000,
+3 00x44e1 0x2000;
and the M3 DMEM entry below will be adjusted as 1 0x8 0x2000.
+
+ wkup_m3: wkup_m3@1,0 {
+ compatible = ti,am3353-wkup-m3;
+ reg = 1 0x0 0x4000, /* M3 UMEM */
+ 2 0x8 0x2000; /* M3 DMEM */
+
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+ };
+
The of_* layer automatically translates everything so the pdata-quirks can
still
match based on wkup_m3@44d0. The existing wkup_m3_rproc driver works
almost
entirely as is with this, all cpu addresses are read and mapped correctly but
the driver no longer will read the actual device addresses correctly which we
need for understanding where to load the firmware sections.
OK. I still don't quite understand how these additional ranges make sense
for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if
it allows you to translate directly to the m3 address space, but is that
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi,
On Wed, Mar 11, 2015 at 10:43:17AM -0700, Tony Lindgren wrote:
No no, capacity-uah is what we should use, but you need an ack from
the battery and device tree people that this is OK. Let's not add
ti,capacity-uah” as that can obviously be a generic property.
I'm okay with capacity-uah.
[...]
Oh if they are battery spicific, then ideally we'd have generic batery
voltage to capacity maps property rather than a custom ti specific
property.
To avoid extra hassles later on, maybe you could submit a generic
binding patch only documenting it to the battery people and the device
tree people? That will make it easier to maintain this driver in the
long run.
Actually the proper way would be to differentiate between the
battery and the measurement chip / adc and that should be
implemented in the long run. The kernel's power supply framework
is not yet ready for it, though.
Example DT:
battery {
battery-specific-data;
};
fuel-gauge {
measures = battery;
};
charger {
charges = battery;
};
Since infrastructure for generic bindings is missing, I think its
best to have the vendor properties for now and map this to generic
properties, once they have been specified.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH v8 0/4] hwspinlock core omap dt support
Hi Suman, On Thu, Mar 5, 2015 at 4:01 AM, Suman Anna s-a...@ti.com wrote: This is the latest version of the hwspinlock dt support series, rebased onto v4.0-rc1 and addressing the long discussion on the bindings in v7 [1]. I really hope that this series can make it into 4.1. From a quick glance this looks great, thanks! Mark, Can you please provide your Acked-by for the binding documents so that Ohad can pick up the patches for the next merge window? That would be perfect. Once we'll have it I could move forward with this towards 4.1. Thanks, Ohad. -- 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
Re: ti,codec property in sound/soc/omap/omap-twl4030.c not used
On 03/12/2015 12:12 AM, Belisko Marek wrote: Hi, I'm looking at sources for omap-twl4030.c driver which is used by many boards. In DT bindings documentation is property ti,codec described as mandatory but it's never parsed in driver code. I did small experiment in gta04 board and remove ti,codec from devicetree and sound was working. I think it can be removed from documentation and also from various device trees. Is my assumption correct? Thanks. Correct. The ti,twl4030-audio is for the MFD driver and the device for the ASoC codec is created in there w/o actual DT compatible string. The audio part of the twl4030 is responsible for the audio and the vibra functionality. Are you going to send the patches? Thanks, Péter -- 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
Re: [PATCHv3 34/35] ARM: dts: dra7: add system control module node
On 03/11/2015 07:17 PM, Tony Lindgren wrote:
Hi Tero,
* Tero Kristo t-kri...@ti.com [150225 11:09]:
Add node for system control module, and move all the existing system
control IO space users under this new node as its children. A new node
for scm_conf area is also added.
...
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -203,26 +203,47 @@
};
};
+ scm: scm@4a002000 {
+ compatible = ti,dra7-ctrl, simple-bus;
+ reg = 0x4a002000 0x1400,
+ 0x4a003400 0x600,
+ 0x4ae0c000 0x600;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x4a002000 0x1400,
+1 0 0x4a003400 0x600,
+2 0 0x4ae0c000 0x600;
+
+ scm_conf: tisyscon@0,0 {
+ compatible = syscon;
+ reg = 0 0x0 0x1400;
+ #address-cells = 1;
+ #size-cells = 1;
+ };
+
+ dra7_pmx_core: pinmux@1,0 {
+ compatible = ti,dra7-padconf,
+pinctrl-single;
+ reg = 1 0x0 0x0464;
+ #address-cells = 1;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x3fff;
+ };
+ };
Wouldn't it make more sense to have separate device_scm, core_scm and
wkup_scm instead of stuffing multiple ranges here?
Or are there other reasons for the multiple ranges?
Yea that was the alternative I was thinking about, I ended up with this
for some reason. I think personally I liked having them all under the
same SCM part, because they are nicely grouped then, and well, its the
same system control part in the chip. We can split it up easily of
course. Should we have a higher level scm part and then have core_scm
and wkup_scm under this followed by the sub-functions, or just drop the
top level scm part completely?
This same question applies to omap4 + omap5 also. In some part for omap3
also, as it also has pmx_core + pmx_wkup separately, even if they are
part of the same register space.
Anyway, just a political decision from your side, I am fine either way. :)
-Tero
--
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
[PATCH v6 6/7] DT: omap4/5: add binding for the wake-up generator
Add a binding for the OMAP4/5 wake-up generator, which acts as
an interrupt controller feeding into the GIC.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
.../interrupt-controller/ti,omap4-wugen-mpu| 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
new file mode 100644
index 000..43effa0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
@@ -0,0 +1,33 @@
+TI OMAP4 Wake-up Generator
+
+All TI OMAP4/5 (and their derivatives) an interrupt controller that
+routes interrupts to the GIC, and also serves as a wakeup source. It
+is also referred to as WUGEN-MPU, hence the name of the binding.
+
+Reguired properties:
+
+- compatible : should contain at least ti,omap4-wugen-mpu or
+ ti,omap5-wugen-mpu
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 3.
+- interrupt-parent : a phandle to the GIC these interrupts are routed
+ to.
+
+Notes:
+
+- Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
+ are explicitly forbiden.
+
+Example:
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = ti,omap5-wugen-mpu, ti,omap4-wugen-mpu;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48281000 0x1000;
+ interrupt-parent = gic;
+ };
--
2.1.4
--
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
[PATCH v6 2/7] irqchip: crossbar: convert dra7 crossbar to stacked domains
Support for the TI crossbar used on the DRA7 family of chips
is implemented as an ugly hack on the side of the GIC.
Converting it to stacked domains makes it slightly more
palatable, as it results in a cleanup.
Unfortunately, as the DT bindings failed to acknowledge the
fact that this is actually yet another interrupt controller
(the third, actually), we have yet another breakage. Oh well.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7.dtsi | 35 +++---
arch/arm/boot/dts/dra72-evm.dts | 1 -
arch/arm/boot/dts/dra72x.dtsi | 3 +-
arch/arm/boot/dts/dra74x.dtsi | 5 +-
arch/arm/mach-omap2/omap4-common.c | 4 -
drivers/irqchip/irq-crossbar.c | 210 +++-
include/linux/irqchip/irq-crossbar.h| 11 --
9 files changed, 149 insertions(+), 125 deletions(-)
delete mode 100644 include/linux/irqchip/irq-crossbar.h
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af..170fbf9 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -454,7 +454,6 @@
mcp_rtc: rtc@6f {
compatible = microchip,mcp7941x;
reg = 0x6f;
- interrupt-parent = gic;
interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_LOW; /* IRQ_SYS_1N */
pinctrl-names = default;
@@ -477,7 +476,7 @@
uart3 {
status = okay;
- interrupts-extended = gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH,
+ interrupts-extended = crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH,
dra7_pmx_core 0x248;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 746cddb..789ee58 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -446,7 +446,7 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = uart1_pins;
- interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
+ interrupts-extended = crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
dra7_pmx_core 0x3e0;
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fed..850f949 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -13,14 +13,13 @@
#include skeleton.dtsi
#define MAX_SOURCES 400
-#define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
/ {
#address-cells = 1;
#size-cells = 1;
compatible = ti,dra7xx;
- interrupt-parent = gic;
+ interrupt-parent = crossbar_mpu;
aliases {
i2c0 = i2c1;
@@ -50,18 +49,19 @@
GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW);
+ interrupt-parent = gic;
};
gic: interrupt-controller@48211000 {
compatible = arm,cortex-a15-gic;
interrupt-controller;
#interrupt-cells = 3;
- arm,routable-irqs = 192;
reg = 0x48211000 0x1000,
0x48212000 0x1000,
0x48214000 0x2000,
0x48216000 0x2000;
interrupts = GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
+ interrupt-parent = gic;
};
/*
@@ -91,8 +91,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x100,
0x4500 0x1000;
- interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI DIRECT_IRQ(10) IRQ_TYPE_LEVEL_HIGH;
+ interrupts-extended = crossbar_mpu GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH,
+ gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -344,7 +344,7 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
- interrupts-extended = gic GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH;
+ interrupts-extended = crossbar_mpu GIC_SPI 67
IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
@@ -355,7 +355,7 @@
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
reg = 0x4806c000 0x100;
- interrupts-extended = gic GIC_SPI 68
IRQ_TYPE_LEVEL_HIGH;
+
[PATCH v6 5/7] DT: arm,gic: kill arm,routable-irqs
Nobody will regret it.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
Documentation/devicetree/bindings/arm/gic.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index c97484b..1e0d212 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -56,11 +56,6 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
-- arm,routable-irqs : Total number of gic irq inputs which are not directly
- connected from the peripherals, but are routed dynamically
- by a crossbar/multiplexer preceding the GIC. The GIC irq
- input line is assigned dynamically when the corresponding
- peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@@ -68,7 +63,6 @@ Example:
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
- arm,routable-irqs = 160;
reg = 0xfff11000 0x1000,
0xfff10100 0x100;
};
--
2.1.4
--
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
Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges
* Dave Gerlach d-gerl...@ti.com [150310 12:55]:
Tony,
On 03/10/2015 11:09 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150309 16:59]:
On 03/05/2015 10:57 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [150305 08:47]:
On 03/05/2015 09:40 AM, Tony Lindgren wrote:
* Dave Gerlach d-gerl...@ti.com [150304 20:14]:
Dave,
Looks like the commit message disappeared during your patch preparation.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index acd3705..086415c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -77,10 +77,23 @@
*/
soc {
compatible = ti,omap-infra;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0x0 0x44d0 0x4000,
+ 0x8 0x44d8 0x2000;
+
I think putting the ranges here will cause issues for adding
ranges for anything else.
How about do something like this instead (untested):
ocp {
l4_wkup: l4_wkup@44c0 {
compatible = am335-l4-wkup, simple-bus;
ranges = 0 0x44c0 0x3f;
wkup_m3: wkup_m3@44d0 {
compatible = ti,am3353-wkup-m3;
reg = 0x100 0x4000, /* M3 UMEM */
0x18 0x2000; /* M3 DMEM */
ti,hwmods = wkup_m3;
ti,pm-firmware = am335x-pm-firmware.elf;
};
...
};
};
That way we can start moving also the other l4_wkup components there
eventuallly without having to redo the ranges again for wkup_m3.
You can also look at how the scm_conf was done for dm816x.dtsi for an
example, and the recent large set of patches posted by Tero.
I have taken a look at both the above. The L4_WKUP range includes the
PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0
etc. What all do we want to move here eventually?
Well eventually all the children of L4_WKUP, but that can be done
slowly as some of the drivers have weird hacks and may not work
properly if moved around.
For example, anything with reg entries for something like SCM area will
break as that's not going to be in the L4_WKUP area ny longer :p And
that's actually good as it will protect us from spaghetti code
automatically later on for new code.
Depending on that, we may have to use 2 address cells like in Tero's
PRCM cleanup series rather than the single cell translation used by
you in dm816x.dtsi so that we can retain the relative addresses
w.r.t the existing node bases in the derivative child nodes.
Hmm OK, care to paste a dts snippet example for that?
Suman and I have been looking at this together, so I can comment here. An
implementation like this is what Suman is referring to:
+ l4_wkup: l4_wkup@44c0 {
+ compatible = am335-l4-wkup, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x44c0 0x10,
+1 0x0 0x44d0 0x4000,
+2 0x8 0x44d8 0x2000;
+
+ wkup_m3: wkup_m3@1,0 {
+ compatible = ti,am3353-wkup-m3;
+ reg = 1 0x0 0x4000, /* M3 UMEM */
+ 2 0x8 0x2000; /* M3 DMEM */
+
+ ti,hwmods = wkup_m3;
+ ti,pm-firmware = am335x-pm-firmware.elf;
+ };
+ };
+
The of_* layer automatically translates everything so the pdata-quirks can
still
match based on wkup_m3@44d0. The existing wkup_m3_rproc driver works
almost
entirely as is with this, all cpu addresses are read and mapped correctly but
the driver no longer will read the actual device addresses correctly which we
need for understanding where to load the firmware sections.
OK. I still don't quite understand how these additional ranges make sense
for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if
it allows you to translate directly to the m3 address space, but is that
really the case here? Maybe you should have the ranges in wkup_m3 instead
if you want addresses for the m3?
These device addresses are being read directly using of_get_address, which
reads
the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We
would need some sort of change there also to get the proper 0x0 and 0x8
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
Hi Dave, On 03/10/2015 07:59 PM, Dave Gerlach wrote: On 03/10/2015 12:36 PM, Grygorii Strashko wrote: On 03/06/2015 07:45 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150306 09:28]: On 03/05/2015 06:41 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150305 12:24]: * Dave Gerlach d-gerl...@ti.com [150305 11:53]: On 03/05/2015 12:49 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150305 10:16]: On Thu, 5 Mar 2015, Dave Gerlach wrote: Introduce a dt property, ti,no-init, that prevents hwmod initialization. Even if a dt node is marked as disabled, hwmod still at least enables the hwmod and programs the sysconfig before attempting to idle it at boot. If an IP has been disabled by the hardware configuration on a platform, this will cause a hang due to writing to inactive registers. This property prevents that from happening by marking the hwmod as _HWMOD_STATE_DISABLED during init. I'm kind of wondering if hwmod should even touch a device if it's marked as disabled in the DT. Tony, what do you think? Well nothing happens if a device is status = disabled. No dev entry gets created for it at all and hwmod won't have any data for the device populated. The only way hwmod code could see that device if the device gets it's data from the legacy omap_hwmod_*_data.c instead of DT. We still need this for the sysconfig programming, correct? hwmod programs that regardless of dt status and then idles the IP, Well hwmod does not even know about the IP IO addresses if it's marked with status = disabled.. Which IP are you having problems with? which is why I needed the ti,no-init for the epos evm. It isn't just a matter of we shouldnt write to it because we don't want to use it; we can't write to it because the module is held off so it causes an external abort if we do. Well hard to say not knowing which module this is.. Pretty much all the modules have drivers and the driver just does pm_runtime_get() on it? Heh OK this thread is about the RTC driver, so I assume that's the problem :) So if you set the rtc to status = disabled how can the hwmod code do anything as AFAIK it won't even get the rtc IO address? Or am I missing something here? Perhaps I am mistaken, but from what I understand, all hwmods have _init and _setup called on them, and all hwmods read the IO address regardless of DT status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets called which calls _enable for the hwmod, and this calls both _enable_sysc and _update_sysc_cache which touch the sysconfig register of the IP. And that's the problem :) What ePar says: “disabled” - Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off). and current OF implementation will not register corresponding device in DD core and, as result, drivers will be never ever bound with these devices. As i said before, such devices are invisible/absent/not present, so there are no reasons to touch them at all in Kernel, because result is unpredictable in general. And there are no guarantee that there will be no other issues, even if you'll fix this particular case. Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(), sorry. Looks like the hwmod IO address data does get populated even for status = disabled although the dev entry won't get created and omap_device_build_from_dt() never gets called. Normally this is fine regardless of whether or not we are using an IP because the module will wake up for a moment, have it's sysc programmed, and then be put back to sleep later, potentially never to be woken again if we bind no driver for it, which is fine for 99% of cases. In the case of am43x epos evm, you can ^^ if status=“disabled”/failed there will be no device and no driver will have been bound :) take the same piece of silicon that will boot happily on the gp evm with the rtc hwmod in place and it will hang during boot on the epos evm because the board uses a pin to hold the RTC IP in reset. There is no way to detect this in software, the module can be turned on as normal using the clk_ctrl, but if you touch any of the IP registers you get an abort. OK sounds like some dts property is needed to signal this. Seems It might be much more simple to just remove RTC device from DT, as it's disabled and unaccessible == not present: - add am4372-rtc.dtsi and put RTC device definition there - include am4372-rtc.dtsi in board files where allowed As I understand, there is device RTC and this device has status 'disabled', so there is reasonable question why do we need to touch it at all? The HWMOD is some kind of SoC description, which was needed before DT. Now with DT in place it seems unreasonable to touch any IP block which: - are not defined in DT - has status 'disabled'. in above cases the u-boot
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
* Eliad Peller el...@wizery.com [150311 06:39]: On Wed, Mar 11, 2015 at 3:21 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Wed, Mar 11, 2015 at 2:17 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 11 March 2015 14:07:11 Javier Martinez Canillas wrote: Right now it seems that all boards in mainline with a WiLink6 part are using internal clocks. So as a first step I think that adding an optional refclock-frequency and tcxoclock-frequency properties should be enough. It would be good if the driver supports getting the refclock and tcxoclock from an external provider in case a board gets these from external clocks but that can be done as a followup if there are boards in the future using that design. But please bear in mind that I'm not familiar with the clock handling in WiLink6 since the WiLink8 part used in the IGEP boards does not need these clocks and I only looked at Luciano's previous patches and the WiLink today driver today. So it would be good if Eliad can double check my assumptions to see if those are correct. sounds right. that's what i know as well. Sounds good. I'd also be fine with not implementing the case for external clocks in the code until we need (and can test) it, but I think it should be specified in the binding from the start. Agreed. great. so i'll implement the internal clocks case only. OK great sounds good to me also. Regards, Tony -- 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
Re: ti,codec property in sound/soc/omap/omap-twl4030.c not used
Hi, On Thu, Mar 12, 2015 at 10:19 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 03/12/2015 12:12 AM, Belisko Marek wrote: Hi, I'm looking at sources for omap-twl4030.c driver which is used by many boards. In DT bindings documentation is property ti,codec described as mandatory but it's never parsed in driver code. I did small experiment in gta04 board and remove ti,codec from devicetree and sound was working. I think it can be removed from documentation and also from various device trees. Is my assumption correct? Thanks. Correct. The ti,twl4030-audio is for the MFD driver and the device for the ASoC codec is created in there w/o actual DT compatible string. The audio part of the twl4030 is responsible for the audio and the vibra functionality. Thanks for reply. Are you going to send the patches? Yes will do. Thanks, Péter BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- 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
Re: [PATCHv3 34/35] ARM: dts: dra7: add system control module node
* Tero Kristo t-kri...@ti.com [150311 12:57]:
On 03/11/2015 09:26 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150311 12:09]:
On 03/11/2015 07:17 PM, Tony Lindgren wrote:
Hi Tero,
* Tero Kristo t-kri...@ti.com [150225 11:09]:
Add node for system control module, and move all the existing system
control IO space users under this new node as its children. A new node
for scm_conf area is also added.
...
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -203,26 +203,47 @@
};
};
+ scm: scm@4a002000 {
+ compatible = ti,dra7-ctrl, simple-bus;
+ reg = 0x4a002000 0x1400,
+ 0x4a003400 0x600,
+ 0x4ae0c000 0x600;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x4a002000 0x1400,
+ 1 0 0x4a003400 0x600,
+ 2 0 0x4ae0c000 0x600;
+
+ scm_conf: tisyscon@0,0 {
+ compatible = syscon;
+ reg = 0 0x0 0x1400;
+ #address-cells = 1;
+ #size-cells = 1;
+ };
+
+ dra7_pmx_core: pinmux@1,0 {
+ compatible = ti,dra7-padconf,
+ pinctrl-single;
+ reg = 1 0x0 0x0464;
+ #address-cells = 1;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x3fff;
+ };
+ };
Wouldn't it make more sense to have separate device_scm, core_scm and
wkup_scm instead of stuffing multiple ranges here?
Or are there other reasons for the multiple ranges?
Yea that was the alternative I was thinking about, I ended up with this for
some reason. I think personally I liked having them all under the same SCM
part, because they are nicely grouped then, and well, its the same system
control part in the chip. We can split it up easily of course. Should we
have a higher level scm part and then have core_scm and wkup_scm under this
followed by the sub-functions, or just drop the top level scm part
completely?
Well I'd model it after the hardware so we can have one or more scm driver
instances managing the clock for those blocks. If we squash them together,
we won't have a chance to pass interrupts and clocks device tree property
to the right driver instance. And for example 5432 TRM has them as separate
devices in Figure 18-1. Control Module Overview.
I don't think we need the top level scm to group them under, these are all
connected seprately to the interconnect, right?
Yea, can't really think of any real need for the top-level node.
This same question applies to omap4 + omap5 also. In some part for omap3
also, as it also has pmx_core + pmx_wkup separately, even if they are part
of the same register space.
Anyway, just a political decision from your side, I am fine either way. :)
OK thanks for confirming that, to me it makes sense to set them up as
separate instances then.
All right, you got fair points there, I'll rework this for next revision of
the set. Had a quick look at OMAP3 TRM and it is also basically listing
these as separate instances also, so I'll change all OMAP3+.
Oh OK.
Tony
--
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
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On Thu, Mar 12, 2015 at 12:43:40PM -0700, Stephen Boyd wrote: On 03/12/15 10:20, Sebastian Andrzej Siewior wrote: On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote: diff = --- arch/arm/mach-imx/mach-imx6q.c +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void) * set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad * (external OSC), and we need to clear the bit. */ - clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP : IMX6Q_GPR1_ENET_CLK_SEL_PAD; gpr = syscon_regmap_lookup_by_compatible(fsl,imx6q-iomuxc-gpr); if (!IS_ERR(gpr)) Any idea how to do the comparison here? Or should we rely that the bootloader sets this properly (it managed already to select a frequency)? The phy has no clock node in current DT's so we can check this. This has been fixed by adding a clk_is_match() helper and using that to compare instead of comparing raw pointers. It would be nice if we could replace the patch with something else that doesn't require this helper though. It looks like this is static board configuration, so I wonder why we didn't just have a DT property that indicates how the gpr should be configured for this particular board. We did not add a DT property for it, because there was already enough info (clock configuration) in DT for kernel to figure it out. Shawn -- 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
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote: diff = --- arch/arm/mach-imx/mach-imx6q.c +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void) * set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad * (external OSC), and we need to clear the bit. */ - clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP : IMX6Q_GPR1_ENET_CLK_SEL_PAD; gpr = syscon_regmap_lookup_by_compatible(fsl,imx6q-iomuxc-gpr); if (!IS_ERR(gpr)) Any idea how to do the comparison here? Or should we rely that the bootloader sets this properly (it managed already to select a frequency)? The phy has no clock node in current DT's so we can check this. Sebastian -- 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
[PATCH 1/2] ARM: dts: omap3: Remove all references to ti,codec property
ti,codec property is not used (parsed) in omap-twl4030 driver. The
ti,twl4030-audio
which ti,codec points by phandle is mfd driver and device for ASoC codec is
created
w/o DT compatible string. Removing all references in DT files.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 1 -
arch/arm/boot/dts/omap3-beagle.dts | 1 -
arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 1 -
arch/arm/boot/dts/omap3-devkit8000.dts | 1 -
arch/arm/boot/dts/omap3-gta04.dtsi | 1 -
arch/arm/boot/dts/omap3-igep.dtsi | 1 -
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 -
arch/arm/boot/dts/omap3-overo-base.dtsi | 1 -
arch/arm/boot/dts/omap3-tao3530.dtsi| 1 -
9 files changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 25f7b0a..da1464b 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -60,7 +60,6 @@
ti,model = omap3beagle;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
gpio_keys {
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index c792391..4d30eaf 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -71,7 +71,6 @@
ti,model = omap3beagle;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
gpio_keys {
diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
index d9e92b6..046cd77 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -16,7 +16,6 @@
ti,model = cm-t35;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
};
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 169037e..134d3f2 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -48,7 +48,6 @@
ti,model = devkit8000;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
ti,audio-routing =
Ext Spk, PREDRIVEL,
Ext Spk, PREDRIVER,
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index fb3a696..b9f6881 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -46,7 +46,6 @@
ti,model = gta04;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
spi_lcd {
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 8a63ad2..d5e5cd4 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -22,7 +22,6 @@
compatible = ti,omap-twl4030;
ti,model = igep2;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
vdd33: regulator-vdd33 {
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index e81fb65..e631333 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -38,7 +38,6 @@
ti,model = lilly-a83x;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
reg_vcc3: vcc3 {
diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi
b/arch/arm/boot/dts/omap3-overo-base.dtsi
index d36bf02..18e1649 100644
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -27,7 +27,6 @@
ti,model = overo;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
/* HS USB Port 2 Power */
diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi
b/arch/arm/boot/dts/omap3-tao3530.dtsi
index e89820a..b3b24a5 100644
--- a/arch/arm/boot/dts/omap3-tao3530.dtsi
+++ b/arch/arm/boot/dts/omap3-tao3530.dtsi
@@ -45,7 +45,6 @@
/* McBSP2 is used for onboard sound, same as on beagle */
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
/* Regulator to enable/switch the vcc of the Wifi module */
--
1.9.1
--
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
[PATCH 2/2] Documentation: omap-twl4030: Remove ti,codec property
ti,codec property is not necessary anymore thus removing references
from documentation.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Documentation/devicetree/bindings/sound/omap-twl4030.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 1ab6bc8..656165f 100644
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
@@ -4,7 +4,6 @@ Required properties:
- compatible: ti,omap-twl4030
- ti,model: Name of the sound card (for example omap3beagle)
- ti,mcbsp: phandle for the McBSP node
-- ti,codec: phandle for the twl4030 audio node
Optional properties:
- ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
@@ -59,5 +58,4 @@ sound {
ti,model = omap3beagle;
ti,mcbsp = mcbsp2;
- ti,codec = twl_audio;
};
--
1.9.1
--
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
[PATCH 0/2] ARM: devicetree: Remove unused ti,codec property
ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary to specify this property in DT because ti,twl4030-audio which ti,codec was pointing to by phandle is mfd driver and device for ASoC ic created w/o any DT property (codec name is hardcoded in ASoC driver). Please see reply [1] from Peter Ujfalusi. [1]: http://comments.gmane.org/gmane.linux.ports.arm.omap/124273 Marek Belisko (2): ARM: dts: omap3: Remove all references to ti,codec property Documentation: omap-twl4030: Remove ti,codec property Documentation/devicetree/bindings/sound/omap-twl4030.txt | 2 -- arch/arm/boot/dts/omap3-beagle-xm.dts| 1 - arch/arm/boot/dts/omap3-beagle.dts | 1 - arch/arm/boot/dts/omap3-cm-t3x30.dtsi| 1 - arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-gta04.dtsi | 1 - arch/arm/boot/dts/omap3-igep.dtsi| 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 - arch/arm/boot/dts/omap3-overo-base.dtsi | 1 - arch/arm/boot/dts/omap3-tao3530.dtsi | 1 - 10 files changed, 11 deletions(-) -- 1.9.1 -- 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
Re: [PATCH] phy: Add a driver for dm816x USB PHY
* Rusty Russell ru...@rustcorp.com.au [150311 18:15]: Tony Lindgren t...@atomide.com writes: * Paul Bolle pebo...@tiscali.nl [150311 04:16]: Oh, it should be just GPL v2 like most of the kernel. Probably copied the header from some other phy driver, will update that instead. Well, all my code is explicitly v2 or later. I'll leave it someone else to try to figure out the stats. I vote for Jon! It seems I nowadays prefer a mix of GPLv2 with just a sprinkle of the later! Keeps people guessing you know :) Tony -- 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
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
Grygorii, On 03/11/2015 11:32 AM, Grygorii Strashko wrote: Hi Dave, On 03/10/2015 07:59 PM, Dave Gerlach wrote: On 03/10/2015 12:36 PM, Grygorii Strashko wrote: On 03/06/2015 07:45 PM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150306 09:28]: On 03/05/2015 06:41 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150305 12:24]: * Dave Gerlach d-gerl...@ti.com [150305 11:53]: On 03/05/2015 12:49 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150305 10:16]: On Thu, 5 Mar 2015, Dave Gerlach wrote: Introduce a dt property, ti,no-init, that prevents hwmod initialization. Even if a dt node is marked as disabled, hwmod still at least enables the hwmod and programs the sysconfig before attempting to idle it at boot. If an IP has been disabled by the hardware configuration on a platform, this will cause a hang due to writing to inactive registers. This property prevents that from happening by marking the hwmod as _HWMOD_STATE_DISABLED during init. I'm kind of wondering if hwmod should even touch a device if it's marked as disabled in the DT. Tony, what do you think? Well nothing happens if a device is status = disabled. No dev entry gets created for it at all and hwmod won't have any data for the device populated. The only way hwmod code could see that device if the device gets it's data from the legacy omap_hwmod_*_data.c instead of DT. We still need this for the sysconfig programming, correct? hwmod programs that regardless of dt status and then idles the IP, Well hwmod does not even know about the IP IO addresses if it's marked with status = disabled.. Which IP are you having problems with? which is why I needed the ti,no-init for the epos evm. It isn't just a matter of we shouldnt write to it because we don't want to use it; we can't write to it because the module is held off so it causes an external abort if we do. Well hard to say not knowing which module this is.. Pretty much all the modules have drivers and the driver just does pm_runtime_get() on it? Heh OK this thread is about the RTC driver, so I assume that's the problem :) So if you set the rtc to status = disabled how can the hwmod code do anything as AFAIK it won't even get the rtc IO address? Or am I missing something here? Perhaps I am mistaken, but from what I understand, all hwmods have _init and _setup called on them, and all hwmods read the IO address regardless of DT status at this point with _init_mpu_rt_base. In _setup, _setup_reset gets called which calls _enable for the hwmod, and this calls both _enable_sysc and _update_sysc_cache which touch the sysconfig register of the IP. And that's the problem :) What ePar says: disabled - Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or switched off). and current OF implementation will not register corresponding device in DD core and, as result, drivers will be never ever bound with these devices. As i said before, such devices are invisible/absent/not present, so there are no reasons to touch them at all in Kernel, because result is unpredictable in general. And there are no guarantee that there will be no other issues, even if you'll fix this particular case. I agree with all of this, but we can't do this entirely without breaking PM, at least until omap_hwmod is entirely gone. If we were to prevent omap_hwmod from touching any dt node marked as disabled, then we aren't going to be able to idle all IPs. omap_hwmod/omap_device handles idling of unused IPs, and we many times need the SYSCONFIG register to do that, so we can't ignore ALL disabled dt nodes until that system is replaced. I dont think it's reasonable to ask people to include every single driver just to get PM. But, this is far beyond the scope of what this patch is trying to solve. Oh OK, I think you're right. I was thinking of omap_device_build_from_dt(), sorry. Looks like the hwmod IO address data does get populated even for status = disabled although the dev entry won't get created and omap_device_build_from_dt() never gets called. Normally this is fine regardless of whether or not we are using an IP because the module will wake up for a moment, have it's sysc programmed, and then be put back to sleep later, potentially never to be woken again if we bind no driver for it, which is fine for 99% of cases. In the case of am43x epos evm, you can ^^ if status=disabled/failed there will be no device and no driver will have been bound :) take the same piece of silicon that will boot happily on the gp evm with the rtc hwmod in place and it will hang during boot on the epos evm because the board uses a pin to hold the RTC IP in reset. There is no way to detect this in software, the module can be turned on as normal using the clk_ctrl, but if you touch any of the IP registers you
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 03/12/15 10:20, Sebastian Andrzej Siewior wrote: On 2015-02-17 14:01:04 [-0800], Stephen Boyd wrote: diff = --- arch/arm/mach-imx/mach-imx6q.c +++ /tmp/cocci-output-11792-b62223-mach-imx6q.c @@ -211,7 +211,6 @@ static void __init imx6q_1588_init(void) * set bit IOMUXC_GPR1[21]. Or the PTP clock must be from pad * (external OSC), and we need to clear the bit. */ -clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP : IMX6Q_GPR1_ENET_CLK_SEL_PAD; gpr = syscon_regmap_lookup_by_compatible(fsl,imx6q-iomuxc-gpr); if (!IS_ERR(gpr)) Any idea how to do the comparison here? Or should we rely that the bootloader sets this properly (it managed already to select a frequency)? The phy has no clock node in current DT's so we can check this. This has been fixed by adding a clk_is_match() helper and using that to compare instead of comparing raw pointers. It would be nice if we could replace the patch with something else that doesn't require this helper though. It looks like this is static board configuration, so I wonder why we didn't just have a DT property that indicates how the gpr should be configured for this particular board. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
Re: [PATCH] media: omap3isp: hist: Move histogram DMA to DMA engine
Hi Sakari,
Thank you for the review.
On Friday 13 March 2015 01:56:32 Sakari Ailus wrote:
On Sun, Mar 08, 2015 at 11:37:55PM +0200, Laurent Pinchart wrote:
...
@@ -198,24 +177,58 @@ static void hist_dma_cb(int lch, u16 ch_status, void
*data)
static int hist_buf_dma(struct ispstat *hist)
{
dma_addr_t dma_addr = hist-active_buf-dma_addr;
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+ int ret;
if (unlikely(!dma_addr)) {
dev_dbg(hist-isp-dev, hist: invalid DMA buffer address\n);
- hist_reset_mem(hist);
- return STAT_NO_BUF;
+ goto error;
}
isp_reg_writel(hist-isp, 0, OMAP3_ISP_IOMEM_HIST, ISPHIST_ADDR);
isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_CNT,
ISPHIST_CNT_CLEAR);
omap3isp_flush(hist-isp);
- hist-dma_config.dst_start = dma_addr;
- hist-dma_config.elem_count = hist-buf_size / sizeof(u32);
- omap_set_dma_params(hist-dma_ch, hist-dma_config);
- omap_start_dma(hist-dma_ch);
+ memset(cfg, 0, sizeof(cfg));
+ cfg.src_addr = hist-isp-mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
++ ISPHIST_DATA;
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.src_maxburst = hist-buf_size / 4;
How about initialising the struct when you declare it instead? That might be
a matter of opinion though, but I think I prefer that. Up to you.
I sometimes agree with this argument, but in this case the separation between
initialization and usage of the structure would in my opinion impede
readability.
I've also checked the code generated by the compiler, and except for memset
being replaced by __memzero, initializing the structure at declaration time
doesn't make a difference.
Acked-by: Sakari Ailus sakari.ai...@iki.fi
--
Regards,
Laurent Pinchart
--
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
[PATCH v6 5/6] ARM: dts: add wl12xx/wl18xx bindings
Replace all the pdata-quirks for setting wl12xx/wl18xx
platform data with proper DT definitions.
The patch was compile-tested only.
Signed-off-by: Eliad Peller el...@wizery.com
---
v6: add wl12xx definitions as well
arch/arm/boot/dts/am335x-evmsk.dts | 11
arch/arm/boot/dts/omap3-cm-t3517.dts | 10
arch/arm/boot/dts/omap3-cm-t3730.dts | 10
arch/arm/boot/dts/omap3-evm-common.dtsi| 10
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 +++
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 +++
arch/arm/boot/dts/omap3-zoom3.dts | 10
arch/arm/boot/dts/omap4-panda-common.dtsi | 10
arch/arm/boot/dts/omap4-sdp.dts| 11
arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi | 10
arch/arm/mach-omap2/pdata-quirks.c | 79 --
11 files changed, 100 insertions(+), 79 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index df5fee6..87fc7a3 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -15,6 +15,7 @@
#include am33xx.dtsi
#include dt-bindings/pwm/pwm.h
+#include dt-bindings/interrupt-controller/irq.h
/ {
model = TI AM335x EVM-SK;
@@ -647,6 +648,16 @@
cap-power-off-card;
pinctrl-names = default;
pinctrl-0 = mmc2_pins;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1271;
+ reg = 2;
+ interrupt-parent = gpio1;
+ interrupts = 31 IRQ_TYPE_LEVEL_HIGH; /* gpio 31 */
+ ref-clock-frequency = 3840;
+ };
};
mcasp1 {
diff --git a/arch/arm/boot/dts/omap3-cm-t3517.dts
b/arch/arm/boot/dts/omap3-cm-t3517.dts
index 0ab748c..f5b5a1d 100644
--- a/arch/arm/boot/dts/omap3-cm-t3517.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3517.dts
@@ -133,6 +133,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1271;
+ reg = 2;
+ interrupt-parent = gpio5;
+ interrupts = 17 IRQ_TYPE_LEVEL_HIGH; /* gpio 145 */
+ ref-clock-frequency = 3840;
+ };
};
dss {
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
b/arch/arm/boot/dts/omap3-cm-t3730.dts
index 46eadb2..2294f5b 100644
--- a/arch/arm/boot/dts/omap3-cm-t3730.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -73,6 +73,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1271;
+ reg = 2;
+ interrupt-parent = gpio5;
+ interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio 136 */
+ ref-clock-frequency = 3840;
+ };
};
dss {
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 127f3e7..346552b 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -106,6 +106,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1271;
+ reg = 2;
+ interrupt-parent = gpio5;
+ interrupts = 21 IRQ_TYPE_LEVEL_HIGH; /* gpio 149 */
+ ref-clock-frequency = 3840;
+ };
};
twl_gpio {
diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index cc8bd0c..72f7cdc 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -42,4 +42,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1835;
+ reg = 2;
+ interrupt-parent = gpio6;
+ interrupts = 17 IRQ_TYPE_LEVEL_HIGH; /* gpio 177 */
+ };
};
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 9326b28..b899e34 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -64,4 +64,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1835;
+ reg = 2;
+ interrupt-parent = gpio5;
+ interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio 136 */
+ };
};
diff --git a/arch/arm/boot/dts/omap3-zoom3.dts
b/arch/arm/boot/dts/omap3-zoom3.dts
index 6644f51..131448d 100644
---
[PATCH v6 1/6] wlcore: set irq_trigger in board files instead of hiding behind a quirk
From: Luciano Coelho l...@coelho.fi
The platform_quirk element in the platform data was used
to change the way the IRQ is triggered. When set,
the EDGE_IRQ quirk would change the irqflags used
and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk,
have the board files set the irq_trigger explicitly.
This will allow us to use standard irq DT definitions
later on.
Signed-off-by: Luciano Coelho l...@coelho.fi
[Eliad - rebase, add irq_trigger field and pass it,
update board file changes]
Signed-off-by: Eliad Peller el...@wizery.com
---
arch/arm/mach-davinci/board-da850-evm.c | 2 +-
arch/arm/mach-omap2/pdata-quirks.c | 1 +
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/main.c| 27 ---
drivers/net/wireless/ti/wlcore/sdio.c| 2 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 5 ++---
include/linux/wl12xx.h | 5 +
7 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 6b5a97d..916589c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1385,8 +1385,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+ .irq_trigger= IRQ_TYPE_EDGE_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..4449f4c 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -48,6 +48,7 @@ static void __init __used legacy_init_wl12xx(unsigned
ref_clock,
wl12xx.board_ref_clock = ref_clock;
wl12xx.board_tcxo_clock = tcxo_clock;
wl12xx.irq = gpio_to_irq(gpio);
+ wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
res = wl12xx_set_platform_data(wl12xx);
if (res) {
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c
b/drivers/net/wireless/ti/wlcore/debugfs.c
index 68f3bf2..eb43f94 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -502,7 +502,7 @@ static ssize_t driver_state_read(struct file *file, char
__user *user_buf,
DRIVER_STATE_PRINT_HEX(irq);
/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
DRIVER_STATE_PRINT_HEX(hw_pg_ver);
- DRIVER_STATE_PRINT_HEX(platform_quirks);
+ DRIVER_STATE_PRINT_HEX(irq_flags);
DRIVER_STATE_PRINT_HEX(chip.id);
DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 1e13699..67518f6 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -27,6 +27,7 @@
#include linux/vmalloc.h
#include linux/wl12xx.h
#include linux/interrupt.h
+#include linux/irq.h
#include wlcore.h
#include debug.h
@@ -538,7 +539,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
* In case edge triggered interrupt must be used, we cannot iterate
* more than once without introducing race conditions with the hardirq.
*/
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+ if (wl-irq_flags (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING))
loopcount = 1;
wl1271_debug(DEBUG_IRQ, IRQ work);
@@ -6249,7 +6250,6 @@ struct ieee80211_hw *wlcore_alloc_hw(size_t priv_size,
u32 aggr_buf_size,
wl-ap_ps_map = 0;
wl-ap_fw_ps_map = 0;
wl-quirks = 0;
- wl-platform_quirks = 0;
wl-system_hlid = WL12XX_SYSTEM_HLID;
wl-active_sta_count = 0;
wl-active_link_count = 0;
@@ -6391,7 +6391,8 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
struct platform_device *pdev = wl-pdev;
struct wlcore_platdev_data *pdev_data = dev_get_platdata(pdev-dev);
struct wl12xx_platform_data *pdata = pdev_data-pdata;
- unsigned long irqflags;
+ struct resource *res;
+
int ret;
irq_handler_t hardirq_fn = NULL;
@@ -6418,19 +6419,23 @@ static void wlcore_nvs_cb(const struct firmware *fw,
void *context)
/* adjust some runtime configuration parameters */
wlcore_adjust_conf(wl);
- wl-irq = platform_get_irq(pdev, 0);
- wl-platform_quirks = pdata-platform_quirks;
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res) {
+ wl1271_error(Could not get IRQ resource);
+ goto out_free_nvs;
+ }
+
+ wl-irq = res-start;
+ wl-irq_flags = res-flags IRQF_TRIGGER_MASK;
[PATCH v6 6/6] wlcore: remove wl12xx_platform_data
Now that we have wlcore device-tree bindings in place
(for both wl12xx and wl18xx), remove the legacy
wl12xx_platform_data struct, and move its members
into the platform device data (that is passed to wlcore)
Davinci 850 is the only platform that still set
the platform data in the legacy way (and doesn't
have DT bindings), so remove the relevant
code/Kconfig option from the board file (as suggested
by Sekhar Nori)
Signed-off-by: Luciano Coelho l...@coelho.fi
Signed-off-by: Eliad Peller el...@wizery.com
---
arch/arm/mach-davinci/Kconfig | 11 ---
arch/arm/mach-davinci/board-da850-evm.c| 113 -
drivers/net/wireless/ti/wilink_platform_data.c | 25 --
drivers/net/wireless/ti/wl12xx/main.c | 19 ++---
drivers/net/wireless/ti/wlcore/boot.c | 1 -
drivers/net/wireless/ti/wlcore/main.c | 4 +-
drivers/net/wireless/ti/wlcore/sdio.c | 75 +---
drivers/net/wireless/ti/wlcore/wlcore_i.h | 8 +-
include/linux/wl12xx.h | 25 --
9 files changed, 36 insertions(+), 245 deletions(-)
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 584e8d4..6bb1049 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -198,17 +198,6 @@ config DA850_UI_SD_VIDEO_PORT
endchoice
-config DA850_WL12XX
- bool AM18x wl1271 daughter board
- depends on MACH_DAVINCI_DA850_EVM
- help
- The wl1271 daughter card for AM18x EVMs is a combo wireless
- connectivity add-on card, based on the LS Research TiWi module with
- Texas Instruments' wl1271 solution.
- Say Y if you want to use a wl1271 expansion card connected to the
- AM18x EVM.
-
-
config MACH_MITYOMAPL138
bool Critical Link MityDSP-L138/MityARM-1808 SoM
depends on ARCH_DAVINCI_DA850
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 853b941..1ed545c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,7 +38,6 @@
#include linux/regulator/fixed.h
#include linux/spi/spi.h
#include linux/spi/flash.h
-#include linux/wl12xx.h
#include mach/common.h
#include mach/cp_intc.h
@@ -60,9 +59,6 @@
#define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
-#define DA850_WLAN_EN GPIO_TO_PIN(6, 9)
-#define DA850_WLAN_IRQ GPIO_TO_PIN(6, 10)
-
#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
static struct mtd_partition da850evm_spiflash_part[] = {
@@ -1343,110 +1339,6 @@ static __init void da850_vpif_init(void)
static __init void da850_vpif_init(void) {}
#endif
-#ifdef CONFIG_DA850_WL12XX
-
-static void wl12xx_set_power(int index, bool power_on)
-{
- static bool power_state;
-
- pr_debug(Powering %s wl12xx, power_on ? on : off);
-
- if (power_on == power_state)
- return;
- power_state = power_on;
-
- if (power_on) {
- /* Power up sequence required for wl127x devices */
- gpio_set_value(DA850_WLAN_EN, 1);
- usleep_range(15000, 15000);
- gpio_set_value(DA850_WLAN_EN, 0);
- usleep_range(1000, 1000);
- gpio_set_value(DA850_WLAN_EN, 1);
- msleep(70);
- } else {
- gpio_set_value(DA850_WLAN_EN, 0);
- }
-}
-
-static struct davinci_mmc_config da850_wl12xx_mmc_config = {
- .set_power = wl12xx_set_power,
- .wires = 4,
- .max_freq = 2500,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_NONREMOVABLE |
- MMC_CAP_POWER_OFF_CARD,
-};
-
-static const short da850_wl12xx_pins[] __initconst = {
- DA850_MMCSD1_DAT_0, DA850_MMCSD1_DAT_1, DA850_MMCSD1_DAT_2,
- DA850_MMCSD1_DAT_3, DA850_MMCSD1_CLK, DA850_MMCSD1_CMD,
- DA850_GPIO6_9, DA850_GPIO6_10,
- -1
-};
-
-static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
- .irq= -1,
- .irq_trigger= IRQ_TYPE_EDGE_RISING,
- .ref_clock_freq = 3840,
- .ref_clock_xtal = false,
-};
-
-static __init int da850_wl12xx_init(void)
-{
- int ret;
-
- ret = davinci_cfg_reg_list(da850_wl12xx_pins);
- if (ret) {
- pr_err(wl12xx/mmc mux setup failed: %d\n, ret);
- goto exit;
- }
-
- ret = da850_register_mmcsd1(da850_wl12xx_mmc_config);
- if (ret) {
- pr_err(wl12xx/mmc registration failed: %d\n, ret);
- goto exit;
- }
-
- ret = gpio_request_one(DA850_WLAN_EN, GPIOF_OUT_INIT_LOW, wl12xx_en);
- if (ret) {
- pr_err(Could not request wl12xx enable gpio: %d\n, ret);
- goto exit;
- }
-
- ret =
[PATCH v6 0/6] wlcore: add device-tree support
Add device-tree support to the wlcore (wl12xx/wl18xx) driver. Update the current users to use the bindings instead of pdata-quirks. Finally, remove the deprecated wl12xx_platform_data struct (along with the da850 board file code that still uses it) NOTE: all the platform patches were compile-tested only. I'm looking for some wl12xx card (that i should have somewhere) to test the wl12xx changes (wrt. clocks), but haven't found it yet. v6: * Add Luca's patches to pass irq_trigger/freq * Support wl12xx as well * Update all relevant platforms Eliad Peller (4): dt: bindings: add TI's wilink wireless device wlcore: add device-tree support ARM: dts: add wl12xx/wl18xx bindings wlcore: remove wl12xx_platform_data Luciano Coelho (2): wlcore: set irq_trigger in board files instead of hiding behind a quirk wl12xx: use frequency instead of enumerations for pdata clocks .../devicetree/bindings/net/wireless/ti,wlcore.txt | 47 + arch/arm/boot/dts/am335x-evmsk.dts | 11 ++ arch/arm/boot/dts/omap3-cm-t3517.dts | 10 ++ arch/arm/boot/dts/omap3-cm-t3730.dts | 10 ++ arch/arm/boot/dts/omap3-evm-common.dtsi| 10 ++ arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 ++ arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 ++ arch/arm/boot/dts/omap3-zoom3.dts | 10 ++ arch/arm/boot/dts/omap4-panda-common.dtsi | 10 ++ arch/arm/boot/dts/omap4-sdp.dts| 11 ++ arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi | 10 ++ arch/arm/mach-davinci/Kconfig | 11 -- arch/arm/mach-davinci/board-da850-evm.c| 112 - arch/arm/mach-omap2/pdata-quirks.c | 79 --- drivers/net/wireless/ti/wilink_platform_data.c | 25 - drivers/net/wireless/ti/wl12xx/main.c | 63 ++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 ++ drivers/net/wireless/ti/wlcore/boot.c | 1 - drivers/net/wireless/ti/wlcore/debugfs.c | 2 +- drivers/net/wireless/ti/wlcore/main.c | 31 +++--- drivers/net/wireless/ti/wlcore/sdio.c | 64 ++-- drivers/net/wireless/ti/wlcore/wlcore.h| 5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h | 8 +- include/linux/wl12xx.h | 49 - 24 files changed, 313 insertions(+), 312 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt -- 1.8.5.2.229.g4448466.dirty -- 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
[PATCH v6 3/6] dt: bindings: add TI's wilink wireless device
Add device tree binding documentation for TI's wilink
(wl12xx and wl18xx) wlan chip.
Signed-off-by: Eliad Peller el...@wizery.com
---
v6: add wl12xx, use IRQ_TYPE_LEVEL_HIGH
.../devicetree/bindings/net/wireless/ti,wlcore.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
new file mode 100644
index 000..2a3d90d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
@@ -0,0 +1,47 @@
+TI Wilink 6/7/8 (wl12xx/wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible: should be one of the following:
+* ti,wl1271
+* ti,wl1273
+* ti,wl1281
+* ti,wl1283
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+ device interrupts are connected.
+ - ref-clock-frequency : ref clock frequency in Hz
+ - tcxo-clock-frequency : tcxo clock frequency in Hz
+
+Note: the *-clock-frequency properties assume internal clocks. In case of
external
+clock, new bindings (for parsing the clock nodes) have to be added.
+
+Example:
+
+mmc3 {
+ status = okay;
+ vmmc-supply = wlan_en_reg;
+ bus-width = 4;
+ cap-power-off-card;
+ keep-power-in-suspend;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1835;
+ reg = 2;
+ interrupt-parent = gpio0;
+ interrupts = 19 IRQ_TYPE_LEVEL_HIGH;
+ };
+};
--
1.8.5.2.229.g4448466.dirty
--
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
[PATCH v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks
From: Luciano Coelho l...@coelho.fi
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Signed-off-by: Luciano Coelho l...@coelho.fi
[Eliad - small fixes, update board file changes]
Signed-off-by: Eliad Peller el...@wizery.com
---
arch/arm/mach-davinci/board-da850-evm.c | 3 +-
arch/arm/mach-omap2/pdata-quirks.c | 29
drivers/net/wireless/ti/wl12xx/main.c | 60 ++---
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +++
include/linux/wl12xx.h | 27 ++-
5 files changed, 103 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 916589c..853b941 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1386,7 +1386,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_trigger= IRQ_TYPE_EDGE_RISING,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 4449f4c..337cc22 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -39,14 +39,14 @@ static struct twl4030_gpio_platform_data twl_gpio_auxdata;
static struct wl12xx_platform_data wl12xx __initdata;
-static void __init __used legacy_init_wl12xx(unsigned ref_clock,
-unsigned tcxo_clock,
+static void __init __used legacy_init_wl12xx(u32 ref_clock_freq,
+u32 tcxo_clock_freq,
int gpio)
{
int res;
- wl12xx.board_ref_clock = ref_clock;
- wl12xx.board_tcxo_clock = tcxo_clock;
+ wl12xx.ref_clock_freq = ref_clock_freq;
+ wl12xx.tcxo_clock_freq = tcxo_clock_freq;
wl12xx.irq = gpio_to_irq(gpio);
wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
@@ -57,8 +57,8 @@ static void __init __used legacy_init_wl12xx(unsigned
ref_clock,
}
}
#else
-static inline void legacy_init_wl12xx(unsigned ref_clock,
- unsigned tcxo_clock,
+static inline void legacy_init_wl12xx(u32 ref_clock_freq,
+ u32 tcxo_clock_freq,
int gpio)
{
}
@@ -130,7 +130,7 @@ static void __init omap3_sbc_t3730_twl_init(void)
static void __init omap3_sbc_t3730_legacy_init(void)
{
omap3_sbc_t3x_usb_hub_init(167, sb-t35 usb hub);
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136);
+ legacy_init_wl12xx(3840, 0, 136);
}
static void __init omap3_sbc_t3530_legacy_init(void)
@@ -174,12 +174,12 @@ static void __init omap3_igep0030_rev_g_legacy_init(void)
static void __init omap3_evm_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
+ legacy_init_wl12xx(3840, 0, 149);
}
static void __init omap3_zoom_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
+ legacy_init_wl12xx(2600, 0, 162);
}
static void am35xx_enable_emac_int(void)
@@ -246,7 +246,7 @@ static void __init omap3_sbc_t3517_legacy_init(void)
am35xx_emac_reset();
hsmmc2_internal_input_clk();
omap3_sbc_t3517_wifi_init();
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
+ legacy_init_wl12xx(3840, 0, 145);
}
static void __init am3517_evm_legacy_init(void)
@@ -291,18 +291,17 @@ static void __init omap3_tao3530_legacy_init(void)
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_26,
- WL12XX_TCXOCLOCK_26, 53);
+ legacy_init_wl12xx(2600, 2600, 53);
}
static void __init omap4_panda_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
+ legacy_init_wl12xx(3840, 0, 53);
}
static void __init var_som_om44_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41);
+ legacy_init_wl12xx(3840, 0, 41);
}
#endif
@@ -317,7 +316,7 @@ static struct iommu_platform_data omap4_iommu_pdata = {
#ifdef CONFIG_SOC_AM33XX
static void __init am335x_evmsk_legacy_init(void)
{
- legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 31);
+ legacy_init_wl12xx(3840, 0, 31);
}
#endif
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 144d1f8..b3f751f 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++
[PATCH v6 4/6] wlcore: add device-tree support
When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.
Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
v6: parse frequency properties, add wl12xx compatible strings
drivers/net/wireless/ti/wlcore/sdio.c | 93 ---
1 file changed, 87 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2bce00a..b55dc0e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
#include wlcore.h
#include wl12xx_80211.h
@@ -214,6 +216,82 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+ { .compatible = ti,wl1271 },
+ { .compatible = ti,wl1273 },
+ { .compatible = ti,wl1281 },
+ { .compatible = ti,wl1283 },
+ { .compatible = ti,wl1801 },
+ { .compatible = ti,wl1805 },
+ { .compatible = ti,wl1807 },
+ { .compatible = ti,wl1831 },
+ { .compatible = ti,wl1835 },
+ { .compatible = ti,wl1837 },
+ { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct wl12xx_platform_data *pdata;
+
+ if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+ return NULL;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ pdata-irq = irq_of_parse_and_map(np, 0);
+ if (!pdata-irq) {
+ dev_err(dev, No irq in platform data\n);
+ kfree(pdata);
+ return NULL;
+ }
+
+ pdata-irq_trigger =
+ irqd_get_trigger_type(irq_get_irq_data(pdata-irq));
+
+ /* optional clock frequency params */
+ of_property_read_u32(np, ref-clock-frequency,
+pdata-ref_clock_freq);
+ of_property_read_u32(np, tcxo-clock-frequency,
+pdata-tcxo_clock_freq);
+
+ return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+ struct wl12xx_platform_data *pdata;
+
+ /* first, look for DT data */
+ pdata = wlcore_probe_of(dev);
+ if (pdata)
+ return pdata;
+
+ /* if not found - fallback to static platform data */
+ pdata = wl12xx_get_platform_data();
+ if (!IS_ERR(pdata))
+ return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+ dev_err(dev, No platform data set\n);
+ return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+ kfree(pdata);
+}
+
static int wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -245,12 +323,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
- pdev_data.pdata = wl12xx_get_platform_data();
- if (IS_ERR(pdev_data.pdata)) {
- ret = PTR_ERR(pdev_data.pdata);
- dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+ pdev_data.pdata = wlcore_get_platform_data(func-dev);
+ if (!pdev_data.pdata)
goto out_free_glue;
- }
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +354,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
- goto out_free_glue;
+ goto out_free_pdata;
}
glue-core-dev.parent = func-dev;
@@ -313,6 +388,9 @@ static int wl1271_probe(struct sdio_func *func,
out_dev_put:
platform_device_put(glue-core);
+out_free_pdata:
+ wlcore_del_platform_data(pdev_data.pdata);
+
out_free_glue:
kfree(glue);
@@ -323,11 +401,14 @@ out:
static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+ struct wl12xx_platform_data *pdata = pdev_data-pdata;
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
platform_device_unregister(glue-core);
+ wlcore_del_platform_data(pdata);
kfree(glue);
}
Re: [PATCH v8 2/4] hwspinlock/core: add device tree support
On Wed 04 Mar 18:01 PST 2015, Suman Anna wrote: This patch adds a new OF-friendly API of_hwspin_lock_get_id() for hwspinlock clients to use/request locks from a hwspinlock device instantiated through a device-tree blob. This new API can be used by hwspinlock clients to get the id for a specific lock using the phandle + args specifier, so that it can be requested using the available hwspin_lock_request_specific() API. Signed-off-by: Suman Anna s-a...@ti.com Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com Regards, Bjorn -- 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
[PATCH] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch does the following:
1: adds DT node for fixed oscillator.
2: adds DT node entries for ov2659 sensor
3: adds remote-endpoint entry for VPFE.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Note this patch depends on
https://patchwork.kernel.org/patch/6000161/
arch/arm/boot/dts/am437x-gp-evm.dts | 42 +++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index f84d971..195f452 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -106,6 +106,14 @@
};
};
};
+
+ /* fixed 12MHz oscillator */
+ refclk: oscillator {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+ };
+
};
am43xx_pinmux {
@@ -404,6 +412,21 @@
regulator-always-on;
};
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe1_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
i2c1 {
@@ -423,6 +446,21 @@
touchscreen-size-x = 1024;
touchscreen-size-y = 600;
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_1: endpoint {
+ remote-endpoint = vpfe0_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
epwmss0 {
@@ -626,7 +664,7 @@
port {
vpfe0_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_1;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
@@ -643,7 +681,7 @@
port {
vpfe1_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_0;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
--
2.1.0
--
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
Re: [PATCH] media: omap3isp: hist: Move histogram DMA to DMA engine
Hi Laurent,
On Sun, Mar 08, 2015 at 11:37:55PM +0200, Laurent Pinchart wrote:
...
@@ -198,24 +177,58 @@ static void hist_dma_cb(int lch, u16 ch_status, void
*data)
static int hist_buf_dma(struct ispstat *hist)
{
dma_addr_t dma_addr = hist-active_buf-dma_addr;
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+ int ret;
if (unlikely(!dma_addr)) {
dev_dbg(hist-isp-dev, hist: invalid DMA buffer address\n);
- hist_reset_mem(hist);
- return STAT_NO_BUF;
+ goto error;
}
isp_reg_writel(hist-isp, 0, OMAP3_ISP_IOMEM_HIST, ISPHIST_ADDR);
isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_CNT,
ISPHIST_CNT_CLEAR);
omap3isp_flush(hist-isp);
- hist-dma_config.dst_start = dma_addr;
- hist-dma_config.elem_count = hist-buf_size / sizeof(u32);
- omap_set_dma_params(hist-dma_ch, hist-dma_config);
- omap_start_dma(hist-dma_ch);
+ memset(cfg, 0, sizeof(cfg));
+ cfg.src_addr = hist-isp-mmio_base_phys[OMAP3_ISP_IOMEM_HIST]
+ + ISPHIST_DATA;
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.src_maxburst = hist-buf_size / 4;
How about initialising the struct when you declare it instead? That might be
a matter of opinion though, but I think I prefer that. Up to you.
Acked-by: Sakari Ailus sakari.ai...@iki.fi
+ ret = dmaengine_slave_config(hist-dma_ch, cfg);
+ if (ret 0) {
+ dev_dbg(hist-isp-dev,
+ hist: DMA slave configuration failed\n);
+ goto error;
+ }
+
+ tx = dmaengine_prep_slave_single(hist-dma_ch, dma_addr,
+ hist-buf_size, DMA_DEV_TO_MEM,
+ DMA_CTRL_ACK);
+ if (tx == NULL) {
+ dev_dbg(hist-isp-dev,
+ hist: DMA slave preparation failed\n);
+ goto error;
+ }
+
+ tx-callback = hist_dma_cb;
+ tx-callback_param = hist;
+ cookie = tx-tx_submit(tx);
+ if (dma_submit_error(cookie)) {
+ dev_dbg(hist-isp-dev, hist: DMA submission failed\n);
+ goto error;
+ }
+
+ dma_async_issue_pending(hist-dma_ch);
return STAT_BUF_WAITING_DMA;
+
+error:
+ hist_reset_mem(hist);
+ return STAT_NO_BUF;
}
static int hist_buf_pio(struct ispstat *hist)
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
* Linus Walleij linus.wall...@linaro.org [150310 03:39]:
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under pinctrl-single,pins
+
+dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins =
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+ 0x1a4 (A_DELAY(265) | G_DELAY(360)) /*
CFG_GPMC_A20_IN */
+ 0x1b0 (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A21_IN */
+ 0x1bc (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A22_IN */
+ 0x1c8 (A_DELAY(287) | G_DELAY(420)) /*
CFG_GPMC_A23_IN */
+ 0x1d4 (A_DELAY(144) | G_DELAY(240)) /*
CFG_GPMC_A24_IN */
+ 0x1e0 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_A25_IN */
+ 0x1ec (A_DELAY(120) | G_DELAY(0)) /*
CFG_GPMC_A26_IN */
+ 0x1f8 (A_DELAY(120) | G_DELAY(180)) /*
CFG_GPMC_A27_IN */
+ 0x360 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_CS1_IN */
+ ;
+ };
+};
But wait.
The promise when we merged pinctrl-single was that this driver was to be used
when the system had a one-register-per-pin layout and it was easy to do device
trees based on that.
We were very reluctant to accept that even though we didn't even have the
generic pin control bindings in place, the argument being that the driver
should know the detailed register layout, it should not be described in the
device tree. We eventually caved in and accepted it as an exception.
Hey let's get few things straight here. There's nothing stopping the
driver from knowing a detailed register layout with the pinctrl-single
binding. This can be very easily done based on the compatible flag and
match data as needed and check the values provided.
And let's also recap the reasons for the pinctrl-single binding. The
the main reason for the pinctrl-single binding is to avoid mapping
individual register bits to device tree compatible string properties.
Imagine doing that for hundreds of similar registers. Believe me, I tried
using device tree properties initially and it just sucked big time. For
larger amounts of dts data, it's best to stick to numeric values and
phandles in the device tree data and rely on the preprocessor for
getting the values right.
Finally, we don't want to build databases into the kernel drivers for
every SoC. We certainly have plenty fo those already.
Since this pin controller is not using pinctrl-single it does not enjoy that
privilege and you need to explain why this pin controller cannot use the
generic bindings like so many other pin controllers have since started
to do. (It is in the same SoC is not an acceptable argument.)
What is wrong with this:
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Nishanth, care to explain your reasons for using pinctrl-single binding
here vs the generic binding? Is the amount of string parsing with the
data an issue here?
We can add generic delay bindings to the list, it even seems like
a good idea to do so, as it is likely something that will come up in
other hardware and will be needed for ACPI etc going forward.
We certainly need to make setting delays (with values) generic, no
doubt about that.
If the large amount of data is not an issue here, we could maybe set
each iodelay register as a separate device? Then the binding could
be just along the interrupts-extended type binding:
foo = bar 0x18c A_DELAY(0) G_DELAY(120);
Where the 0x18c is the instance offset of the register within the
ti,dra7-iodelay compatible controller.
Regards,
Tony
--
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
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote: On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote: On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote: I was expecting you to remove all calls to legacy_init_wl12xx from this file, including the ones for wl12xx aside from the wl18xx ones you removed, but if that's enough to clean out the platform_data handling from the wlcore driver, it's good enough as a start. not sure i'm following - can you elaborate? i'll summarize the way i see it. please correct me if i'm wrong. both wl18xx and wl12xx use the platform data to get the irq number. wl12xx (only) also needs some additional clock definitions to be passed. there's currently some issue with specifying some the of clock sources, so i preferred starting only with (the simpler) wl18xx bindings. for platforms with wl18xx, we can remove the pdata-quirk, as all the data (i.e. irq) can be passed by the new DT bindings. however, for platforms with wl12xx, we still need to pass the clock definitions (along with the irq), so we have to keep legacy_init_wl12xx for the time being (and that's also why we have to currently keep the platform_data handling in the wlcore driver) do you have something else in mind? I think what Arnd is saying is we've now removed all the wl12xx using legacy platforms, so all of them can boot with just data from dts. Right, that was my idea. I don't think that's the case (unless i'm missing something). e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which initializes wl12xx device. This one is just like the igep0030, as Tony was saying: the board boots from device tree already, so now that we have a binding for it, we can remove the wl12xx_set_platform_data() for it. i think the wl12xx_set_platform_data() name created some confusion - it is used to pass platform data for both wl12xx and wl18xx devices. (this confusion is all around the wlcore driver as well, due to the code evolution) the binding i added is for wl18xx only (there is no wl12xx binding yet). the remaining boards, AFAICT, have wl12xx (rather than wl18xx) cards. so i don't see how we can remove these wl12xx_set_platform_data() calls before we have wl12xx bindings in-place as well. What is missing for that binding then? I keep getting confused here, but I thought that they share the implementation that looks at the platform data. Arnd -- 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
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
On Monday 09 March 2015 23:03:30 Eliad Peller wrote:
On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -64,4 +64,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ wlcore: wlcore@2 {
+ compatible = ti,wl1835;
+ reg = 2;
+ interrupt-parent = gpio5;
+ interrupts = 8 IRQ_TYPE_NONE;
+ };
Why IRQ_TYPE_NONE?
i simply mirrored the current board file (which only sets the irq number).
The irq type is set in this chunk of code from wlcore_nvs_cb:
if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ) {
irqflags = IRQF_TRIGGER_RISING;
hardirq_fn = wlcore_hardirq;
} else {
irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
}
This means you would replace the platform_quirks with setting the
correct irq type.
Arnd
--
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
Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings
* Arnd Bergmann a...@arndb.de [150310 08:48]: On Tuesday 10 March 2015 07:28:05 Tony Lindgren wrote: Oops I forgot about the omap3-sbc-t3730, so yes we have to keep the platform data a little bit longer. But nothing stopping us moving all the other ones to use a proper device tree based configuration. For all I can tell, the t3730 board file does not support wl12xx at the moment, only the dts file does. Hmm strange, it seems to configure the wlan_rst pin. Maybe there are variants with different WLAN module. But yeah, seems to be unused. That still leaves configuring all the dts users of the pdata-quirks.c legacy_init_wl12xx() with proper dts before removing it: $ git grep legacy_init_wl12xx pdata-quirks.c pdata-quirks.c:static void __init __used legacy_init_wl12xx(unsigned ref_clock, pdata-quirks.c:static inline void legacy_init_wl12xx(unsigned ref_clock, pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136); pdata-quirks.c: legacy_init_wl12xx(0, 0, 177); pdata-quirks.c: legacy_init_wl12xx(0, 0, 136); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_26, pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41); pdata-quirks.c: legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 31); If we do what Sekhar suggested and drop wl12xx support from the DA850 EVM board file, we can fix all wlcore users. I guess Sekhar knows the da850 evm status the best. So up to you guys if wl12xx is not being used on legacy da850. Regards, Tony -- 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
Re: [PATCH v5 2/3] wl18xx: add basic device-tree support
Hello Arnd,
On Wed, Mar 11, 2015 at 10:51 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 11 March 2015 01:34:19 Javier Martinez Canillas wrote:
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+ struct wl12xx_platform_data *pdata;
+
+ /* first, look for DT data */
I thought it was the opposite, that platform data should over-rule DT.
That way you can still use the data filled in
arch/arm/mach-omap2/pdata-quirks.c even after the driver supports your
new DT binding.
No, the pdata-quirks stuff for this driver must die, it was a hack
that only exists because we previously could not attach data to an
sdio function.
Ok sorry, I misunderstood and thought that the output from the
discussion in patch 3/3 was that the pdata could not still be removed
due not having a way to configure the clocks for wl12xx.
I totally agree with removing the pdata on this driver, in fact I
would go an just remove all the remaining OMAP2+ board files and
pdata-quirks completely. Most OMAP2+ boards have been converted to DT
years ago and if someone really cares about mainline support for these
boards, they can add a DTS and DT bindings for the drivers that still
needed like this one.
Best regards,
Javier
--
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
