Hi,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Baptiste Reynal
> Sent: Tuesday, June 23, 2015 5:43 PM
> To: Sricharan R
> Cc: linux-arm-msm@vger.kernel.org; Linux IOMMU; Will Deacon; open list;
> moderated list:ARM SM
DSI PHY errors are falsely reported whenever a dsi error occurs. This is
because DSI_DLN0_PHY_ERR isn't only used as a status register, but also
used to mask PHY errors. Currently, we end up reading the mask bits too
and therefore always report errors.
Ignore the register mask bits and check for o
Add bitfieds in DSI_DLN0_PHY_ERR which are used to report and clear
errors.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.
The maximum output width of one pipeline depends on the LayerMixer's
capability. It may be different on each target. Also, MDP5 doesn't
have vertical limitation in one frame, as long as the pixel clock
can be supported.
This change obtains the maximum LM resolution from configuration
table and tre
On 06/22/2015 04:09 PM, Srinivas Kandagatla wrote:
> diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
> new file mode 100644
> index 000..7f7a82f
> --- /dev/null
> +++ b/drivers/nvmem/qfprom.c
> @@ -0,0 +1,89 @@
>
> +
> +#include
> +#include
> +#include
> +#include
> +#include
On 18/06/15 07:47, Bjorn Andersson wrote:
This introduces pinctrl drivers for gpio and mpp blocks found in family A
PMICs.
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 5 +
drivers/pinctrl/qcom/Kconfig | 12 +
drivers/pin
On 24/06/15 18:47, Stefan Wahren wrote:
Hi Srinivas,
Srinivas Kandagatla hat am 24. Juni 2015 um
15:03 geschrieben:
On 24/06/15 13:30, Stefan Wahren wrote:
If the question is just about hexdump, then hexdump itself can read
file from given offset and size.
yes, this is my question at f
Hi Srinivas,
> Srinivas Kandagatla hat am 24. Juni 2015 um
> 15:03 geschrieben:
>
>
>
>
> On 24/06/15 13:30, Stefan Wahren wrote:
> >> >If the question is just about hexdump, then hexdump itself can read
> >> >file from given offset and size.
> > yes, this is my question at first. Let me show the
On Fri, Jun 19, 2015 at 11:36 AM, Jilai Wang wrote:
> Add plane properties "premultiplied/zpos/alpha" used in msm MDP
> driver to perform proper blending operation.
>
> Signed-off-by: Jilai Wang
> ---
> Documentation/DocBook/drm.tmpl | 23 +++
> 1 file changed, 23 insertions(
On Wed, 24 Jun 2015 10:17:30 -0600
Ankit Gupta wrote:
> Add chip name and hw-irq number to the trace_irq_handler_entry()
> tracepoint. When tracing interrupt events the chip-name and hw-irq
> numbers are stable and known in advance. This makes them a better
> choice as a filtering criteria for th
Add chip name and hw-irq number to the trace_irq_handler_entry()
tracepoint. When tracing interrupt events the chip-name and hw-irq
numbers are stable and known in advance. This makes them a better
choice as a filtering criteria for the trace buffer dump. On the
flipside, the os-irq numbers are dyn
To support mdp5 blending for mdp5 v1.5 and later
V1: Initial change
V2: After the stage number is increased to 7, BLENDx registers are
not continuous now. Using the offset for each BLEND stage
to fix it.
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 95
MDP1.5 can support 7 stages. Update xml file accordingly.
V1: Initial change
V2: After the stage number is increased to 7, BLENDx registers are
not continuous now. Using the offset for each BLEND stage
to fix it.
Signed-off-by: Jilai Wang
---
rnndb/mdp/mdp5.xml | 38 +++
On 24/06/15 13:30, Stefan Wahren wrote:
>If the question is just about hexdump, then hexdump itself can read
>file from given offset and size.
yes, this is my question at first. Let me show the difference between
the current implementation and my expectations as a user.
$ hexdump /sys/class/n
Hi Srinivas,
Am 24.06.2015 um 11:46 schrieb Srinivas Kandagatla:
>
>
> On 23/06/15 20:47, Stefan Wahren wrote:
>>> 0001000
>>> >
>> i want to port OCOTP driver for MXS, which hasn't MMIO. From my
>> understanding
> That's cool.
>
>> hexdump would readout the complete register range defined in prov
On 24/06/15 01:24, Stephen Boyd wrote:
Can you assign the attributes to the device_type in the nvmem::struct
device? I don't see why these attributes need to be part of the class.
I will fix this.
>>
>>>+{
>>>+return class_register(&nvmem_class);
>>
>>I thought class was on the way out
On 23/06/15 10:26, Pantelis Antoniou wrote:
Hi Joe,
>On Jun 23, 2015, at 05:52 , Joe Perches wrote:
>
>On Tue, 2015-06-23 at 00:08 +0100, Srinivas Kandagatla wrote:
>>This patch adds just providers part of the framework just to enable easy
>>review.
>[]
>>include/linux/nvmem-provider.h |
On 23/06/15 21:10, Stefan Wahren wrote:
Hi Srinivas,
sorry for the messed up indention.
NP,
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Sorting alphabetically would by nice
Good Idea.
+ [...]
+/**
+ * nvmem_regis
On 23/06/15 21:16, Stefan Wahren wrote:
+
>+struct device;
Do we need forward declaration of struct device_node too?
Yep, Will fix it in next version.
--srini
>+/* consumer cookie */
>[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message
On 23/06/15 21:28, Stefan Wahren wrote:
>@@ -26,6 +35,21 @@ void devm_nvmem_cell_put(struct device *dev, struct
>nvmem_cell *cell);
>void *nvmem_cell_read(struct nvmem_cell *cell, ssize_t *len);
>int nvmem_cell_write(struct nvmem_cell *cell, void *buf, ssize_t len);
>
>+/* direct nvmem device r
On 23/06/15 21:35, Stefan Wahren wrote:
+Required properties:
>+reg: specifies the offset in byte within that storage device, start bit
>+ in the byte and the length in bits of the data we care about.
Is the second parameter really in bits, not bytes?
Thanks for spotting this, I will fix this
On 23/06/15 10:25, Rajendra Nayak wrote:
[]..
+Example:
+
+qfprom: qfprom@0070 {
+compatible = "qcom,qfprom";
+reg= <0x0070 0x8000>;
+...
+/* Data cells */
+tsens_calibration: calib@404 {
+reg = <0x4404 0x10>;
+
On 23/06/15 21:44, Stefan Wahren wrote:
Srinivas Kandagatla hat am 23. Juni 2015 um
01:09 geschrieben:
From: Maxime Ripard
Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation
On 23/06/15 20:47, Stefan Wahren wrote:
0001000
>
i want to port OCOTP driver for MXS, which hasn't MMIO. From my understanding
That's cool.
hexdump would readout the complete register range defined in provider DT node.
How can i achieve that hexdump only reads the data area within the reg
On Wed, 2015-06-17 at 23:47 -0700, Bjorn Andersson wrote:
> This series starts out by fixing various issues found in the pm8941 mpp
> driver.
> While doing this work, and trying to use the mpp driver from device tree it,
> it
> became obvious that the current binding is not fit for neither the d
Hi Bjorn,
On Wed, 2015-06-17 at 23:47 -0700, Bjorn Andersson wrote:
> This introduces pinctrl drivers for gpio and mpp blocks found in family A
> PMICs.
>
> +
> +static struct platform_driver pm8xxx_gpio_driver = {
> + .driver = {
> + .name = "pm8xxx_gpio",
Name of the SPMI
Hi Bjorn,
On Wed, 2015-06-17 at 23:47 -0700, Bjorn Andersson wrote:
> When the MPP is configured for analog output the output level is selected by
> the AOUT_CTL register, this patch makes it possible to control this.
>
> }
> @@ -748,6 +765,10 @@ static int pmic_mpp_populate(struct pmi
27 matches
Mail list logo
