Re: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pavel, Sakari, On 11/18/2014 05:51 PM, Pavel Machek wrote: Hi! If the hardware LED changes with one that needs different current, the block for the adp1653 stays the same, but white LED block should be updated with different value. I think that you are talking about sub nodes. Indeed I am leaning towards this type of design. I think I am :-). I agree that flash-timeout should be per led - an array, similarly as in case of iout's. Agreed about per-led, disagreed about the array. As all the fields would need arrays, and as LED system currently does not use arrays for label and linux,default-trigger, I believe we should follow existing design and model it as three devices. (It _is_ physically three devices.) Right, I missed that the leds/common.txt describes child node. I propose following modifications to the binding: Optional properties for child nodes: - iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - iout-mode-flash : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led - iout-mode-indicator : initial intensity in microamperes of the indicator LED; it is required to enable support for the indicator led - max-iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - max-iout-mode-flash : maximum intensity in microamperes of the flash LED - max-iout-mode-indicator : maximum intensity in microamperes of the indicator LED - flash-timeout : timeout in microseconds after which flash led is turned off Ok, I took a look, and iout is notation I understand, but people may have trouble with and I don't see it used anywhere else. Also... do we need both current and max-current properties? But regulators already have regulator-max-microamp property. So what about: max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) max-flash-microamp :initial intensity in microamperes of the flash LED; it is required to enable support for the flash led flash-timeout-microseconds : timeout in microseconds after which flash led is turned off If you had indicator on the same led, I guess indicator-microamp : recommended intensity in microamperes of the LED for indication ...would do? Ongoing discussion allowed me for taking a look at the indicator issue from different perspective. This is also vital for the issue of whether a v4l2-flash sub-device should be created per device or per sub-led [1]. Currently each sub-led is represented as a separate device tree sub node and the led drivers create separate LED class device for the sub nodes. What this implies is that indicator led also must be represented by the separate LED class device. This is contrary to the way how V4L2 Flash API approaches this issue, as it considers a flash device as a regulator chip driven through a bus. The API allows to set the led in torch or flash mode and implicitly assumes that there can be additional indicator led supported, which can't be turned on separately, but the drivers apply the indicator current to the indicator led when the torch or flash led is activated. I propose to create separate v4l2-flash device for the indicator led, and treat it as a regular sub-led similarly like it is done in the LED subsystem. LED Flash class driver would only add a flag LED_DEV_CAP_INDICATOR and basing on it the v4l2-flash sub-device would create only V4L2_CID_FLASH_INDICATOR_INTENSITY control for it. There could ba also additional control added: V4L2_CID_FLASH_INDICATOR_PATTERN to support the feature supported by some LED class drivers. From the media device perspective such an approach would be harmful, as the indicator led could be turned on right before strobing the flash or turning the torch on, by separate calls to different v4l2-flash sub-devices. The design described above would allow for avoiding issues I touched in the message [1]. Regarding DT documentation: I would also swap the segments of a property name to follow the convention as in case of regulator-max-microamp. Updated version: == Optional properties for child nodes: - max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) - flash-max-microamp : maximum intensity in microamperes of the flash LED; it is mandatory if the led should support the flash mode - flash-timeout-microsec : timeout in microseconds after which the flash led is turned off - indicator-pattern :
Re: [PATCH 0/3] mmc: omap_hsmmc: make more use of mmc library functionality
On 8 November 2014 00:52, NeilBrown ne...@suse.de wrote: omap_hsmmc currently duplicates some work that can be done for it by common code, and consequently does not benefit from extra functionality in that common code. In particular, mmc_of_parse and the slot-gpio library are not used. This set of patches allows omap_hsmmc to use that common functionality, and benefit from any extra devicetree parsing that it performs. The one awkward part of this change is that omap_hsmmc has an interrupt handler for 'card detect' which does more than the common code. I see three options: 1 - move that functionality into common code 2 - discard that functionality 3 - allow the common code to be configured to use a device-specific card detect interrupt. This series implements '3'. I suspect a mix of '1' and '2' would be a better choice but I know no of the history or justification for those differences. My preference would be for this series to be applied (if there are no other issues) and if there are opinions about effecting '1' or '2', they can be done with subsequent patches. Thanks, NeilBrown I like the looks of this patchset, but it needs a rebase. Kind regards Uffe --- NeilBrown (3): mmc: omap_hsmmc: remove prepare/complete system suspend support. mmc: omap_hsmmc: use slot-gpio library for gpio support. mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration. drivers/mmc/core/slot-gpio.c | 21 drivers/mmc/host/omap_hsmmc.c | 158 +--- include/linux/mmc/slot-gpio.h |2 include/linux/platform_data/mmc-omap.h |4 - 4 files changed, 47 insertions(+), 138 deletions(-) -- Signature -- 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: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi Tony, 2014-11-18 16:42 GMT+01:00 Tony Lindgren t...@atomide.com: * Enric Balletbo Serra eballe...@gmail.com [141118 01:04]: Hi Tony, 2014-11-17 19:04 GMT+01:00 Tony Lindgren t...@atomide.com: Just tested v3.18-rc5 with beagleboard xm, and the host mode enumerates the devices, then may fail with insufficient bus power at least for the WLAN device I tried with. Is this with following options ? CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set Because with these options doesn't work for me. It only works if I don't use dual role mode CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_DUAL_ROLE is not set Weird. Yes I have CONFIG_USB_MUSB_DUAL_ROLE. AFAIK there's actually no way to disable the role switching in MUSB hardware, the hardware tries to do things on it's own anyways. So it's probably best to always set it to CONFIG_USB_MUSB_DUAL_ROLE=y unless size of the code is an issue. I noticed that this only works with CONFIG_USB_MUSB_HDRC and CONFIG_TWL4030_USB built into the kernel. No luck so far with them as loadable modules for some reason. Looks like also USB gadgets fail with MUSB as modules. I found the core issue with loadable modules, we currently need to have just one platform glue layer module compiled in. I have a fix coming up for that.. It's weird, for me fails in both cases, built-in and with loadable modules. Connecting the OTG Cable Adapter with a pendrive reports [ 51.462432] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 53.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 And then polls until I disconnect the OTG Cable Adapter with the pendrive. [ 71.488983] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 71.778930] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect [ 72.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 74.088714] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_suspend Looks like the twl4030-usb is producing interrupts alright. Maybe check your MUSB configuration one more time. See the attached patch, but note you need to only select the glue layer for the CONFIG_USB_MUSB_OMAP2PLUS option and disable other glue layer module options. Checked again, and no luck. It's very weird because from the OTG point of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. Can you confirm that you're using kernel 3.18-rc5 without other patches applied ? At this moment, I don't have a Beagleboard-XM to test, I'll try to get one because at this moment I'm a bit stuck with this problem. Also, you may want to monitor the VBUS line in host mode. If the VBUS does not come up fast enough, MUSB hardware will give up as it's again trying to do things on its own. And on the 37xx EVM, I've never had any luck getting any twl4030_usb interrupts for some reason. Turns out the 37xx EVM is using an isp1507 phy instead of the twl4030 phy. The proper fix for that will be to start using the usb-nop-xceiv or phy-ulpi when we have drivers/phy/ driver for it. Right now trying to use it seems to fail with the following error: HS USB OTG: no PHY configured Regards, Tony Thanks, Enric 8 - From: Tony Lindgren t...@atomide.com Date: Mon, 17 Nov 2014 07:53:59 -0800 Subject: [PATCH] ARM: omap2plus_defconfig: Enable USB as loadable modules NOTE: Currently only one MUSB glue layer can be selected below because of the ifdefs, I'll do a fix for that. --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -270,17 +270,92 @@ CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_DYNAMIC_MINORS=y +CONFIG_USB_OTG=y CONFIG_USB_MON=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y +CONFIG_USB_MUSB_HDRC=m +CONFIG_USB_MUSB_TUSB6010=m +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_USB_MUSB_AM35X=m +CONFIG_USB_MUSB_DSPS=m CONFIG_USB_DWC3=m -CONFIG_USB_TEST=y -CONFIG_AM335X_PHY_USB=y +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_SIMPLE=m +CONFIG_USB_SERIAL_FTDI_SIO=m +CONFIG_USB_SERIAL_PL2303=m +CONFIG_USB_EMI62=m +CONFIG_USB_EMI26=m +CONFIG_USB_ADUTUX=m +CONFIG_USB_SEVSEG=m +CONFIG_USB_RIO500=m +CONFIG_USB_LEGOTOWER=m +CONFIG_USB_LCD=m +CONFIG_USB_LED=m +CONFIG_USB_CYPRESS_CY7C63=m +CONFIG_USB_CYTHERM=m +CONFIG_USB_IDMOUSE=m +CONFIG_USB_FTDI_ELAN=m +CONFIG_USB_APPLEDISPLAY=m +CONFIG_USB_SISUSBVGA=m +CONFIG_USB_SISUSBVGA_CON=y
[PATCH v2] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
3430LDP has NAND flash with 32 bytes OOB size which is sufficient to hold
BCH8 codes but the small page check introduced in
commit b491da7233d5 (mtd: nand: omap: clean-up ecc layout for BCH ecc schemes)
considers anything below 64 bytes unsuitable for BCH4/8/16. There is another
bug in that code where it doesn't skip the check for OMAP_ECC_HAM1_CODE_SW.
Get rid of that small page check code as it is insufficient and redundant
because we are checking for OOB available bytes vs ecc layout before calling
nand_scan_tail().
Fixes: b491da7233d5 (mtd: nand: omap: clean-up ecc layout for BCH ecc schemes)
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3b357e9..10d07dd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1741,13 +1741,6 @@ static int omap_nand_probe(struct platform_device *pdev)
goto return_error;
}
- /* check for small page devices */
- if ((mtd-oobsize 64) (pdata-ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
- dev_err(info-pdev-dev, small page devices are not
supported\n);
- err = -EINVAL;
- goto return_error;
- }
-
/* re-populate low-level callbacks based on xfer modes */
switch (pdata-xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
--
1.8.3.2
--
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 V2] ARM: dts: DRA7: Add node for RTC
Add node for RTC.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes since v1:
- Fixed rtc dt node label.
arch/arm/boot/dts/dra7.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..5d92562 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1075,6 +1075,15 @@
status = disabled;
};
+ rtc@48838000 {
+ compatible = ti,am3352-rtc;
+ reg = 0x48838000 0x100;
+ interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = rtcss;
+ clocks = sys_32k_ck;
+ };
+
omap_control_usb2phy1: control-phy@4a002300 {
compatible = ti,control-phy-usb2;
reg = 0x4a002300 0x4;
--
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 v5 6/7] clk: Make clk API return per-user struct clk instances
On 14 November 2014 08:06, Stephen Boyd sb...@codeaurora.org wrote: On 10/30, Tomeu Vizoso wrote: Moves clock state to struct clk_core, but takes care to change as little API as possible. struct clk_hw still has a pointer to a struct clk, which is the implementation's per-user clk instance, for backwards compatibility. The struct clk that clk_get_parent() returns isn't owned by the caller, but by the clock implementation, so the former shouldn't call clk_put() on it. Because some boards in mach-omap2 still register clocks statically, their clock registration had to be updated to take into account that the clock information is stored in struct clk_core now. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com It would be good to have Russell at least ack the clkdev bits. There's still more work to do in the future here, but Reviewed-by: Stephen Boyd sb...@codeaurora.org Thanks, Stephen. Russell, do you think we could have your ack? Regards, Tomeu -- 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 1/5] video: omapdss: Add opa362 driver
Am 13.11.2014 um 17:41 schrieb Tomi Valkeinen tomi.valkei...@ti.com:
On 13/11/14 18:25, Dr. H. Nikolaus Schaller wrote:
Hi,
Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen tomi.valkei...@ti.com:
On 13/11/14 00:10, Marek Belisko wrote:
opa362 is amplifier for video and can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
drivers/video/fbdev/omap2/displays-new/Makefile| 1 +
.../fbdev/omap2/displays-new/amplifier-opa362.c| 343
+
I think it would be better to rename this to encoder-opa362.c. It's not
When developing this driver we did simply rename the encoder-tfp410 file,
but thent hough that it does not fit into the „encoder“ category, because we
would expect something digital or digital to analog „encoding“ which it does
not.
That is true, but we already have other encoders like
encoder-tpd12s015.c, which also do not encode. encoder in this context
means something that takes a video input, and has a video output. In
contrast to a panel or a connector.
+
+ in-ops.atv-set_timings(in, ddata-timings);
+ /* fixme: should we receive the invert from our consumer, i.e. the
connector? */
+ in-ops.atv-invert_vid_out_polarity(in, true);
Well this does seem to be broken. I don't know what the answer to the
question above is, but the code doesn't work properly.
In the opa362_invert_vid_out_polarity function below, you get the invert
boolean from the connector. This you pass to the OMAP venc. However,
above you always override that value in venc with true.
So, either the invert_vid_out_polarity value has to be always true or
false, because _OPA362_ requires it to be true or false, OR you need use
the value from the connector.
Seeing the comment in opa362_invert_vid_out_polarity, my guess is the
latter, and the call above should be removed.
Yes, you are right - this is not systematic.
But the problem is that we can’t ask the connector here what it wants
to see. It might (or might not) call our opa362_invert_vid_out_polarity()
later
which we can then forward to overwrite the inital state of this
opa362_enable().
You don't need to ask. The connector calls invert_vid_out_polarity
before enabling the output.
Unfortunately it doesn’t. At least not always.
It does only for pdata systems but not for DT based systems:
if (!ddata-dev-of_node) {
in-ops.atv-set_type(in, ddata-connector_type);
in-ops.atv-invert_vid_out_polarity(in,
ddata-invert_polarity);
}
Not calling is in our case different from calling with ddata-invert_polarity
== 0.
You can just pass it forward inverted, as
you already do in this driver. If it doesn't, it's either a bug or you
can just rely on the value that is already programmed to venc.
Therefore it is not called with “false” which would make our
invert_vid_out_polarity
invert it and send “true” towards the VENC. So VENC remains non-inverted.
We will also add a patch for the connector-analog.c
We are going to support only DT boot at some point. Thus I think the
whole platform data code should be left out.
Is there already a decision? I think it should not be done before. And it
does not harm to still have it.
It's just a matter of time. I don't accept any new boards using platform
data for display, or new display drivers using platform data, because I
don't want to spend my time converting them later. And as this is a new
driver, no existing board can be using the opa362 platform_data. So we
can support DT only.
Ok, that looks reasonable - as long as we can rely on that all mainline DSS
drivers are already fully converted to DT :)
BR,
Nikolaus
--
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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Jacek and Pavel, Jacek Anaszewski wrote: Hi Pavel, Sakari, On 11/18/2014 05:51 PM, Pavel Machek wrote: Hi! If the hardware LED changes with one that needs different current, the block for the adp1653 stays the same, but white LED block should be updated with different value. I think that you are talking about sub nodes. Indeed I am leaning towards this type of design. I think I am :-). I agree that flash-timeout should be per led - an array, similarly as in case of iout's. Agreed about per-led, disagreed about the array. As all the fields would need arrays, and as LED system currently does not use arrays for label and linux,default-trigger, I believe we should follow existing design and model it as three devices. (It _is_ physically three devices.) Right, I missed that the leds/common.txt describes child node. I propose following modifications to the binding: Optional properties for child nodes: - iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - iout-mode-flash : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led - iout-mode-indicator : initial intensity in microamperes of the indicator LED; it is required to enable support for the indicator led - max-iout-mode-led : maximum intensity in microamperes of the LED (torch LED for flash devices) - max-iout-mode-flash : maximum intensity in microamperes of the flash LED - max-iout-mode-indicator : maximum intensity in microamperes of the indicator LED - flash-timeout :timeout in microseconds after which flash led is turned off Ok, I took a look, and iout is notation I understand, but people may have trouble with and I don't see it used anywhere else. Also... do we need both current and max-current properties? But regulators already have regulator-max-microamp property. So what about: max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) max-flash-microamp : initial intensity in microamperes of the flash LED; it is required to enable support for the flash led flash-timeout-microseconds : timeout in microseconds after which flash led is turned off If you had indicator on the same led, I guess indicator-microamp : recommended intensity in microamperes of the LED for indication The value for the indicator is maximum as well, not just a recommendation. ...would do? Ongoing discussion allowed me for taking a look at the indicator issue from different perspective. This is also vital for the issue of whether a v4l2-flash sub-device should be created per device or per sub-led [1]. Currently each sub-led is represented as a separate device tree sub node and the led drivers create separate LED class device for the sub nodes. What this implies is that indicator led also must be represented by the separate LED class device. This is contrary to the way how V4L2 Flash API approaches this issue, as it considers a flash device as a regulator chip driven through a bus. The API allows to set the led in torch or flash mode and implicitly assumes that there can be additional indicator led supported, which can't be turned on separately, but the drivers apply the indicator current to the indicator led when the torch or flash led is activated. The indicator is independent of the flash LED in V4L2 flash API. At least that's how it should be, and in adp1653 the two are independent, but the as3645a can't use indicator with the flash AFAIR. I propose to create separate v4l2-flash device for the indicator led, and treat it as a regular sub-led similarly like it is done in the LED subsystem. LED Flash class driver would only add a flag LED_DEV_CAP_INDICATOR and basing on it the v4l2-flash sub-device would create only V4L2_CID_FLASH_INDICATOR_INTENSITY control for it. There could ba also additional control added: V4L2_CID_FLASH_INDICATOR_PATTERN to support the feature supported by some LED class drivers. Interesting idea. The flash controller is still a single I2C device with common set of faults, for instance. Some devices refuse to work again in case of faults until they are cleared (= read). Could the indicator pattern control be present in the same sub-device? Are there any flash LED controllers that support such functionality? From the media device perspective such an approach would be harmful, as the indicator led could be turned on right before strobing the flash or turning the torch on, by separate calls to different v4l2-flash sub-devices. The design described above would allow for avoiding issues I touched in the message [1]. Let me reply this separately. Feel free to ping me if I obviously appear to miss something. -- Kind
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
* Enric Balletbo Serra eballe...@gmail.com [141119 03:14]: 2014-11-18 16:42 GMT+01:00 Tony Lindgren t...@atomide.com: Checked again, and no luck. It's very weird because from the OTG point of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. Can you confirm that you're using kernel 3.18-rc5 without other patches applied ? At this moment, I don't have a Beagleboard-XM to test, I'll try to get one because at this moment I'm a bit stuck with this problem. Yes it was with v3.18-rc5 and the defconfig patch I posted except I had to disable all the other MUSB platforms. Also tested it with built in modules. Maybe you need to check the .dts pinctrl entries for hsusb0_* lines? 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: [RFC] adp1653: Add device tree bindings for LED controller
Hi Pavel, Pavel Machek wrote: On Mon 2014-11-17 07:06:17, Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [141117 07:03]: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the binding should be added to the driver, but that removes a dependency to the legacy booting mode if things are otherwise working. Tony, legacy board code for n900 is not in mainline tree. And that omap3 camera subsystem for n900 is broken since 3.5 kernel... (both Front and Back camera on n900 show only green picture). I'm still seeing the legacy board code for n900 in mainline tree :) It's deprecated, but still there. Are you maybe talking about some other piece of platform_data that's no longer in the mainline kernel? No idea what might be wrong with the camera though. Camera support for main and secondary cameras was never mainline, AFAICT. Merging it will not be easy, as it lacks DT support... and was broken for long time. I have a smiapp patchset for DT support that I posted a while ago, here: URL:http://www.spinics.net/lists/linux-media/msg83285.html What's missing on top of that is the omap3isp support, plus something to toggle the sysctl registers based on the chosen receiver. I have a preliminary, not RFC yet but functional set here: URL:http://vihersipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/rm696-045-dt The main camera support requires et8ek8 driver as well, and resolving the breakage with the image capture on 3430. N9/N950 will be first, though. Lens controllers are another matter, but nothing too difficult on that side either. Anyway, flash is kind of important for me, since it makes phone useful as backup light; and it is simple piece of hw, so I intend to keep it useful. Me, too. :-) -- Kind regards, Sakari Ailus sakari.ai...@iki.fi -- 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: N900 modem support in 3.18-rc1
Pavel Machek pa...@ucw.cz writes: Thanks for the info. I added +Mainline has support for Mitac Mio A701, but that having only 64MiB +RAM, QTopia is the software to use there. Thanks Pavel, that looks good. Cheers. -- Robert -- 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 0/3] mmc: omap_hsmmc: make more use of mmc library functionality
On Wed, 19 Nov 2014 11:14:24 +0100 Ulf Hansson ulf.hans...@linaro.org wrote: On 8 November 2014 00:52, NeilBrown ne...@suse.de wrote: omap_hsmmc currently duplicates some work that can be done for it by common code, and consequently does not benefit from extra functionality in that common code. In particular, mmc_of_parse and the slot-gpio library are not used. This set of patches allows omap_hsmmc to use that common functionality, and benefit from any extra devicetree parsing that it performs. The one awkward part of this change is that omap_hsmmc has an interrupt handler for 'card detect' which does more than the common code. I see three options: 1 - move that functionality into common code 2 - discard that functionality 3 - allow the common code to be configured to use a device-specific card detect interrupt. This series implements '3'. I suspect a mix of '1' and '2' would be a better choice but I know no of the history or justification for those differences. My preference would be for this series to be applied (if there are no other issues) and if there are opinions about effecting '1' or '2', they can be done with subsequent patches. Thanks, NeilBrown I like the looks of this patchset, but it needs a rebase. Thanks. What should I rebase against? Is 3.18-rc sufficient or is there some other tree I should work against? Thanks, NeilBrown Kind regards Uffe --- NeilBrown (3): mmc: omap_hsmmc: remove prepare/complete system suspend support. mmc: omap_hsmmc: use slot-gpio library for gpio support. mmc: omap_hsmmc: use mmc_of_parse to parse common mmc configuration. drivers/mmc/core/slot-gpio.c | 21 drivers/mmc/host/omap_hsmmc.c | 158 +--- include/linux/mmc/slot-gpio.h |2 include/linux/platform_data/mmc-omap.h |4 - 4 files changed, 47 insertions(+), 138 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ pgpe08RBN41nG.pgp Description: OpenPGP digital signature
[PATCH 00/15] tz1090: add clock components
This patchset adds common clock framework support for the TZ1090 SoC. Patches 1 and 2 are generic and switch clk-divider to use masks internally instead of shifts and width. Patch 1 came from Mike's divider DT bindings patchset from a while back. This is required by the TZ1090 divider binding (patch 13). Patches 3 to 14 add TZ1090 clock types and associated DT bindings, specifically: * PLLs (True Circuits, but TZ1090 specific register interface) * Gate banks (a register containing clock gate bits) * Mux banks (a register containing clock mux bits) * Clock deleters (delete up to 1023 out of every 1024 clocks) * PDC clock (combined divider and mux) * Divider clock (pretty basic divider, but specific to TZ1090) Finally patch 15 defines most of the TZ1090 clocks using these components, with a few placeholders for less interesting clocks from more complex components. This is mostly for reference to give an idea how the clock components are intended to be used, and I'll take this one through the metag tree when the drivers/clk/ stuff is accepted. James Hogan (14): clk: divider: expose new clk_register_divider_mask dt: binding: add binding for tz1090-pll clock clk: tz1090: add PLL clock driver dt: binding: add binding for TZ1090 gate bank clk: tz1090: add gate bank clock driver dt: binding: add binding for TZ1090 mux bank clk: tz1090: add mux bank clock driver dt: binding: add binding for TZ1090 clock deleter clk: tz1090: add deleter clock driver dt: binding: add binding for TZ1090 PDC clock clk: tz1090: add PDC clock driver dt: binding: add binding for TZ1090 divider clock clk: tz1090: add divider clock driver metag: tz1090: add TZ1090 clocks to device tree Mike Turquette (1): clk: divider: replace bitfield width with mask .../bindings/clock/img,tz1090-deleter.txt | 40 ++ .../bindings/clock/img,tz1090-divider.txt | 37 + .../bindings/clock/img,tz1090-gate-bank.txt| 52 ++ .../bindings/clock/img,tz1090-mux-bank.txt | 56 ++ .../bindings/clock/img,tz1090-pdc-clock.txt| 44 ++ .../devicetree/bindings/clock/img,tz1090-pll.txt | 33 + arch/arm/mach-imx/clk-busy.c | 2 +- arch/arm/mach-imx/clk-fixup-div.c | 2 +- arch/metag/Kconfig.soc | 1 + arch/metag/boot/dts/tz1090.dtsi| 4 + arch/metag/boot/dts/tz1090_clk.dtsi| 784 + drivers/clk/Makefile | 1 + drivers/clk/clk-divider.c | 58 +- drivers/clk/mxs/clk-div.c | 2 +- drivers/clk/rockchip/clk.c | 2 +- drivers/clk/st/clk-flexgen.c | 4 +- drivers/clk/st/clkgen-mux.c| 4 +- drivers/clk/st/clkgen-pll.c| 2 +- drivers/clk/sunxi/clk-sunxi.c | 2 +- drivers/clk/ti/divider.c | 2 +- drivers/clk/tz1090/Makefile| 7 + drivers/clk/tz1090/clk-tz1090-deleter.c| 188 + drivers/clk/tz1090/clk-tz1090-divider.c| 96 +++ drivers/clk/tz1090/clk-tz1090-gate-bank.c | 199 ++ drivers/clk/tz1090/clk-tz1090-mux-bank.c | 191 + drivers/clk/tz1090/clk-tz1090-pdc.c| 185 + drivers/clk/tz1090/clk-tz1090-pll.c| 305 include/linux/clk-private.h| 2 +- include/linux/clk-provider.h | 7 +- 29 files changed, 2282 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-deleter.txt create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-divider.txt create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-gate-bank.txt create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-mux-bank.txt create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-pdc-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/img,tz1090-pll.txt create mode 100644 arch/metag/boot/dts/tz1090_clk.dtsi create mode 100644 drivers/clk/tz1090/Makefile create mode 100644 drivers/clk/tz1090/clk-tz1090-deleter.c create mode 100644 drivers/clk/tz1090/clk-tz1090-divider.c create mode 100644 drivers/clk/tz1090/clk-tz1090-gate-bank.c create mode 100644 drivers/clk/tz1090/clk-tz1090-mux-bank.c create mode 100644 drivers/clk/tz1090/clk-tz1090-pdc.c create mode 100644 drivers/clk/tz1090/clk-tz1090-pll.c Cc: Emilio López emi...@elopez.com.ar Cc: Heiko Stuebner he...@sntech.de Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Mark Rutland mark.rutl...@arm.com Cc: Pawel Moll pawel.m...@arm.com Cc: Rob Herring robh...@kernel.org Cc: Sascha Hauer ker...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Cc: Tero Kristo t-kri...@ti.com Cc:
[PATCH 01/15] clk: divider: replace bitfield width with mask
From: Mike Turquette mturque...@linaro.org
The forthcoming Device Tree binding for the divider clock type will use
a bitfield mask instead of bitfield width, which is what the current
basic divider implementation uses.
This patch replaces the u8 width in struct clk_divider with a u32 mask.
The divider code is updated to use the bit mask internally but the two
registration functions still accept the width to maintain compatibility
with existing users.
Also updated in this patch is the clk-private.h divider macro and
various clock divider implementations that are based on struct
clk_divider.
Signed-off-by: Mike Turquette mturque...@linaro.org
[james.ho...@imgtec.com: forward port, fix new uses of width]
Signed-off-by: James Hogan james.ho...@imgtec.com
Tested-by: Shawn Guo shawn@linaro.org
Tested-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Heiko Stuebner he...@sntech.de
Cc: Emilio López emi...@elopez.com.ar
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
---
Changes since original:
- Forward ported
- Adjust new div_mask from recent patch clk-divider: Fix READ_ONLY when
divider 1
- Updated assignment of clk_divider::width in imx, rockchip, st, sunxi,
ti clock components to use mask instead (not tested), using the
following semantic patch:
virtual context
virtual patch
@depends on context@
struct clk_divider clk;
expression e;
@@
*clk.width = e
@depends on patch@
struct clk_divider clk;
expression e;
@@
-clk.width = fls(e)
+clk.mask = e
@depends on patch@
struct clk_divider *clk;
expression e;
@@
-clk-width = fls(e)
+clk-mask = e
@depends on patch@
struct clk_divider clk;
expression e;
@@
-clk.width = e
+clk.mask = BIT(e) - 1
@depends on patch@
struct clk_divider *clk;
expression e;
@@
-clk-width = e
+clk-mask = BIT(e) - 1
---
arch/arm/mach-imx/clk-busy.c | 2 +-
arch/arm/mach-imx/clk-fixup-div.c | 2 +-
drivers/clk/clk-divider.c | 33 -
drivers/clk/mxs/clk-div.c | 2 +-
drivers/clk/rockchip/clk.c| 2 +-
drivers/clk/st/clk-flexgen.c | 4 ++--
drivers/clk/st/clkgen-mux.c | 4 ++--
drivers/clk/st/clkgen-pll.c | 2 +-
drivers/clk/sunxi/clk-sunxi.c | 2 +-
drivers/clk/ti/divider.c | 2 +-
include/linux/clk-private.h | 2 +-
include/linux/clk-provider.h | 2 +-
12 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-imx/clk-busy.c b/arch/arm/mach-imx/clk-busy.c
index 4bb1bc4..bc88e38 100644
--- a/arch/arm/mach-imx/clk-busy.c
+++ b/arch/arm/mach-imx/clk-busy.c
@@ -95,7 +95,7 @@ struct clk *imx_clk_busy_divider(const char *name, const char
*parent_name,
busy-div.reg = reg;
busy-div.shift = shift;
- busy-div.width = width;
+ busy-div.mask = BIT(width) - 1;
busy-div.lock = imx_ccm_lock;
busy-div_ops = clk_divider_ops;
diff --git a/arch/arm/mach-imx/clk-fixup-div.c
b/arch/arm/mach-imx/clk-fixup-div.c
index 21db020..af33b7a 100644
--- a/arch/arm/mach-imx/clk-fixup-div.c
+++ b/arch/arm/mach-imx/clk-fixup-div.c
@@ -115,7 +115,7 @@ struct clk *imx_clk_fixup_divider(const char *name, const
char *parent,
fixup_div-divider.reg = reg;
fixup_div-divider.shift = shift;
- fixup_div-divider.width = width;
+ fixup_div-divider.mask = BIT(width) - 1;
fixup_div-divider.lock = imx_ccm_lock;
fixup_div-divider.hw.init = init;
fixup_div-ops = clk_divider_ops;
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..a432cf8 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -30,8 +30,6 @@
#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
-#define div_mask(d)((1 ((d)-width)) - 1)
-
static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
{
unsigned int maxdiv = 0;
@@ -57,12 +55,12 @@ static unsigned int _get_table_mindiv(const struct
clk_div_table *table)
static unsigned int _get_maxdiv(struct clk_divider *divider)
{
if (divider-flags CLK_DIVIDER_ONE_BASED)
- return div_mask(divider);
+ return divider-mask;
if (divider-flags CLK_DIVIDER_POWER_OF_TWO)
- return 1 div_mask(divider);
+ return 1 divider-mask;
if (divider-table)
return _get_table_maxdiv(divider-table);
- return div_mask(divider) + 1;
+ return divider-mask + 1;
}
static unsigned int _get_table_div(const struct clk_div_table *table,
@@ -116,7 +114,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw
*hw,
unsigned int div, val;
val = clk_readl(divider-reg) divider-shift;
- val = div_mask(divider);
+ val = divider-mask;
div = _get_div(divider, val);
if (!div) {
@@ -266,7 +264,7 @@ static int
Re: [PATCHv6 5/5] hwspinlock/omap: add support for dt nodes
On Wed, Nov 12, 2014 at 11:14 AM, Ohad Ben-Cohen o...@wizery.com wrote: Hi Suman, [..] Does this mean you allow nodes not to have the base_id property? How do we protect against multiple nodes not having a base_id property then? Implicitly assuming a base_id value (zero in this case) may not be always safe. Hi Ohad, I still have a huge problem understanding the awesomeness with the base_id. If you have a SoC with 2 hwlock blocks; say 8+8 locks, used for interaction with e.g. a modem and a video core respectively. Why would you in either remote system offset the locks with 8? Wouldn't e.g the modem use locks hwlock0:0-7 and video core use locks hwlock1:0-7? What systems use more than one hwlock block and do you know of any reasons why these hwlocks are globally numbered? 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
OMAP baseline test results for v3.18-rc5
Here are some basic OMAP test results for Linux v3.18-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18-rc5/20141119185802/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc4 (206c5f60a3d902bc4b56dab2de3e88de5eb06108)): text data bsstotal kernel +736 -400 +696 omap1_defconfig +736 +240 +760 omap1_defconfig_1510innovator_only +736 -320 +704 omap1_defconfig_5912osk_only +37585 +306320 +68217 multi_v7_defconfig -313260-8928 -38696 -360884 omap2plus_defconfig -288752-8672 -38600 -336024 omap2plus_defconfig_2430sdp_only -303324-9000 -38696 -351020 omap2plus_defconfig_am33xx_only -307484-8936 -38696 -355116 omap2plus_defconfig_am43xx_only -309164-8912 -38696 -356772 omap2plus_defconfig_cpupm -303324-8936 -38696 -350956 omap2plus_defconfig_dra7xx_only -10219 -152 -64 -10435 omap2plus_defconfig_n800_multi_omap2xxx -6123 -152 -64-6339 omap2plus_defconfig_n800_only_a -309132-8904 -38696 -356732 omap2plus_defconfig_no_pm -317356-8912 -38696 -364964 omap2plus_defconfig_omap2_4_only -307420-8936 -38696 -355052 omap2plus_defconfig_omap3_4_only -307484-8944 -38696 -355124 omap2plus_defconfig_omap5_only +692 +8 -104 +596 rmk_omap3430_ldp_allnoconfig +968 -80 +960 rmk_omap3430_ldp_oldconfig +724 +12 -136 +600 rmk_omap4430_sdp_allnoconfig +644 -80 +636 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc4 (206c5f60a3d902bc4b56dab2de3e88de5eb06108)) avail rsrvd high freed board kconfig . . . 4k 2420n800 omap2plus_defconfig_n800_only_a 352k -352k . . 2430sdpomap2plus_defconfig 352k -352k .-4k 3530es31beagle omap2plus_defconfig 352k -352k .-4k 3530es3beagle
Re: [PATCHv6 5/5] hwspinlock/omap: add support for dt nodes
Hi Bjorn, On Thu, Nov 20, 2014 at 2:43 AM, Bjorn Andersson bj...@kryo.se wrote: I still have a huge problem understanding the awesomeness with the base_id. If you have a SoC with 2 hwlock blocks; say 8+8 locks, used for interaction with e.g. a modem and a video core respectively. Why would you in either remote system offset the locks with 8? Wouldn't e.g the modem use locks hwlock0:0-7 and video core use locks hwlock1:0-7? Please see below What systems use more than one hwlock block None that we know of. This concern was raised some time ago by Arnd and since it was easy to deal with we added the 'base_id' notion. and do you know of any reasons why these hwlocks are globally numbered? Because on an heterogeneous asymmetric multiprocessing systems you sometimes have use cases where hwlocks are dynamically allocated and their id numbers need to be synchronized between user space applications, the Linux kernel, and entities running on remote processors (which are likely not running Linux). For this to work we have to have some system-wide global hwlocks naming that is predefined and known to all processors. A mere number seems like the simplest naming method. A dynamic hwlock request API could return hwlock1:0 but a mere 8 seems easier to deal with. 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: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support
Hi
On Thu, 9 Oct 2014, Tomi Valkeinen wrote:
Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
parent hwmod that needs to be enabled for the child hwmod to work.
This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
This one has been updated here to add some kerneldoc documentation.
Please let me know if you have any objections.
- Paul
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 9 Oct 2014 17:03:14 +0300
Subject: [PATCH] ARM: OMAP2+: hwmod: add parent_hwmod support
Add parent_hwmod pointer to omap_hwmod. This can be set to point to a
parent hwmod that needs to be enabled for the child hwmod to work.
This is used at hwmod setup time: when doing the initial setup and
reset, first enable the parent hwmod, and after setup and reset is done,
restore the parent hwmod to postsetup_state.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reviewed-by: Archit Taneja archit.tan...@gmail.com
[p...@pwsan.com: add kerneldoc documentation for parent_hwmod; note that it
is a temporary workaround]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 22 ++
arch/arm/mach-omap2/omap_hwmod.h | 8
2 files changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index acae6d5d1151..a2c7b300fe89 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2719,11 +2719,33 @@ static int __init _setup(struct omap_hwmod *oh, void
*data)
if (oh-_state != _HWMOD_STATE_INITIALIZED)
return 0;
+ if (oh-parent_hwmod) {
+ int r;
+
+ r = _enable(oh-parent_hwmod);
+ WARN(r, hwmod: %s: setup: failed to enable parent hwmod %s\n,
+oh-name, oh-parent_hwmod-name);
+ }
+
_setup_iclk_autoidle(oh);
if (!_setup_reset(oh))
_setup_postsetup(oh);
+ if (oh-parent_hwmod) {
+ u8 postsetup_state;
+
+ postsetup_state = oh-parent_hwmod-_postsetup_state;
+
+ if (postsetup_state == _HWMOD_STATE_IDLE)
+ _idle(oh-parent_hwmod);
+ else if (postsetup_state == _HWMOD_STATE_DISABLED)
+ _shutdown(oh-parent_hwmod);
+ else if (postsetup_state != _HWMOD_STATE_ENABLED)
+ WARN(1, hwmod: %s: unknown postsetup state %d!
defaulting to enabled\n,
+oh-parent_hwmod-name, postsetup_state);
+ }
+
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 512f809a3f4d..35ca6efbec31 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -633,6 +633,7 @@ struct omap_hwmod_link {
* @flags: hwmod flags (documented below)
* @_lock: spinlock serializing operations on this hwmod
* @node: list node for hwmod list (internal use)
+ * @parent_hwmod: (temporary) a pointer to the hierarchical parent of this
hwmod
*
* @main_clk refers to this module's main clock, which for our
* purposes is defined as the functional clock needed for register
@@ -643,6 +644,12 @@ struct omap_hwmod_link {
* the omap_hwmod code and should not be set during initialization.
*
* @masters and @slaves are now deprecated.
+ *
+ * @parent_hwmod is temporary; there should be no need for it, as this
+ * information should already be expressed in the OCP interface
+ * structures. @parent_hwmod is present as a workaround until we improve
+ * handling for hwmods with multiple parents (e.g., OMAP4+ DSS with
+ * multiple register targets across different interconnects).
*/
struct omap_hwmod {
const char *name;
@@ -680,6 +687,7 @@ struct omap_hwmod {
u8 _int_flags;
u8 _state;
u8 _postsetup_state;
+ struct omap_hwmod *parent_hwmod;
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
--
2.1.3
--
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: [RFC PATCH 0/6] ARM: OMAP4+: hwmod: fixing omap4+ DSS hwmods
Hi Tomi, thanks for the ping. On Fri, 14 Nov 2014, Tomi Valkeinen wrote: On 09/10/14 17:03, Tomi Valkeinen wrote: This is an RFC to fix the issues with boot time DSS hwmod setup. There was an earlier series sent by Archit here: http://www.spinics.net/lists/linux-omap/msg107700.html This series takes different approach, and just tries to fix the issue at setup time by making sure the DSS core hwmod is enabled when a DSS submodule hwmod is being setup. Quickly tested on OMAP4 Panda and OMAP5 uEVM. Tomi Tomi Valkeinen (6): ARM: OMAP2+: hwmod: add parent_hwmod support ARM: OMAP5: hwmod: set DSS submodule parent hwmods ARM: OMAP4: hwmod: set DSS submodule parent hwmods ARM: OMAP4: hwmod: use MODULEMODE properly ARM: OMAP4: fix RFBI iclk ARM: dts: omap4.dtsi: remove dss_fck arch/arm/boot/dts/omap4.dtsi | 2 +- arch/arm/boot/dts/omap44xx-clocks.dtsi | 8 arch/arm/mach-omap2/omap_hwmod.c | 22 ++ arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 25 - arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 5 + 6 files changed, 45 insertions(+), 18 deletions(-) Ping. Would this series be acceptable? Yes, it looks good for the short term, and definitely moves us closer to where we should be. Queued with Archit's Reviewed-by:, with some extra documentation added to the first patch. If you have a spare moment, could you take a quick look at it? It should not result in any functional changes. In theory, that .parent_hwmod information should come from the omap_hwmod_ocp_if data. But as you know, unfortunately due to some limitations in the hwmod code, we don't handle IP blocks with multiple interconnect parents very well right now. Ultimately we should only have one OCP interface between each of the DSS IP blocks. But for that to work, the physical address code needs to be overhauled, and the data should be specified as offsets rather than absolute addresses. One of these days. - Paul -- 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/3] ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm
On Tue, 4 Nov 2014, Vignesh R wrote:
This patch adds hwmod support for tscadc to work on am43xx-evm. The am33xx
hwmod structures of tscadc has been moved to ipblock_data so that it can
be reused in am43xx. The clock domain names are separately set for am33xx
and am43xx. Thus tscadc dt entries can now be added to am43xx board
dt files.
Signed-off-by: Vignesh R vigne...@ti.com
...
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index 6e57b8ad0db5..b92a7c7825fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
...
+static void am33xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l4hs_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l4_wkup_clkdm);
+}
+
+static void am43xx_hwmod_clockdomain(void)
+{
+ CLKDMNAME(am33xx_l4_hs_hwmod, l3_clkdm);
+ CLKDMNAME(am33xx_adc_tsc_hwmod, l3s_tsc_clkdm);
+}
+
...
+ am33xx_hwmod_clockdomain();
I looked at this patch and the one before it. Is there some reason why we
need to share these two hwmods between AM33xx and AM43xx? It seems
cleaner just to add the ADC data directly to the AM43xx hwmod data file,
not touch the AM33xx data, and not add another runtime data update for the
clockdomains. Unless there's something that I'm missing?
- Paul
--
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: [RFC PATCH 1/6] ARM: OMAP2+: hwmod: add parent_hwmod support
Hi Paul, On 20/11/14 09:03, Paul Walmsley wrote: Hi On Thu, 9 Oct 2014, Tomi Valkeinen wrote: Add parent_hwmod pointer to omap_hwmod. This can be set to point to a parent hwmod that needs to be enabled for the child hwmod to work. This is used at hwmod setup time: when doing the initial setup and reset, first enable the parent hwmod, and after setup and reset is done, restore the parent hwmod to postsetup_state. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com This one has been updated here to add some kerneldoc documentation. Please let me know if you have any objections. Thanks, looks good to me. Sorry I missed adding the kernel doc. Tomi signature.asc Description: OpenPGP digital signature
