Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
Hi,
Am 06.01.2016 um 00:40 schrieb Nishanth Menon <n...@ti.com>:
On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
+ rtc {
+ compatible = "ti,palmas-rtc";
+ interrupt-parent = <>;
+ interrupts = <8 IRQ_TYPE_NONE>;
IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
it had none, there'd be no interrupt, right?
Well, it just translates IRQ_TYPE_NONE through
Linux/include/dt-bindings/interrupt-controller/irq.h
to
interrupts = <8 0>;
which is given as an example in
Documentation//devicetree/bindings/rtc/rtc-palmas.txt
Since I don't know anything about the rtc driver beyond the bindings
documentation I assume it is correct...
I have added Laxman Dewangan because he introduced this interrupts = <8 0>;
As this is for palmas interrupt controller, it does not use the second
field for interrupt from RTC.
So there is no really any polarity. It can be set to 0.
The second argument will be used for GPIOs mainly. However, support need
to be added on GPIO driver for rising/falling configuration.
--
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] iio:adc:palmas: add DT support
On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote: From: Marek Belisko <ma...@goldelico.com> Code was found at: https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1 Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com> [Fixed minor typos + add channels list to documentation] Signed-off-by: Marek Belisko <ma...@goldelico.com> --- Acked-by: Laxman Dewangan <ldewan...@nvidia.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: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc
On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote: This driver code was found as: https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc Fixed various compilation issues and test this driver on omap5 evm. Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com> Signed-off-by: Marek Belisko <ma...@goldelico.com> Acked-by: Laxman Dewangan <ldewan...@nvidia.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: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Monday 17 June 2013 11:16 AM, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Looks good to me. Acked-by: Laxman Dewangan ldewan...@nvidia.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: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
On Friday 14 June 2013 03:25 PM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
+ if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
+ children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
+ children[PALMAS_PMIC_ID].pdata_size =
+ sizeof(*pdata-pmic_pdata);
+ }
I think a lot of complexity here could actually be removed by removing the
old board file style probing for palmas. I do not beleive either major user
of palmas requires that anymore? I always had in my mind that this bit
was temporary.
Completely agree, we should not have this. Also this is not valid much
in DT context and so we can remove it.
--
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/2] ARM: dts: add dtsi for palmas
On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd Most of time we refer from this document for dt population. Thanks, Laxman -- 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] extcon: Palmas Extcon Driver
On Monday 27 May 2013 11:38 AM, Chanwoo Choi wrote: On 05/27/2013 02:54 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote: Hi Kishon, I have some comment about this patch and upload modified patch to following repository (extcon-for-palmas). - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmasid=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c This patchset include patch related to other module ,so I need your opinion to apply this patchset to git repository. yeah.. Still there is some confusion with palmas_set_switch_smps10(). I think we can remove it for now and add it separately later. By this at least we can have device mode fully functional in OMAP5. What do you think? I agree your opinion. But, I propose some fixes about palmas_set_switch_smps10(). I dont' prefer to call global function in exton-palmas.c from palmas-regulator.c. So, Why don't you use regulator consumer instead of global function? You can register specific regulator for enabling or disabling SMPS10_SWITCH_EN and then control SMPS10_SWITCH_EN bit through regulator framework in extcon-palmas.c without calling global function. Along with this, I also like to make the VBUS regulator control to be optional here. Currently it is mandatory. -- 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] extcon: Palmas Extcon Driver
On Monday 27 May 2013 12:01 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 11:52 AM, Laxman Dewangan wrote: On Monday 27 May 2013 11:38 AM, Chanwoo Choi wrote: On 05/27/2013 02:54 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote: Hi Kishon, I have some comment about this patch and upload modified patch to following repository (extcon-for-palmas). - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmasid=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c This patchset include patch related to other module ,so I need your opinion to apply this patchset to git repository. yeah.. Still there is some confusion with palmas_set_switch_smps10(). I think we can remove it for now and add it separately later. By this at least we can have device mode fully functional in OMAP5. What do you think? I agree your opinion. But, I propose some fixes about palmas_set_switch_smps10(). I dont' prefer to call global function in exton-palmas.c from palmas-regulator.c. So, Why don't you use regulator consumer instead of global function? You can register specific regulator for enabling or disabling SMPS10_SWITCH_EN and then control SMPS10_SWITCH_EN bit through regulator framework in extcon-palmas.c without calling global function. Along with this, I also like to make the VBUS regulator control to be optional here. Currently it is mandatory. But dint you just tell on my v4 of this patch that you don’t require this. http://www.spinics.net/lists/linux-doc/msg10638.html In V4, I said remove this VBUS control and my mean was to remove all regulator calls for VBUS enabled/disable. I saw you just remove the platform data option to have this control and made VBUS mandatory. Probably some gap here. In tegra platform, we dont need VBUS regualtor control from extcon. -- 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] extcon: Palmas Extcon Driver
On Monday 27 May 2013 12:11 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 12:06 PM, Laxman Dewangan wrote: On Monday 27 May 2013 12:01 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 11:52 AM, Laxman Dewangan wrote: On Monday 27 May 2013 11:38 AM, Chanwoo Choi wrote: On 05/27/2013 02:54 PM, Kishon Vijay Abraham I wrote: Hi, On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote: Hi Kishon, I have some comment about this patch and upload modified patch to following repository (extcon-for-palmas). - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmasid=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c This patchset include patch related to other module ,so I need your opinion to apply this patchset to git repository. yeah.. Still there is some confusion with palmas_set_switch_smps10(). I think we can remove it for now and add it separately later. By this at least we can have device mode fully functional in OMAP5. What do you think? I agree your opinion. But, I propose some fixes about palmas_set_switch_smps10(). I dont' prefer to call global function in exton-palmas.c from palmas-regulator.c. So, Why don't you use regulator consumer instead of global function? You can register specific regulator for enabling or disabling SMPS10_SWITCH_EN and then control SMPS10_SWITCH_EN bit through regulator framework in extcon-palmas.c without calling global function. Along with this, I also like to make the VBUS regulator control to be optional here. Currently it is mandatory. But dint you just tell on my v4 of this patch that you don’t require this. http://www.spinics.net/lists/linux-doc/msg10638.html In V4, I said remove this VBUS control and my mean was to remove all regulator calls for VBUS enabled/disable. I saw you just remove the platform data option to have this control and made VBUS mandatory. Probably some gap here. Indeed.. I think then we should stick back to how it was with my v4 or else it would break OMAP. The regulator calls can't be moved anywhere else as it is specific to PALMAS. I was thinking that extcon driver just detect the cable type and notify to the client. After cable detection, the next level of configuration should be done in the respective client. On Tegra platform, for ID pin detection, Tegra SOC is capable of detect the ID pin presence or Palma is capable. Depending on the board design, how the ID pin routed from USB connector to PMIC or to Tegra, we enable corresponding detection logic. Once the USB driver got notification for ID pin presence (by any means), the enabling of VBUS (as the Tegra will work as Host now and need to supply VBUS), is done in USB driver. Not sure about the OMAP here. So in above context, I really do not want to have the VBUS control on extcon driver from Tegra context. If it is require in OMAP context then please make it as optional so that we can satisfy for Tegra and Omap platform. -- 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/3] drivers: regulator: palmas: add an API to set/clear the switch bit on SMPS10
Hi Kishon/Graeme, On Friday 24 May 2013 08:01 PM, Kishon Vijay Abraham I wrote: From: Graeme Gregory g...@slimlogic.co.uk Added an API to set/clear the switch bit on SMPS10 which can be used by palmas usb. The switch bit should be set in order for palmas to supply VBUS and is needed when OMAP is acting as USB HOST. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/regulator/palmas-regulator.c | 26 ++ include/linux/mfd/palmas.h | 2 ++ 2 files changed, 28 insertions(+) diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index 92ceed0..d57ab55 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -465,6 +465,32 @@ static int palmas_smps_set_ramp_delay(struct regulator_dev *rdev, return ret; } +/** + * palmas_set_switch_smps10() - set or clear the switch bit on SMPS10 + * @param palmas pointer to the palmas mfd structure + * @param sw boolean to indicate switch status + * + * There is not a way to represent this function within the regulator + * framework. This sets/clears the switch of SMPS10 so SMPS10_OUT1 and + * SMPS10_OUT2 are shorted together. + */ As per datasheet, SMPS10 has 2 outputs, OUT1 and OUT2. OUT2 is always available either through parasitic diode or bypass switch or boost mode. It can not be off at all. OUT2 can be enable/disable through the switch bit. The smps10 regulator is implemented enable/disable on which it just enable/disable boost mode. I think this is not proper control, actually we should control OUT1 switch on regulator enable/disable of the smps10. And hence in this case, we will not need this API. Otherwise it will difficult to use this api outside of palmas. In tegra platform, we have connected the USB-VBUS supply from SMPS10-OUT1 and usb driver control the vbus enabled/disable and so it can not call this API. This functionality need to be exposed through the regulator only. -- 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] extcon: Palmas Extcon Driver
Hi Graeme/Kishon, On Friday 24 May 2013 08:01 PM, Kishon Vijay Abraham I wrote: From: Graeme Gregory g...@slimlogic.co.uk This is the driver for the USB comparator built into the palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. I have following feedback on this driver to use this on Tegra platform: 1. Can we have very simple driver for detecting VBUS and ID and just generate notification. No VBUS control logic or lots of USB related configurations? 2. We will need the VBUS control as optional if it is require for TI platform. Currently it is mandatory and hence it is not suite in our context. 3. There is VBUS control (enabled/disable) in VBUS detection also. When palma detect the VBUS then why actually it need to enable VBUS as VBUS is already supplied by HOST? It may be only need when palma detect the ID pin and maybe want to enable VBUS but again VBUS control (enable/disable) should be part of USB driver, out of extcon driver. -- 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 4/4] regulator: fixed: Properly use input_supply parameter from device tree
On 11/15/2012 09:56 AM, Roger Quadros wrote: The device tree node will provide the input supply name as a string. Use that to populate the supply_name parameter of the regulator descriptor. Also correct the documentation to reflect the same. Signed-off-by: Roger Quadros rog...@ti.com CC: Laxman Dewangan ldewan...@nvidia.com CC: Mark Brown broo...@opensource.wolfsonmicro.com --- regulator-boot-on; gpio-open-drain; - vin-supply = parent_reg; + vin-supply = input-supply-name; This is not correct as per the regulator binding. It says - name-supply: phandle to the parent supply/regulator node So we need to pass the phandle rather than string. Just for curiosity, why do you want this change? What is the issue are you facing. This change will creates regression on many platform. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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 3/8] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Wednesday 18 April 2012 03:41 PM, Russell King wrote:
+/**
+ * vchan_cookie_complete - report completion of a descriptor
+ * vd: virtual descriptor to update
+ *
+ * vc.lock must be held by caller
+ */
+static inline void vchan_cookie_complete(struct virt_dma_desc *vd)
+{
+ struct virt_dma_chan *vc = to_virt_chan(vd-tx.chan);
+
+ dma_cookie_complete(vd-tx);
+ dev_vdbg(vc-chan.device-dev, txd %p[%x]: marked complete\n,
+ vd, vd-tx.cookie);
+ list_add_tail(vd-node,vc-desc_completed);
+
+ tasklet_schedule(vc-task);
+}
For cyclic case, we will not like to call the dma_cookie_complete() but
want to put the desc in callback list.
So can we have one more arg on this function which byspass the call of
dma_cookie_complete()
--
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 3/8] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Tuesday 24 April 2012 04:20 PM, Russell King - ARM Linux wrote: For cyclic case, we will not like to call the dma_cookie_complete() but want to put the desc in callback list. So can we have one more arg on this function which byspass the call of dma_cookie_complete() See the discussion on what's supposed to happen with cyclic transfers. Cyclic transfers don't complete, so adding them to the completed list and marking them complete is the wrong thing to be doing. So arguably calling this function is also the wrong thing to be doing because you're not completing the transfer. OK, we will not call this function but still need to call the callback. So do you suggest to call callback directly from dma driver rather than the virt_chan? I'll be addressing the issue of cyclic transfers when I eventually get to sorting out the OMAP ASoC driver. Here I am developing the dma driver for Tegra in cyclic and normal mode and what is your suggestion here? Should I use your virt_chan now or I can go ahead with my first patch without virt_chan and once you are done with your virt_chan with all cyclic support then port the tegra_dma to use virt chan and next enhanced patch? In this way, my Tegra dma will be there in tree, all client will be move to dma engine based driver and then I will comeback to tegra_dma for using the virt_channel. -- 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
