Re: [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}
On Fri, Oct 10, 2014 at 05:20:56PM -0700, Stephen Boyd wrote: On 10/10, Peter De Schrijver wrote: drivers/clk/tegra/clk-pll.c:732:unsigned long input_rate = clk_get_rate(clk_get_parent(hw-clk)); drivers/clk/tegra/clk-pll.c:1288:unsigned long input_rate = clk_get_rate(clk_get_parent(hw-clk)); This is not so easy to change unfortunately. I will have to think of a solution. Thanks. Does the input parent rate change at runtime or is it fixed at boot? I'm hoping we can call _get_table_rate() once before we register the clock or something. It can change at runtime. Cheers, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm 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/3] spi: qup: Remove .owner field for driver
On Thu, Oct 09, 2014 at 01:12:08PM +0530, Kiran Padwal wrote: There is no need to init .owner field. Based on the patch from Peter Griffin peter.grif...@linaro.org mmc: remove .owner field for drivers using module_platform_driver This patch removes the superfluous .owner field for drivers which use the module_platform_driver API, as this is overridden in platform_driver_register anyway. Two problems: - I'm missing patches 1 and 2. - This only changes one driver but essentially every SPI driver initializes .owner - why is only thi sone driver being changed? signature.asc Description: Digital signature
Re: [PATCH 2/4] Input: pmic8xxx-keypad - use regmap_field for register access
On Wed, Oct 08, 2014 at 01:32:33PM -0700, Dmitry Torokhov wrote: On Wed, Oct 08, 2014 at 09:04:26PM +0100, Mark Brown wrote: On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote: Srini/Mark, any reason why the regmap_field structure is opaque? So you can't peer into it and rely on the contents. I can see it being useful to add a bulk allocator. And then one have to define offsets in an array and use awkward syntax to access individual fields. Can we just reply on reviews/documentation for users to not do wrong thing? I have very little confidence in users not doing awful things to be honest, this is the sort of API where the users are just random things all over the kernel so this sort of thing tends to be found after the fact. I get a lot of these in drivers that just got thrown over the wall so nobody really knows what things are doing when you do find them. If the standard allocators aren't doing a good job (I've not checked) I'd much rather handle this inside the API if we can. signature.asc Description: Digital signature
Re: [PATCH v3 2/2] DT: iio: vadc: document dt binding
On Wed, Sep 24, 2014 at 01:56:55PM +0100, Stanimir Varbanov wrote: Document DT binding for Qualcomm SPMI PMIC voltage ADC driver. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 130 1 files changed, 130 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt new file mode 100644 index 000..fa30300 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt @@ -0,0 +1,130 @@ +Qualcomm's SPMI PMIC voltage ADC + +SPMI PMIC voltage ADC (VADC) provides interface to clients to read +voltage. A 15 bit ADC is used for voltage measurements. There are multiple +peripherals to the VADC and the scope of the driver is to provide interface +for the USR peripheral of the VADC. + +VADC node: + +- compatible: +Usage: required +Value type: string Technically this is a list of strings. +Definition: Should contain qcom,spmi-vadc. + +- reg: +Usage: required +Value type: u32 This is an address + size pair, not a u32 (following your example). +Definition: Base address in the SPMI PMIC register map. And the size, too. + +- address-cells: +Usage: required +Value type: u32 +Definition: Must be one. #address-cells. What would this cell represent within the ADC? + +- size-cells: +Usage: required +Value type: u32 +Definition: Must be zero. #size-cells. + +- interrupts: +Usage: optional +Value type: prop-encoded-array +Definition: End of conversion interrupt number. If this property does +not exist polling will be used instead. Just say end of conversion interrupt. The interrupts property is standard, and driver behaviour is not a property of the device. + +- interrupt-names: +Usage: optional +Value type: string +Definition: Should contain the interrupt name eoc (end of conversion). If you wish to use interrupt-names, please define interrupts in terms of interrupt-names so as to make the relationship clear and to avoid redundancy. + +Channel node properties: + +- reg: +Usage: required +Value type: u32 +Definition: AMUX channel number. +See include/dt-bindings/iio/qcom,spmi-pmic-vadc.h That header should be part of this patch (and this patch should come before the driver). + +- qcom,decimation: +Usage: optional +Value type: u32 +Definition: Sampling rate to use for the individual channel measurement. +Quicker measurements can be made by reducing decimation ratio. +Valid values are 512, 1024, 2048, 4096. +If property is not found, default value of 512 will be used. This description does not make sense. If reducing the value increases the sampling rate, this property should not be described as the sampling rate. This feels like something that should be runtime configurable rather than a fixed device property. + +- qcom,pre-scaling: +Usage: optional +Value type: u32 array +Definition: Used for scaling the channel input signal before the signal is +fed to VADC. The configuration for this node is to know the +pre-determined ratio and use it for post scaling. Select one from +the following options. +1 1, 1 3, 1 4, 1 6, 1 20, 1 8, 10 81, 1 10 +If property is not found default value depending of chip will be used. + +- qcom,ratiometric: +Usage: optional +Value type: empty +Definition: Channel calibration type. If this property is specified +VADC will use the VDD reference(1.8V) and GND for channel +calibration. If property is not found, channel will be +calibrated with 625mV and 1.25V reference channels. +Otherwise the absolute calibration will be used. Surely this should be part of the specifier? + +- qcom,hw-settle-time: +Usage: optional +Value type: u32 +Definition: Time between AMUX getting configured and the ADC starting +conversion. Delay = 100us * (value) for value 11, and +2ms * (value - 10) otherwise. +Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800, +900 us and 1, 2, 4, 6, 8, 10 ms +If property is not found, channel will use 0us. + +- qcom,avg-samples: +Usage: optional +Value type: u32 +Definition: Number of samples to be used for measurement. +Fast averaging provides the option to obtain a single measurement +from the ADC that is an average of multiple samples. The value +selected is 2^(value). +Valid values are: 1, 2, 4,
Re: [PATCH v3] mtd: ubi: Extend UBI layer debug/messaging capabilities
On Mon, 2014-10-06 at 14:01 +0300, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Looks good to me, pushed to the master branch of the linux-ubifs.git tree. Later, when the merge window is closed, I'll merge this patch to the linux-next branch too. Thanks! -- Artem -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm 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] mtd: ubi: Extend UBI layer debug/messaging capabilities
On Mon, 2014-10-13 at 18:37 +0300, Artem Bityutskiy wrote: On Mon, 2014-10-06 at 14:01 +0300, Tanya Brokhman wrote: If there is more then one UBI device mounted, there is no way to distinguish between messages from different UBI devices. Add device number to all ubi layer message types. Looks good to me, pushed to the master branch of the linux-ubifs.git tree. Later, when the merge window is closed, I'll merge this patch to the linux-next branch too. Tanya, sorry, I was not careful enough, I merged it and tested against the Linuses head, it is fine. But it does not apply the the linux-ubifs.git tree. There are conflicts. But more importantly, you did not get the 'block.c' right. There we use the same printing macros, but we do not have 'struct ubi_info' there at all. Please, enable the R/O block layer feature and try to compile, it'll fail. The block driver is in 'drivers/mtd/ubi', but it is kind of a separate driver - it does not access the internal UBI data structures. I guess the solution would be to just use pr_* functions there instead. CCing Ezequiel. Please, submit a patch against the 'linux-next' branch of this tree: git://git.infradead.org/linux-ubifs.git Artem. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm 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 2/2] DT: iio: vadc: document dt binding
Thanks for the comments! On 10/12/2014 02:05 AM, Hartmut Knaack wrote: Hi, two small issues inline. Stanimir Varbanov schrieb am 24.09.2014 14:56: Document DT binding for Qualcomm SPMI PMIC voltage ADC driver. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com --- .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 130 1 files changed, 130 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt new file mode 100644 index 000..fa30300 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt @@ -0,0 +1,130 @@ +Qualcomm's SPMI PMIC voltage ADC + +SPMI PMIC voltage ADC (VADC) provides interface to clients to read +voltage. A 15 bit ADC is used for voltage measurements. There are multiple +peripherals to the VADC and the scope of the driver is to provide interface +for the USR peripheral of the VADC. + +VADC node: + +- compatible: +Usage: required +Value type: string +Definition: Should contain qcom,spmi-vadc. + +- reg: +Usage: required +Value type: u32 +Definition: Base address in the SPMI PMIC register map. + +- address-cells: +Usage: required +Value type: u32 +Definition: Must be one. + +- size-cells: +Usage: required +Value type: u32 +Definition: Must be zero. + +- interrupts: +Usage: optional +Value type: prop-encoded-array +Definition: End of conversion interrupt number. If this property does +not exist polling will be used instead. + +- interrupt-names: +Usage: optional +Value type: string +Definition: Should contain the interrupt name eoc (end of conversion). + +Channel node properties: + +- reg: +Usage: required +Value type: u32 +Definition: AMUX channel number. +See include/dt-bindings/iio/qcom,spmi-pmic-vadc.h + +- qcom,decimation: +Usage: optional +Value type: u32 +Definition: Sampling rate to use for the individual channel measurement. +Quicker measurements can be made by reducing decimation ratio. +Valid values are 512, 1024, 2048, 4096. +If property is not found, default value of 512 will be used. + +- qcom,pre-scaling: +Usage: optional +Value type: u32 array +Definition: Used for scaling the channel input signal before the signal is +fed to VADC. The configuration for this node is to know the +pre-determined ratio and use it for post scaling. Select one from +the following options. +1 1, 1 3, 1 4, 1 6, 1 20, 1 8, 10 81, 1 10 +If property is not found default value depending of chip will be used. + +- qcom,ratiometric: +Usage: optional +Value type: empty +Definition: Channel calibration type. If this property is specified +VADC will use the VDD reference(1.8V) and GND for channel Missing whitespace before opening parenthesis. +calibration. If property is not found, channel will be +calibrated with 625mV and 1.25V reference channels. There is a slight majority in using V instead of mv (2 : 1), so why not express everything in V? No worries, will correct. -- regards, Stan -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
