Re: [PATCH 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Stephen Boyd 
On 09/15, Andrew Morton wrote:
> On Tue, 15 Sep 2015 12:41:26 -0700 Stephen Boyd  wrote:
> 
> > The SMD driver is reading and writing chunks of data to iomem,
> > and there's an __iowrite32_copy() function for the writing part, but
> > no __ioread32_copy() function for the reading part. This series
> > adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
> > case this should go through the -mm tree. Otherwise the target
> > of this patch series is SMD, so I've sent it to Andy.
> 
> "soc: qcom: smd: Use __ioread32_copy() instead of open-coding it" no
> longer applies, because smd_copy_from_fifo() has switched to
> readl_relaxed().

Yes. There are some other patches in flight on the mailing list
to this file from me[1]. Those would need to be applied first to
avoid conflicts.

> 
> Let's use the __weak macro rather than open-coding it (and convert
> __iowrite32_copy() while we're in there).

Yep, I converted the __iowrite32_copy() open-code in there too in
the patch series I mentioned above. See [2].

> 
> It's unclear why __iowrite32_copy() is a weak function - nothing
> overrides it.  Perhaps we should just take that away rather than
> copying it into __ioread32_copy().

Huh? I see that x86 has an implementation in arch/x86/lib/iomap_copy_64.S

> 
> __iowrite32_copy() is marked __visible.  I don't actually know what
> that does and Andi's d47d5c8194579bc changelog (which sucks the big
> one) didn't explain it.  Apparently it has something to do with being
> implemented in assembly, but zillions of functions are implemented in
> assembly, so why are only two functions marked this way?  Anyway,
> __ioread32_copy() is implemented in C so I guess __visible isn't needed
> there.

Yeah, I didn't add visible because there isn't an assembly
version of __ioread32_copy() so far. I can remove __weak if
desired. I left it there to match __iowrite32_copy() in case
x86 wanted to override it but we can do that later or never.

[1] 
http://lkml.kernel.org/g/1441234011-4259-7-git-send-email-sb...@codeaurora.org
[2] 
http://lkml.kernel.org/g/1441234011-4259-5-git-send-email-sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-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 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Andrew Morton 
On Tue, 15 Sep 2015 12:41:26 -0700 Stephen Boyd  wrote:

> The SMD driver is reading and writing chunks of data to iomem,
> and there's an __iowrite32_copy() function for the writing part, but
> no __ioread32_copy() function for the reading part. This series
> adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
> case this should go through the -mm tree. Otherwise the target
> of this patch series is SMD, so I've sent it to Andy.

"soc: qcom: smd: Use __ioread32_copy() instead of open-coding it" no
longer applies, because smd_copy_from_fifo() has switched to
readl_relaxed().

Let's use the __weak macro rather than open-coding it (and convert
__iowrite32_copy() while we're in there).

It's unclear why __iowrite32_copy() is a weak function - nothing
overrides it.  Perhaps we should just take that away rather than
copying it into __ioread32_copy().

__iowrite32_copy() is marked __visible.  I don't actually know what
that does and Andi's d47d5c8194579bc changelog (which sucks the big
one) didn't explain it.  Apparently it has something to do with being
implemented in assembly, but zillions of functions are implemented in
assembly, so why are only two functions marked this way?  Anyway,
__ioread32_copy() is implemented in C so I guess __visible isn't needed
there.



--
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 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Andi Kleen 
> Under what circumstances will the compiler (or linker?) do this? 

Compiler.

> LTO enabled?

Yes it's for LTO.  The optimization allows the compiler to drop unused
functions, which is very popular with users (a lot use it to get smaller
kernel images)

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
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 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Andi Kleen 
> __iowrite32_copy() is marked __visible.  I don't actually know what
> that does and Andi's d47d5c8194579bc changelog (which sucks the big
> one) didn't explain it.  Apparently it has something to do with being
> implemented in assembly, but zillions of functions are implemented in
> assembly, so why are only two functions marked this way?  Anyway,
> __ioread32_copy() is implemented in C so I guess __visible isn't needed
> there.

__visible is needed for C functions that are called from assembler.
Otherwise the compiler may optimize them away.

-Andi
--
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 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Andrew Morton 
On Wed, 16 Sep 2015 04:32:19 +0200 Andi Kleen  wrote:

> > __iowrite32_copy() is marked __visible.  I don't actually know what
> > that does and Andi's d47d5c8194579bc changelog (which sucks the big
> > one) didn't explain it.  Apparently it has something to do with being
> > implemented in assembly, but zillions of functions are implemented in
> > assembly, so why are only two functions marked this way?  Anyway,
> > __ioread32_copy() is implemented in C so I guess __visible isn't needed
> > there.
> 
> __visible is needed for C functions that are called from assembler.
> Otherwise the compiler may optimize them away.

Under what circumstances will the compiler (or linker?) do this? 
LTO enabled?

--
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] spmi-pmic-arb: support configurable number of peripherals

2015-09-15 Thread Stephen Boyd 
On 09/15, Ivan T. Ivanov wrote:
> 
> On Mon, 2015-09-14 at 18:28 -0700, Stephen Boyd wrote:
> > On 09/14/2015 02:54 PM, Stephen Boyd wrote:
> > > The current driver implementation supports only 128 peripherals.
> > > Add support for more than 128 peripherals by taking a lazy
> > > caching approach to the mapping tables. Instead of reading the
> > > tables at boot given some fixed size, read them on an as needed
> > > basis and cache the results. We still assume a max number of 512
> > > peripherals, trading off some space for simplicity.
> > > 
> > > Based on a patch by Gilad Avidov  and
> > > Sagar Dharia .
> > > 
> > > Signed-off-by: Stephen Boyd 
> > > ---
> > 
> > Hi Ivan,
> > 
> > This patch causes 8916 to crash, because there isn't a mapping for ppid
> > 257 in the ppid to channel table. It seems that we're reading the revid
> > from the slave id 1 pmic by going through channel 0, which seems to be
> > setup for ppid 9 (slave id 0 and the peripheral starting at 0x900). Can
> > we stop reading the revid registers from non-zero slave id pmic devices?
> > That would be one solution to fix this problem. Or maybe we need to
> > special case this in the pmic arbiter code to fold ppid 0xN01 (slave id
> > N and address 0x100) onto channel 0 all the time?
> > 
> 
> Yes, we can. We are not using this information at the moment.
> Right now, revision read is more or less for debug purposes.
> 
> Would following patch work for you? Of course it will be difficult

Yes the patch works fine. Feel free to add a

Tested-by: Stephen Boyd 

> to guaranties that some other driver misbehave and touch non-existing
> register, right?

Yeah some driver could misbehave and try to read/write something
that doesn't exist. As in this case, the device will reset. Given
that all this stuff is in the kernel though, it seems fine to
blow up instead of add a bunch of checks that aren't ever going
to matter in practice.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-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] spmi-pmic-arb: support configurable number of peripherals

2015-09-15 Thread Ivan T. Ivanov 

On Mon, 2015-09-14 at 18:28 -0700, Stephen Boyd wrote:
> On 09/14/2015 02:54 PM, Stephen Boyd wrote:
> > The current driver implementation supports only 128 peripherals.
> > Add support for more than 128 peripherals by taking a lazy
> > caching approach to the mapping tables. Instead of reading the
> > tables at boot given some fixed size, read them on an as needed
> > basis and cache the results. We still assume a max number of 512
> > peripherals, trading off some space for simplicity.
> > 
> > Based on a patch by Gilad Avidov  and
> > Sagar Dharia .
> > 
> > Signed-off-by: Stephen Boyd 
> > ---
> 
> Hi Ivan,
> 
> This patch causes 8916 to crash, because there isn't a mapping for ppid
> 257 in the ppid to channel table. It seems that we're reading the revid
> from the slave id 1 pmic by going through channel 0, which seems to be
> setup for ppid 9 (slave id 0 and the peripheral starting at 0x900). Can
> we stop reading the revid registers from non-zero slave id pmic devices?
> That would be one solution to fix this problem. Or maybe we need to
> special case this in the pmic arbiter code to fold ppid 0xN01 (slave id
> N and address 0x100) onto channel 0 all the time?
> 

Yes, we can. We are not using this information at the moment.
Right now, revision read is more or less for debug purposes.

Would following patch work for you? Of course it will be difficult
to guaranties that some other driver misbehave and touch non-existing
register, right?

Regards,
IvanFrom d7c9c59b7134f093cf3f829832f4f7771a65664e Mon Sep 17 00:00:00 2001
From: "Ivan T. Ivanov" 
Date: Tue, 15 Sep 2015 09:43:10 +0300
Subject: [PATCH] mfd: qcom-spmi-pmic: Do not access non existing registers
Cc: linux-ker...@vger.kernel.org

Revision ID registers are available only on devices with
Slave ID Zero, so don't make access to unavailable registers.

Signed-off-by: Ivan T. Ivanov 
---
 drivers/mfd/qcom-spmi-pmic.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c
index af6ac1c4b45c..d7ad72af5682 100644
--- a/drivers/mfd/qcom-spmi-pmic.c
+++ b/drivers/mfd/qcom-spmi-pmic.c
@@ -122,12 +122,22 @@ static int pmic_spmi_probe(struct spmi_device *sdev)
 {
 	struct device_node *root = sdev->dev.of_node;
 	struct regmap *regmap;
+	u32 sid;
+	int ret;
+
+	ret = of_property_read_u32(root, "reg", );
+	if (ret < 0) {
+		dev_err(>dev, "Missing SID\n");
+		return ret;
+	}
 
 	regmap = devm_regmap_init_spmi_ext(sdev, _regmap_config);
 	if (IS_ERR(regmap))
 		return PTR_ERR(regmap);
 
-	pmic_spmi_show_revid(regmap, >dev);
+	/* Only devices with Slave ID Zero contain this information */
+	if (sid == 0)
+		pmic_spmi_show_revid(regmap, >dev);
 
 	return of_platform_populate(root, NULL, NULL, >dev);
 }
-- 
1.9.1

Re: [PATCH v2 1/2] input: Add Qualcomm PM8941 power key driver

2015-09-15 Thread Ivan T. Ivanov 

On Fri, 2015-01-23 at 16:19 -0800, Bjorn Andersson wrote:
> From: Courtney Cavin ca...@sonymobile.com>
> 
> Signed-off-by: Courtney Cavin ca...@sonymobile.com>
> Signed-off-by: Bjorn Andersson anders...@sonymobile.com>
> 



> 
> +config INPUT_PM8941_PWRKEY
> +   tristate "Qualcomm PM8941 power key support"
> +   depends on MFD_SPMI_PMIC
> +   help
> +   Say Y here if you want support for the power key 
> usually found
> +   on boards using a Qualcomm PM8941 compatible PMIC.
> +

Hi Bjorn, Courtney, 

Do you plan to extend this driver to support RESIN_N PMIC input?
 
It looks like the same downstream "qcom,qpnp-power-on" handle
this functionality for recent PMIC versions.

What will be the best way to add this new functionality, extend
this driver, write new one...?

Regards,
Ivan


--
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: [RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-09-15 Thread Archit Taneja 

Hi Rob, Mark,

We've been trying to figure out the right way to represent a class
of display encoder devices in DT.

These devices have registers that are generally configured via i2c. Once 
the device is configured, it takes in video data from the mipi

dsi bus.

Until now, all the devices we've supported devices that can be are
configured by the dsi bus itself, and hence, we've been able to
represent them in DT as children under the dsi host.

For the above class of devices (using both i2c and dsi), we aren't
able to conclude upon what's the better approach among the two:

1. Represent the device via 2 different nodes in DT. One would be
a child under an i2c adapter, the other a child of a dsi host. We
would have two device drivers, one i2c client, and the other a
mipi dsi device.

2. Represent the device as an i2c client in DT. Provide an api
to create "dummy" dsi devices. The i2c client driver would use
this api to register a dsi device, and link itself with the dsi
host.

What do you think would be the way to go here? I guess you
might have faced something similar in other subsystems.

I've given a relatively brief description of the problem. There
were some more nitty gritties discussed in this thread before.

Thierry, Andrzej, Lucas,

Please feel free to add your comments if I have missed out on
something.

Thanks,
Archit

On 09/10/2015 01:02 PM, Thierry Reding wrote:

On Thu, Sep 10, 2015 at 11:45:35AM +0530, Archit Taneja wrote:



On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.


I see that

Re: [PATCH] ARM: Remove __ref on hotplug cpu die path

2015-09-15 Thread Andy Gross 
On Mon, Sep 14, 2015 at 05:23:17PM -0700, Stephen Boyd wrote:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
> 
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
> 
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.



Acked-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: [RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-09-15 Thread Rob Herring 
On 09/15/2015 05:32 AM, Archit Taneja wrote:
> Hi Rob, Mark,
> 
> We've been trying to figure out the right way to represent a class
> of display encoder devices in DT.

I've been meaning to reply on this.

> These devices have registers that are generally configured via i2c. Once
> the device is configured, it takes in video data from the mipi
> dsi bus.
> 
> Until now, all the devices we've supported devices that can be are
> configured by the dsi bus itself, and hence, we've been able to
> represent them in DT as children under the dsi host.
> 
> For the above class of devices (using both i2c and dsi), we aren't
> able to conclude upon what's the better approach among the two:
> 
> 1. Represent the device via 2 different nodes in DT. One would be
> a child under an i2c adapter, the other a child of a dsi host. We
> would have two device drivers, one i2c client, and the other a
> mipi dsi device.
> 
> 2. Represent the device as an i2c client in DT. Provide an api
> to create "dummy" dsi devices. The i2c client driver would use
> this api to register a dsi device, and link itself with the dsi
> host.
> 
> What do you think would be the way to go here? I guess you
> might have faced something similar in other subsystems.

The closest thing I can think of are WiFi/BT combo chips that use
SDIO+UART. In that case, 2 nodes makes sense as these chips are
essentially 2 independent functions in a single chip and both interfaces
are control interfaces (as well as data). This case is a bit different
with both interfaces being tied to the same function.

So in this case, I think option 2 is the right way for the reasons
already outlined in this thread. I think there needs to be more
consistency in how the of-graph connections are defined with the core
doing more of the graph traversing. So having an i2c device plus
of-graph seems more consistent with other non-DSI cases.

The main open issue seemed to be setting the VC. At least for the
ADV7533, it can be whatever you want it to be. The host and device just
need to agree. I see no need for that to be in DT at least in this case.
But then I'm not sure what are typical constraints for VC assignment.
I'd guess that constraints are on the device side and hosts can support
whatever the device wants. If so, then it can purely be up to the driver
to set.

Implementation-wise, I don't think that I'd call this a dummy device.
There are multiple ways for devices to get created in the driver model.
DT is just one way. You are just creating the device in a different way
outside of DT which is fine.

Rob

> I've given a relatively brief description of the problem. There
> were some more nitty gritties discussed in this thread before.
> 
> Thierry, Andrzej, Lucas,
> 
> Please feel free to add your comments if I have missed out on
> something.
> 
> Thanks,
> Archit
> 
> On 09/10/2015 01:02 PM, Thierry Reding wrote:
>> On Thu, Sep 10, 2015 at 11:45:35AM +0530, Archit Taneja wrote:
>>>
>>>
>>> On 09/08/2015 03:57 PM, Andrzej Hajda wrote:
 On 09/07/2015 01:46 PM, Archit Taneja wrote:
> Thierry,
>
> On 08/21/2015 11:39 AM, Archit Taneja wrote:
>>
>>
>> On 08/20/2015 05:18 PM, Thierry Reding wrote:
>>> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
 Hi Thierry, Lucas,


 On 08/19/2015 08:32 PM, Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
 Hi Thierry, Archit,

>> [...]
> Perhaps a better way would be to invert this relationship.
> According to
> your proposal we'd have to have DT like this:
>
>  i2c@... {
>  ...
>
>  dsi-device@... {
>  ...
>  dsi-bus = <>;
>  ...
>  };
>
>  ...
>  };
>
>  dsi@... {
>  ...
>  };
>
> Inversing the relationship would become something like this:
>
>  i2c@... {
>  ...
>  };
>
>  dsi@... {
>  ...
>
>  peripheral@... {
>  ...
>  i2c-bus = <>;
>  ...
>  };
>
>  ...
>  };
>
> Both of those aren't fundamentally different, and they both
> have
> the
> disavantage of lacking ways to transport configuration data
> that
> the
> other bus needs to

[PATCH 3/3] FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

2015-09-15 Thread Stephen Boyd 
Now that we have a generic library function for this, replace the
open-coded instance.

Cc: Hauke Mehrtens 
Cc: Rafał Miłecki 
Cc: Paul Walmsley 
Cc: 
Signed-off-by: Stephen Boyd 
---
 drivers/firmware/broadcom/bcm47xx_nvram.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c 
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index e41594510b97..8f46e6e394b1 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -56,9 +56,7 @@ static u32 find_nvram_size(void __iomem *end)
 static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
 {
struct nvram_header __iomem *header;
-   int i;
u32 off;
-   u32 *src, *dst;
u32 size;
 
if (nvram_len) {
@@ -95,10 +93,7 @@ static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
return -ENXIO;
 
 found:
-   src = (u32 *)header;
-   dst = (u32 *)nvram_buf;
-   for (i = 0; i < sizeof(struct nvram_header); i += 4)
-   *dst++ = __raw_readl(src++);
+   __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
header = (struct nvram_header *)nvram_buf;
nvram_len = header->len;
if (nvram_len > size) {
@@ -111,8 +106,8 @@ found:
nvram_len = NVRAM_SPACE - 1;
}
/* proceed reading data after header */
-   for (; i < nvram_len; i += 4)
-   *dst++ = readl(src++);
+   __ioread32_copy(nvram_buf + sizeof(*header), header + 1,
+   DIV_ROUND_UP(nvram_len / 4));
nvram_buf[NVRAM_SPACE - 1] = '\0';
 
return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH 1/3] lib: iomap_copy: Add __ioread32_copy()

2015-09-15 Thread Stephen Boyd 
Some drivers need to read data out of iomem areas 32-bits at a
time. Add an API to do this.

Cc: Bjorn Andersson 
Signed-off-by: Stephen Boyd 
---
 include/linux/io.h |  1 +
 lib/iomap_copy.c   | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/io.h b/include/linux/io.h
index de64c1e53612..72c35e0a41d1 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -29,6 +29,7 @@ struct device;
 struct resource;
 
 __visible void __iowrite32_copy(void __iomem *to, const void *from, size_t 
count);
+void __ioread32_copy(void *to, const void __iomem *from, size_t count);
 void __iowrite64_copy(void __iomem *to, const void *from, size_t count);
 
 #ifdef CONFIG_MMU
diff --git a/lib/iomap_copy.c b/lib/iomap_copy.c
index 4527e751b5e0..f174d4759ef3 100644
--- a/lib/iomap_copy.c
+++ b/lib/iomap_copy.c
@@ -42,6 +42,29 @@ void __attribute__((weak)) __iowrite32_copy(void __iomem *to,
 EXPORT_SYMBOL_GPL(__iowrite32_copy);
 
 /**
+ * __ioread32_copy - copy data from MMIO space, in 32-bit units
+ * @to: destination (must be 32-bit aligned)
+ * @from: source, in MMIO space (must be 32-bit aligned)
+ * @count: number of 32-bit quantities to copy
+ *
+ * Copy data from MMIO space to kernel space, in units of 32 bits at a
+ * time.  Order of access is not guaranteed, nor is a memory barrier
+ * performed afterwards.
+ */
+void __attribute__((weak)) __ioread32_copy(void *to,
+  const void __iomem *from,
+  size_t count)
+{
+   u32 *dst = to;
+   const u32 __iomem *src = from;
+   const u32 __iomem *end = src + count;
+
+   while (src < end)
+   *dst++ = __raw_readl(src++);
+}
+EXPORT_SYMBOL_GPL(__ioread32_copy);
+
+/**
  * __iowrite64_copy - copy data to MMIO space, in 64-bit or 32-bit units
  * @to: destination, in MMIO space (must be 64-bit aligned)
  * @from: source (must be 64-bit aligned)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH 0/3] Add __ioread32_copy() and use it

2015-09-15 Thread Stephen Boyd 
The SMD driver is reading and writing chunks of data to iomem,
and there's an __iowrite32_copy() function for the writing part, but
no __ioread32_copy() function for the reading part. This series
adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
case this should go through the -mm tree. Otherwise the target
of this patch series is SMD, so I've sent it to Andy.

Stephen Boyd (3):
  lib: iomap_copy: Add __ioread32_copy()
  soc: qcom: smd: Use __ioread32_copy() instead of open-coding it
  FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

 drivers/firmware/broadcom/bcm47xx_nvram.c | 11 +++
 drivers/soc/qcom/smd.c| 13 -
 include/linux/io.h|  1 +
 lib/iomap_copy.c  | 23 +++
 4 files changed, 31 insertions(+), 17 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH 2/3] soc: qcom: smd: Use __ioread32_copy() instead of open-coding it

2015-09-15 Thread Stephen Boyd 
Now that we have a generic library function for this, replace the
open-coded instance.

Cc: Bjorn Andersson 
Signed-off-by: Stephen Boyd 
---

Note this patch relies on a previous patch on the list that
changes the readl() to __raw_readl()[1].

 drivers/soc/qcom/smd.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index e2f85a714243..e81eac28b5ce 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -434,20 +434,15 @@ static void smd_copy_to_fifo(void __iomem *dst,
 /*
  * Copy count bytes of data using 32bit accesses, if that is required.
  */
-static void smd_copy_from_fifo(void *_dst,
-  const void __iomem *_src,
+static void smd_copy_from_fifo(void *dst,
+  const void __iomem *src,
   size_t count,
   bool word_aligned)
 {
-   u32 *dst = (u32 *)_dst;
-   u32 *src = (u32 *)_src;
-
if (word_aligned) {
-   count /= sizeof(u32);
-   while (count--)
-   *dst++ = __raw_readl(src++);
+   __ioread32_copy(dst, src, count / sizeof(u32));
} else {
-   memcpy_fromio(_dst, _src, count);
+   memcpy_fromio(dst, src, count);
}
 }
 
-- 

[1] 
http://lkml.kernel.org/g/1441234011-4259-7-git-send-email-sb...@codeaurora.org

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] ARM: Remove __ref on hotplug cpu die path

2015-09-15 Thread Sudeep Holla 



On 15/09/15 01:23, Stephen Boyd wrote:

Now that __cpuinit has been removed, the __ref markings on these
functions are useless. Remove them. This also reduces the size of
the multi_v7_defconfig image:

$ size before after
textdata bss dec hex filename
126835781470996  348904 14503478 dd4e36 before
126832741470996  348904 14503174 dd4d06 after

presumably because now we don't have to jump to code in the
.ref.text section and/or the noinline marking is removed.

Cc: Tony Lindgren 
Cc: Barry Song 
Cc: Andy Gross 
Cc: Viresh Kumar 
Cc: Shiraz Hashim 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Linus Walleij 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Stephen Boyd 
---

This patch can be broken up into per-SoC if desired.



[...]


  arch/arm/mach-vexpress/hotplug.c | 2 +-


Acked-by: Sudeep Holla 

Regards,
--
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: [RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-09-15 Thread Archit Taneja 

Hi Rob, Mark,

We've been trying to figure out the right way to represent a class
of display encoder devices in DT.

These devices have registers that are generally configured via i2c. Once 
the device is configured, it takes in video data from the mipi

dsi bus.

Until now, all the devices we've supported devices that can be are
configured by the dsi bus itself, and hence, we've been able to
represent them in DT as children under the dsi host.

For the above class of devices (using both i2c and dsi), we aren't
able to conclude upon what's the better approach among the two:

1. Represent the device via 2 different nodes in DT. One would be
a child under an i2c adapter, the other a child of a dsi host. We
would have two device drivers, one i2c client, and the other a
mipi dsi device.

2. Represent the device as an i2c client in DT. Provide an api
to create "dummy" dsi devices. The i2c client driver would use
this api to register a dsi device, and link itself with the dsi
host.

What do you think would be the way to go here? I guess you
might have faced something similar in other subsystems.

I've given a relatively brief description of the problem. There
were some more nitty gritties discussed in this thread before.

Thierry, Andrzej, Lucas,

Please feel free to add your comments if I have missed out on
something.

Thanks,
Archit

On 09/10/2015 01:02 PM, Thierry Reding wrote:

On Thu, Sep 10, 2015 at 11:45:35AM +0530, Archit Taneja wrote:



On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.


I see that

[PATCH 03/10] drm/msm: Fix IOMMU clean up path in case msm_iommu_new() fails

2015-09-15 Thread Stephane Viau 
msm_iommu_new() can fail and this change makes sure that we
detect the failure and free the allocated domain before going
any further.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 1 +
 drivers/gpu/drm/msm/msm_gpu.c   | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 14ac20a..e11028c6 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -590,6 +590,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
if (IS_ERR(mmu)) {
ret = PTR_ERR(mmu);
dev_err(dev->dev, "failed to init iommu: %d\n", ret);
+   iommu_domain_free(config->platform.iommu);
goto fail;
}
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 5d31b5a..aed9f37 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -651,6 +651,14 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
if (iommu) {
dev_info(drm->dev, "%s: using IOMMU\n", name);
gpu->mmu = msm_iommu_new(>dev, iommu);
+   if (IS_ERR(gpu->mmu)) {
+   ret = PTR_ERR(gpu->mmu);
+   dev_err(drm->dev, "failed to init iommu: %d\n", ret);
+   gpu->mmu = NULL;
+   iommu_domain_free(iommu);
+   goto fail;
+   }
+
} else {
dev_info(drm->dev, "%s: no IOMMU, fallback to VRAM 
carveout!\n", name);
}
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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] ARM: Remove __ref on hotplug cpu die path

2015-09-15 Thread Thierry Reding 
On Mon, Sep 14, 2015 at 05:23:17PM -0700, Stephen Boyd wrote:
[...]
>  arch/arm/mach-tegra/hotplug.c| 2 +-

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCHv2 3/4] power: Add Qualcomm SMBB driver

2015-09-15 Thread Bjorn Andersson 
On Tue 15 Sep 05:43 PDT 2015, Sebastian Reichel wrote:

> Hi,
> 
> On Thu, Jul 30, 2015 at 10:53:56AM -0700, Bjorn Andersson wrote:
> > From: Courtney Cavin 
> > 
> > Add the Qualcomm Switch-Mode Battery Charger and Boost driver, found in
> > pm8941.
> > 
> > Signed-off-by: Courtney Cavin 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > Changes since v1:
> > - Corrected authorship
> > - Dropped MODULE_ALIAS
> 
> Acked-By: Sebastian Reichel 
> 
> I think the first patch made it into 4.3, so I can simply queue this
> patch together with the DT binding?
> 

That is correct, sorry for it not being mentioned in the thread.

Thanks,
Bjorn
--
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

[PATCH 05/10] drm/msm/mdp5: Vote for SMMU power when performing translations

2015-09-15 Thread Stephane Viau 
On most recent chipsets, clients need to vote for SMMU power
(regulator and clock) themselves for as long as they want the
SMMU to be on, performing translations.

This change enables (disables) the SMMU power just before
attaching (after detaching) MDP5 device to the SMMU.

Signed-off-by: Stephane Viau 
---
 Documentation/devicetree/bindings/drm/msm/mdp.txt |  3 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 65 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++
 3 files changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 0833eda..99ba764 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -19,6 +19,9 @@ Optional properties:
 - gpus: phandle for gpu device
 - clock-names: the following clocks are optional:
   * "lut_clk"
+  * "iommu_clk"
+  * "mmagic_clk"
+- mmagic-supply: phandle for mmagic GDSC regulator used during IOMMU 
translation
 
 Example:
 
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 61fcb41..983bd53 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -129,6 +129,54 @@ static void mdp5_preclose(struct msm_kms *kms, struct 
drm_file *file)
mdp5_crtc_cancel_pending_flip(priv->crtcs[i], file);
 }
 
+static int mdp5_translation_ctrl_pwr(struct mdp5_kms *mdp5_kms, bool on)
+{
+   struct device *dev = mdp5_kms->dev->dev;
+   int ret;
+
+   if (on) {
+   if (mdp5_kms->mmagic) {
+   ret = regulator_enable(mdp5_kms->mmagic);
+   if (ret) {
+   dev_err(dev, "failed to enable mmagic GDSC: 
%d\n", ret);
+   return ret;
+   }
+   }
+   if (mdp5_kms->mmagic_clk) {
+   clk_prepare_enable(mdp5_kms->mmagic_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable mmagic_clk\n");
+   goto undo_gdsc;
+   }
+   }
+   if (mdp5_kms->iommu_clk) {
+   ret = clk_prepare_enable(mdp5_kms->iommu_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable iommu_clk\n");
+   goto undo_mmagic_clk;
+   }
+   }
+   } else {
+   if (mdp5_kms->iommu_clk)
+   clk_disable_unprepare(mdp5_kms->iommu_clk);
+   if (mdp5_kms->mmagic_clk)
+   clk_disable_unprepare(mdp5_kms->mmagic_clk);
+   if (mdp5_kms->mmagic)
+   regulator_disable(mdp5_kms->mmagic);
+   }
+
+   return 0;
+
+undo_mmagic_clk:
+   if (mdp5_kms->mmagic_clk)
+   clk_disable_unprepare(mdp5_kms->mmagic_clk);
+undo_gdsc:
+   if (mdp5_kms->mmagic)
+   regulator_disable(mdp5_kms->mmagic);
+
+   return ret;
+}
+
 static void mdp5_destroy(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
@@ -138,6 +186,7 @@ static void mdp5_destroy(struct msm_kms *kms)
 
if (mmu) {
mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
+   mdp5_translation_ctrl_pwr(mdp5_kms, false);
mmu->funcs->destroy(mmu);
}
 
@@ -520,6 +569,13 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
goto fail;
}
 
+   mdp5_kms->mmagic = devm_regulator_get_optional(>dev, "mmagic");
+   if (IS_ERR(mdp5_kms->mmagic)) {
+   ret = PTR_ERR(mdp5_kms->mmagic);
+   DBG("failed to get mmagic GDSC regulator: %d\n", ret);
+   mdp5_kms->mmagic = NULL;
+   }
+
/* mandatory clocks: */
ret = get_clk(pdev, _kms->axi_clk, "bus_clk", true);
if (ret)
@@ -539,6 +595,8 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
 
/* optional clocks: */
get_clk(pdev, _kms->lut_clk, "lut_clk", false);
+   get_clk(pdev, _kms->mmagic_clk, "mmagic_clk", false);
+   get_clk(pdev, _kms->iommu_clk, "iommu_clk", false);
 
/* we need to set a default rate before enabling.  Set a safe
 * rate first, then figure out hw revision, and then set a
@@ -612,6 +670,13 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
DBG("coherent hardware translation table walks is off");
}
 
+   ret = mdp5_translation_ctrl_pwr(mdp5_kms, true);
+   if (ret) {
+   dev_err(dev->dev, "failed to power iommu: %d\n", ret);
+   mmu->funcs->destroy(mmu);
+   goto fail;
+   }
+

[PATCH 06/10] drm/msm/hdmi: Add basic HDMI support for msm8996

2015-09-15 Thread Stephane Viau 
The HDMI controller is new in MDP5 v1.7. As of now, this change
doesn't reflect the novelty and only adds the basics so the probe
gets triggered.

Signed-off-by: Stephane Viau 
---
 Documentation/devicetree/bindings/drm/msm/hdmi.txt |  3 +++
 drivers/gpu/drm/msm/hdmi/hdmi.c| 17 ++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt 
b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
index e926239..379ee2e 100644
--- a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
@@ -2,6 +2,7 @@ Qualcomm adreno/snapdragon hdmi output
 
 Required properties:
 - compatible: one of the following
+   * "qcom,hdmi-tx-8996"
* "qcom,hdmi-tx-8994"
* "qcom,hdmi-tx-8084"
* "qcom,hdmi-tx-8974"
@@ -21,6 +22,7 @@ Required properties:
 Optional properties:
 - qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
 - qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
+- power-domains: reference to the power domain(s), if available.
 - pinctrl-names: the pin control state names; should contain "default"
 - pinctrl-0: the default pinctrl state (active)
 - pinctrl-1: the "sleep" pinctrl state
@@ -35,6 +37,7 @@ Example:
reg-names = "core_physical";
reg = <0x04a0 0x1000>;
interrupts = ;
+   power-domains = < MDSS_GDSC>;
clock-names =
"core_clk",
"master_iface_clk",
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 101b324..1f4a95e 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -328,6 +328,9 @@ fail:
.item ## _names = item ##_names_ ## entry, \
.item ## _cnt   = ARRAY_SIZE(item ## _names_ ## entry)
 
+static const char *pwr_reg_names_none[] = {};
+static const char *hpd_reg_names_none[] = {};
+
 static struct hdmi_platform_config hdmi_tx_8660_config = {
.phy_init = hdmi_phy_8x60_init,
 };
@@ -367,18 +370,26 @@ static struct hdmi_platform_config hdmi_tx_8084_config = {
.hpd_freq  = hpd_clk_freq_8x74,
 };
 
-static const char *hpd_reg_names_8x94[] = {};
-
 static struct hdmi_platform_config hdmi_tx_8994_config = {
.phy_init = NULL, /* nothing to do for this HDMI PHY 20nm */
HDMI_CFG(pwr_reg, 8x74),
-   HDMI_CFG(hpd_reg, 8x94),
+   HDMI_CFG(hpd_reg, none),
+   HDMI_CFG(pwr_clk, 8x74),
+   HDMI_CFG(hpd_clk, 8x74),
+   .hpd_freq  = hpd_clk_freq_8x74,
+};
+
+static struct hdmi_platform_config hdmi_tx_8996_config = {
+   .phy_init = NULL,
+   HDMI_CFG(pwr_reg, none),
+   HDMI_CFG(hpd_reg, none),
HDMI_CFG(pwr_clk, 8x74),
HDMI_CFG(hpd_clk, 8x74),
.hpd_freq  = hpd_clk_freq_8x74,
 };
 
 static const struct of_device_id dt_match[] = {
+   { .compatible = "qcom,hdmi-tx-8996", .data = _tx_8996_config },
{ .compatible = "qcom,hdmi-tx-8994", .data = _tx_8994_config },
{ .compatible = "qcom,hdmi-tx-8084", .data = _tx_8084_config },
{ .compatible = "qcom,hdmi-tx-8974", .data = _tx_8974_config },
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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

[PATCH 09/10] drm/msm/mdp: Add Software Pixel Extension support

2015-09-15 Thread Stephane Viau 
In order to produce an image, the scalar needs to be fed extra
pixels. These top/bottom/left/right values depend on a various of
factors, including resolution, scaling type, phase step and
initial phase.

Pixel Extension are programmed by hardware in most targets - and
can be overwritten by software. For some targets (e.g.: msm8996),
software *must* program those registers.

In order to ease this computation, let's always use bilinear
filters, which are easier to program from kernel. Eventually,
all of these values will come down from user space for better
quality.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 158 --
 drivers/gpu/drm/msm/mdp/mdp_kms.h |   1 +
 2 files changed, 128 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index c294033..c86f49f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -542,40 +542,120 @@ static int calc_scaley_steps(struct drm_plane *plane,
return 0;
 }
 
-static uint32_t get_scale_config(enum mdp_chroma_samp_type chroma_sample,
-   uint32_t src, uint32_t dest, bool hor)
+static uint32_t get_scale_config(const struct mdp_format *format,
+   uint32_t src, uint32_t dst, bool horz)
 {
-   uint32_t y_filter =   (src <= dest) ? SCALE_FILTER_CA  : 
SCALE_FILTER_PCMN;
-   uint32_t y_a_filter = (src <= dest) ? SCALE_FILTER_BIL : 
SCALE_FILTER_PCMN;
-   uint32_t uv_filter = ((src / 2) <= dest) ? /* 2x upsample */
-   SCALE_FILTER_BIL : SCALE_FILTER_PCMN;
-   uint32_t value = 0;
-
-   if (chroma_sample == CHROMA_420 || chroma_sample == CHROMA_H2V1) {
-   if (hor)
-   value = MDP5_PIPE_SCALE_CONFIG_SCALEX_EN |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_0(y_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_3(y_a_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_1_2(uv_filter);
-   else
-   value = MDP5_PIPE_SCALE_CONFIG_SCALEY_EN |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_0(y_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_3(y_a_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_1_2(uv_filter);
-   } else if (src != dest) {
-   if (hor)
-   value = MDP5_PIPE_SCALE_CONFIG_SCALEX_EN |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_0(y_a_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_3(y_a_filter);
-   else
-   value = MDP5_PIPE_SCALE_CONFIG_SCALEY_EN |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_0(y_a_filter) |
-   
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_3(y_a_filter);
+   bool scaling = format->is_yuv ? true : (src != dst);
+   uint32_t sub, pix_fmt = format->base.pixel_format;
+   uint32_t ya_filter, uv_filter;
+   bool yuv = format->is_yuv;
+
+   if (!scaling)
+   return 0;
+
+   if (yuv) {
+   sub = horz ? drm_format_horz_chroma_subsampling(pix_fmt) :
+drm_format_vert_chroma_subsampling(pix_fmt);
+   uv_filter = ((src / sub) <= dst) ?
+  SCALE_FILTER_BIL : SCALE_FILTER_PCMN;
}
+   ya_filter = (src <= dst) ? SCALE_FILTER_BIL : SCALE_FILTER_PCMN;
+
+   if (horz)
+   return  MDP5_PIPE_SCALE_CONFIG_SCALEX_EN |
+   MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_0(ya_filter) |
+   MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_3(ya_filter) |
+   COND(yuv, 
MDP5_PIPE_SCALE_CONFIG_SCALEX_FILTER_COMP_1_2(uv_filter));
+   else
+   return  MDP5_PIPE_SCALE_CONFIG_SCALEY_EN |
+   MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_0(ya_filter) |
+   MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_3(ya_filter) |
+   COND(yuv, 
MDP5_PIPE_SCALE_CONFIG_SCALEY_FILTER_COMP_1_2(uv_filter));
+}
+
+static void calc_pixel_ext(const struct mdp_format *format,
+   uint32_t src, uint32_t dst, uint32_t phase_step[2],
+   int pix_ext_edge1[COMP_MAX], int pix_ext_edge2[COMP_MAX],
+   bool horz)
+{
+   bool scaling = format->is_yuv ? true : (src != dst);
+   int i;
+
+   /*
+* Note:
+* We assume here that:
+* 1. PCMN filter is used for downscale
+* 2. bilinear filter is used for upscale
+* 3. we are in a single pipe configuration
+*/
 
-   return value;
+   for (i = 0; i < COMP_MAX; i++) {

[PATCH 07/10] drm/msm/mdp: Update generated headers (Pixel Extension)

2015-09-15 Thread Stephane Viau 
This change is the output of Envytools change:

"rnndb: Add Pixel Extension registers"

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h  | 82 +++-
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h | 11 -
 2 files changed, 90 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index af9b932..bb4eae3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,9 +8,9 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
36021 bytes, from 2015-07-31 21:25:50)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
37194 bytes, from 2015-07-31 21:28:36)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2015-04-30 16:26:30)
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2576 bytes, from 2015-07-31 21:25:50)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2849 bytes, from 2015-07-31 21:28:36)
 
 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
@@ -887,6 +887,7 @@ static inline uint32_t MDP5_PIPE_SRC_OP_MODE_BWC(enum 
mdp5_pipe_bwc val)
 #define MDP5_PIPE_SRC_OP_MODE_IGC_ROM_1
0x0004
 #define MDP5_PIPE_SRC_OP_MODE_DEINTERLACE  0x0040
 #define MDP5_PIPE_SRC_OP_MODE_DEINTERLACE_ODD  0x0080
+#define MDP5_PIPE_SRC_OP_MODE_SW_PIX_EXT_OVERRIDE  0x8000
 
 static inline uint32_t REG_MDP5_PIPE_SRC_CONSTANT_COLOR(enum mdp5_pipe i0) { 
return 0x003c + __offset_PIPE(i0); }
 
@@ -924,6 +925,83 @@ static inline uint32_t MDP5_PIPE_DECIMATION_HORZ(uint32_t 
val)
return ((val) << MDP5_PIPE_DECIMATION_HORZ__SHIFT) & 
MDP5_PIPE_DECIMATION_HORZ__MASK;
 }
 
+static inline uint32_t __offset_SW_PIX_EXT(enum mdp_component_type idx)
+{
+   switch (idx) {
+   case COMP_0: return 0x0100;
+   case COMP_1_2: return 0x0110;
+   case COMP_3: return 0x0120;
+   default: return INVALID_IDX(idx);
+   }
+}
+static inline uint32_t REG_MDP5_PIPE_SW_PIX_EXT(enum mdp5_pipe i0, enum 
mdp_component_type i1) { return 0x + __offset_PIPE(i0) + 
__offset_SW_PIX_EXT(i1); }
+
+static inline uint32_t REG_MDP5_PIPE_SW_PIX_EXT_LR(enum mdp5_pipe i0, enum 
mdp_component_type i1) { return 0x + __offset_PIPE(i0) + 
__offset_SW_PIX_EXT(i1); }
+#define MDP5_PIPE_SW_PIX_EXT_LR_LEFT_RPT__MASK 0x00ff
+#define MDP5_PIPE_SW_PIX_EXT_LR_LEFT_RPT__SHIFT0
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_LR_LEFT_RPT(uint32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_LR_LEFT_RPT__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_LR_LEFT_RPT__MASK;
+}
+#define MDP5_PIPE_SW_PIX_EXT_LR_LEFT_OVF__MASK 0xff00
+#define MDP5_PIPE_SW_PIX_EXT_LR_LEFT_OVF__SHIFT8
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_LR_LEFT_OVF(int32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_LR_LEFT_OVF__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_LR_LEFT_OVF__MASK;
+}
+#define MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_RPT__MASK
0x00ff
+#define MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_RPT__SHIFT   16
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_RPT(uint32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_RPT__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_RPT__MASK;
+}
+#define MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_OVF__MASK
0xff00
+#define MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_OVF__SHIFT   24
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_OVF(int32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_OVF__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_LR_RIGHT_OVF__MASK;
+}
+
+static inline uint32_t REG_MDP5_PIPE_SW_PIX_EXT_TB(enum mdp5_pipe i0, enum 
mdp_component_type i1) { return 0x0004 + __offset_PIPE(i0) + 
__offset_SW_PIX_EXT(i1); }
+#define MDP5_PIPE_SW_PIX_EXT_TB_TOP_RPT__MASK  0x00ff
+#define MDP5_PIPE_SW_PIX_EXT_TB_TOP_RPT__SHIFT 0
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_TB_TOP_RPT(uint32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_TB_TOP_RPT__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_TB_TOP_RPT__MASK;
+}
+#define MDP5_PIPE_SW_PIX_EXT_TB_TOP_OVF__MASK  0xff00
+#define MDP5_PIPE_SW_PIX_EXT_TB_TOP_OVF__SHIFT 8
+static inline uint32_t MDP5_PIPE_SW_PIX_EXT_TB_TOP_OVF(int32_t val)
+{
+   return ((val) << MDP5_PIPE_SW_PIX_EXT_TB_TOP_OVF__SHIFT) & 
MDP5_PIPE_SW_PIX_EXT_TB_TOP_OVF__MASK;
+}
+#define MDP5_PIPE_SW_PIX_EXT_TB_BOTTOM_RPT__MASK

[PATCH 10/10] drm/msm/mdp5: Basic support for MDP5 v1.7 (MSM8996)

2015-09-15 Thread Stephane Viau 
This change adds the basic MDP5 support for MSM8996.

Signed-off-by: Stephane Viau 
---
 Documentation/devicetree/bindings/drm/msm/mdp.txt |  2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   | 95 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h   |  9 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 18 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 18 +++--
 drivers/gpu/drm/msm/mdp/mdp_kms.h |  5 ++
 7 files changed, 135 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 99ba764..0114a87 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -22,6 +22,7 @@ Optional properties:
   * "iommu_clk"
   * "mmagic_clk"
 - mmagic-supply: phandle for mmagic GDSC regulator used during IOMMU 
translation
+- iommus: phandle for IOMMU v2 device
 
 Example:
 
@@ -48,5 +49,6 @@ Example:
< TV_SRC>,
< HDMI_TV_CLK>,
< MDP_TV_CLK>;
+   iommus = <_smmu 0>;
};
 };
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index a1e26f2..bb1225a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -27,6 +27,8 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
.mdp = {
.count = 1,
.base = { 0x00100 },
+   .caps = MDP_CAP_SMP |
+   0,
},
.smp = {
.mmb_count = 22,
@@ -96,6 +98,8 @@ const struct mdp5_cfg_hw msm8x74v2_config = {
.mdp = {
.count = 1,
.base = { 0x00100 },
+   .caps = MDP_CAP_SMP |
+   0,
},
.smp = {
.mmb_count = 22,
@@ -165,6 +169,8 @@ const struct mdp5_cfg_hw apq8084_config = {
.mdp = {
.count = 1,
.base = { 0x00100 },
+   .caps = MDP_CAP_SMP |
+   0,
},
.smp = {
.mmb_count = 44,
@@ -242,6 +248,8 @@ const struct mdp5_cfg_hw msm8x16_config = {
.mdp = {
.count = 1,
.base = { 0x01000 },
+   .caps = MDP_CAP_SMP |
+   0,
},
.smp = {
.mmb_count = 8,
@@ -301,6 +309,8 @@ const struct mdp5_cfg_hw msm8x94_config = {
.mdp = {
.count = 1,
.base = { 0x01000 },
+   .caps = MDP_CAP_SMP |
+   0,
},
.smp = {
.mmb_count = 44,
@@ -370,7 +380,89 @@ const struct mdp5_cfg_hw msm8x94_config = {
[3] = INTF_HDMI,
},
},
-   .max_clk = 32000,
+   .max_clk = 4,
+};
+
+const struct mdp5_cfg_hw msm8x96_config = {
+   .name = "msm8x96",
+   .mdp = {
+   .count = 1,
+   .base = { 0x01000 },
+   .caps = MDP_CAP_DSC |
+   MDP_CAP_CDM |
+   0,
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+   .flush_hw_mask = 0xf4ff,
+   },
+   .pipe_vig = {
+   .count = 4,
+   .base = { 0x05000, 0x07000, 0x09000, 0x0b000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SCALE  |
+   MDP_PIPE_CAP_CSC|
+   MDP_PIPE_CAP_DECIMATION |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .pipe_rgb = {
+   .count = 4,
+   .base = { 0x15000, 0x17000, 0x19000, 0x1b000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SCALE  |
+   MDP_PIPE_CAP_DECIMATION |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .pipe_dma = {
+   .count = 2,
+   .base = { 0x25000, 0x27000 },
+   .caps = MDP_PIPE_CAP_HFLIP  |
+   MDP_PIPE_CAP_VFLIP  |
+   MDP_PIPE_CAP_SW_PIX_EXT |
+   0,
+   },
+   .lm = {
+   .count = 6,
+   .base = { 0x45000, 0x46000, 0x47000, 0x48000, 0x49000, 0x4a000 
},
+   .nb_stages = 8,
+   .max_width = 2560,
+   .max_height = 0x,
+   },
+   .dspp = {
+   .count = 2,
+   .base = { 0x55000, 0x57000 },
+   },
+   .ad = {
+   .count =

[PATCH 04/10] drm/msm/mdp5: Avoid printing error messages for optional clocks

2015-09-15 Thread Stephane Viau 
The current behavior is to try to get optional clocks and print a
dev_err message in case of failure. This looks rather confusing
and may increase with the amount of optional clocks.

We may need a cleaner way to handle per-device clocks but in the
meantime, let's reduce the amount of dev_err messages during the
probe.

Signed-off-by: Stephane Viau 
---
 Documentation/devicetree/bindings/drm/msm/mdp.txt |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 27 ++-
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 1a0598e..0833eda 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -11,13 +11,14 @@ Required properties:
 - clock-names: the following clocks are required:
   * "core_clk"
   * "iface_clk"
-  * "lut_clk"
   * "src_clk"
   * "hdmi_clk"
   * "mpd_clk"
 
 Optional properties:
 - gpus: phandle for gpu device
+- clock-names: the following clocks are optional:
+  * "lut_clk"
 
 Example:
 
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index e11028c6..61fcb41 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -454,15 +454,19 @@ static void read_hw_revision(struct mdp5_kms *mdp5_kms,
 }
 
 static int get_clk(struct platform_device *pdev, struct clk **clkp,
-   const char *name)
+   const char *name, bool mandatory)
 {
struct device *dev = >dev;
struct clk *clk = devm_clk_get(dev, name);
-   if (IS_ERR(clk)) {
+   if (IS_ERR(clk) && mandatory) {
dev_err(dev, "failed to get %s (%ld)\n", name, PTR_ERR(clk));
return PTR_ERR(clk);
}
-   *clkp = clk;
+   if (IS_ERR(clk))
+   DBG("skipping %s", name);
+   else
+   *clkp = clk;
+
return 0;
 }
 
@@ -516,25 +520,26 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
goto fail;
}
 
-   ret = get_clk(pdev, _kms->axi_clk, "bus_clk");
+   /* mandatory clocks: */
+   ret = get_clk(pdev, _kms->axi_clk, "bus_clk", true);
if (ret)
goto fail;
-   ret = get_clk(pdev, _kms->ahb_clk, "iface_clk");
+   ret = get_clk(pdev, _kms->ahb_clk, "iface_clk", true);
if (ret)
goto fail;
-   ret = get_clk(pdev, _kms->src_clk, "core_clk_src");
+   ret = get_clk(pdev, _kms->src_clk, "core_clk_src", true);
if (ret)
goto fail;
-   ret = get_clk(pdev, _kms->core_clk, "core_clk");
+   ret = get_clk(pdev, _kms->core_clk, "core_clk", true);
if (ret)
goto fail;
-   ret = get_clk(pdev, _kms->lut_clk, "lut_clk");
-   if (ret)
-   DBG("failed to get (optional) lut_clk clock");
-   ret = get_clk(pdev, _kms->vsync_clk, "vsync_clk");
+   ret = get_clk(pdev, _kms->vsync_clk, "vsync_clk", true);
if (ret)
goto fail;
 
+   /* optional clocks: */
+   get_clk(pdev, _kms->lut_clk, "lut_clk", false);
+
/* we need to set a default rate before enabling.  Set a safe
 * rate first, then figure out hw revision, and then set a
 * more optimal rate:
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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: [PATCHv2 3/4] power: Add Qualcomm SMBB driver

2015-09-15 Thread Sebastian Reichel 
Hi,

On Thu, Jul 30, 2015 at 10:53:56AM -0700, Bjorn Andersson wrote:
> From: Courtney Cavin 
> 
> Add the Qualcomm Switch-Mode Battery Charger and Boost driver, found in
> pm8941.
> 
> Signed-off-by: Courtney Cavin 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v1:
> - Corrected authorship
> - Dropped MODULE_ALIAS

Acked-By: Sebastian Reichel 

I think the first patch made it into 4.3, so I can simply queue this
patch together with the DT binding?

-- Sebastian


signature.asc
Description: Digital signature

[PATCH 01/10] drm/msm/mdp5: remove the cfg pointer from SMP struct

2015-09-15 Thread Stephane Viau 
We want to make sure we control all the information being passed
down to SMP block. Having access to the cfg pointer here may create
bad things in the future.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index efb918d..a6facaf 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -61,7 +61,7 @@ struct mdp5_smp_block {
int mmb_size;   /* MMB: size in bytes */
uint32_t clients[MAX_CLIENTS];  /* SMP port allocation /pipe */
mdp5_smp_state_t reserved_state;/* SMP MMBs statically allocated */
-   int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
+   uint8_t reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
 };
 
 #define MDP5_INTF_NUM_MAX  5
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 563cca9..6f425c2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -90,7 +90,7 @@
 struct mdp5_smp {
struct drm_device *dev;
 
-   const struct mdp5_smp_block *cfg;
+   uint8_t reserved[MAX_CLIENTS]; /* fixed MMBs allocation per client */
 
int blk_cnt;
int blk_size;
@@ -141,10 +141,10 @@ static int smp_request_block(struct mdp5_smp *smp,
struct mdp5_kms *mdp5_kms = get_kms(smp);
struct mdp5_client_smp_state *ps = >client_state[cid];
int i, ret, avail, cur_nblks, cnt = smp->blk_cnt;
-   int reserved;
+   uint8_t reserved;
unsigned long flags;
 
-   reserved = smp->cfg->reserved[cid];
+   reserved = smp->reserved[cid];
 
spin_lock_irqsave(>state_lock, flags);
 
@@ -405,12 +405,12 @@ struct mdp5_smp *mdp5_smp_init(struct drm_device *dev, 
const struct mdp5_smp_blo
}
 
smp->dev = dev;
-   smp->cfg = cfg;
smp->blk_cnt = cfg->mmb_count;
smp->blk_size = cfg->mmb_size;
 
/* statically tied MMBs cannot be re-allocated: */
bitmap_copy(smp->state, cfg->reserved_state, smp->blk_cnt);
+   memcpy(smp->reserved, cfg->reserved, sizeof(smp->reserved));
spin_lock_init(>state_lock);
 
return smp;
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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

[PATCH 00/10] drm/msm: Add support for MSM8996

2015-09-15 Thread Stephane Viau 
This series of patches adds support for MSM8996, including MDP5 v1.7.
Note that only the HDMI interface is supported for now. 

Stephane Viau (10):
  drm/msm/mdp5: remove the cfg pointer from SMP struct
  drm/msm/mdp5: Disable hardware translation table walks (MSM8996)
  drm/msm: Fix IOMMU clean up path in case msm_iommu_new() fails
  drm/msm/mdp5: Avoid printing error messages for optional clocks
  drm/msm/mdp5: Vote for SMMU power when performing translations
  drm/msm/hdmi: Add basic HDMI support for msm8996
  drm/msm/mdp: Update generated headers (Pixel Extension)
  drm/msm/mdp5: Use the newly introduced enum mdp_component_type
  drm/msm/mdp: Add Software Pixel Extension support
  drm/msm/mdp5: Basic support for MDP5 v1.7 (MSM8996)

 Documentation/devicetree/bindings/drm/msm/hdmi.txt |   3 +
 Documentation/devicetree/bindings/drm/msm/mdp.txt  |   8 +-
 drivers/gpu/drm/msm/hdmi/hdmi.c|  17 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h|  82 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c|  95 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h|  11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 126 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h|   5 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c  | 201 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c|   8 +-
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h   |  11 +-
 drivers/gpu/drm/msm/mdp/mdp_kms.h  |   6 +
 drivers/gpu/drm/msm/msm_gpu.c  |   8 +
 13 files changed, 501 insertions(+), 80 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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

[PATCH 02/10] drm/msm/mdp5: Disable hardware translation table walks (MSM8996)

2015-09-15 Thread Stephane Viau 
On certain targets (eg, MSM8996) we need to set the following
domain attribute for correct operation of the SMMU:
DOMAIN_ATTR_COHERENT_HTW_DISABLE.

Setting that attribute is very important on 8996. Without it, we would
see crazy translation faults.

Note:
There could be support for coherent hardware table walks in
the future

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index bbab6e6..14ac20a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -584,6 +584,8 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
mdelay(16);
 
if (config->platform.iommu) {
+   int rev = mdp5_cfg_get_hw_rev(mdp5_kms->cfg);
+
mmu = msm_iommu_new(>dev, config->platform.iommu);
if (IS_ERR(mmu)) {
ret = PTR_ERR(mmu);
@@ -591,6 +593,19 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
goto fail;
}
 
+   /*
+* On certain targets (8996, for example) we need to set the
+* following domain attribute for correct operation of the SMMU;
+* Without it, we would see crazy translation faults..
+*/
+   if (rev == 7) {
+   int disable_htw = 1;
+
+   iommu_domain_set_attr(config->platform.iommu,
+   DOMAIN_ATTR_COHERENT_HTW_DISABLE, _htw);
+   DBG("coherent hardware translation table walks is off");
+   }
+
ret = mmu->funcs->attach(mmu, iommu_ports,
ARRAY_SIZE(iommu_ports));
if (ret) {
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
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