[PATCH net] rxrpc: Wake up the transmitter if Rx window size increases on the peer

2017-03-09 Thread David Howells
The RxRPC ACK packet may contain an extension that includes the peer's
current Rx window size for this call.  We adjust the local Tx window size
to match.  However, the transmitter can stall if the receive window is
reduced to 0 by the peer and then reopened.

This is because the normal way that the transmitter is re-energised is by
dropping something out of our Tx queue and thus making space.  When a
single gap is made, the transmitter is woken up.  However, because there's
nothing in the Tx queue at this point, this doesn't happen.

To fix this, perform a wake_up() any time we see the peer's Rx window size
increasing.

The observable symptom is that calls start failing on ETIMEDOUT and the
following:

kAFS: SERVER DEAD state=-62

appears in dmesg.

Signed-off-by: David Howells 
---

 net/rxrpc/input.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index d74921c4969b..18b2ad8be8e2 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -652,6 +652,7 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_peer *peer;
unsigned int mtu;
+   bool wake = false;
u32 rwind = ntohl(ackinfo->rwind);
 
_proto("Rx ACK %%%u Info { rx=%u max=%u rwin=%u jm=%u }",
@@ -659,9 +660,14 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
   ntohl(ackinfo->rxMTU), ntohl(ackinfo->maxMTU),
   rwind, ntohl(ackinfo->jumbo_max));
 
-   if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
-   rwind = RXRPC_RXTX_BUFF_SIZE - 1;
-   call->tx_winsize = rwind;
+   if (call->tx_winsize != rwind) {
+   if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
+   rwind = RXRPC_RXTX_BUFF_SIZE - 1;
+   if (rwind > call->tx_winsize)
+   wake = true;
+   call->tx_winsize = rwind;
+   }
+
if (call->cong_ssthresh > rwind)
call->cong_ssthresh = rwind;
 
@@ -675,6 +681,9 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
spin_unlock_bh(>lock);
_net("Net MTU %u (maxdata %u)", peer->mtu, peer->maxdata);
}
+
+   if (wake)
+   wake_up(>waitq);
 }
 
 /*



[PATCH net] rxrpc: Wake up the transmitter if Rx window size increases on the peer

2017-03-09 Thread David Howells
The RxRPC ACK packet may contain an extension that includes the peer's
current Rx window size for this call.  We adjust the local Tx window size
to match.  However, the transmitter can stall if the receive window is
reduced to 0 by the peer and then reopened.

This is because the normal way that the transmitter is re-energised is by
dropping something out of our Tx queue and thus making space.  When a
single gap is made, the transmitter is woken up.  However, because there's
nothing in the Tx queue at this point, this doesn't happen.

To fix this, perform a wake_up() any time we see the peer's Rx window size
increasing.

The observable symptom is that calls start failing on ETIMEDOUT and the
following:

kAFS: SERVER DEAD state=-62

appears in dmesg.

Signed-off-by: David Howells 
---

 net/rxrpc/input.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index d74921c4969b..18b2ad8be8e2 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -652,6 +652,7 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_peer *peer;
unsigned int mtu;
+   bool wake = false;
u32 rwind = ntohl(ackinfo->rwind);
 
_proto("Rx ACK %%%u Info { rx=%u max=%u rwin=%u jm=%u }",
@@ -659,9 +660,14 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
   ntohl(ackinfo->rxMTU), ntohl(ackinfo->maxMTU),
   rwind, ntohl(ackinfo->jumbo_max));
 
-   if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
-   rwind = RXRPC_RXTX_BUFF_SIZE - 1;
-   call->tx_winsize = rwind;
+   if (call->tx_winsize != rwind) {
+   if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
+   rwind = RXRPC_RXTX_BUFF_SIZE - 1;
+   if (rwind > call->tx_winsize)
+   wake = true;
+   call->tx_winsize = rwind;
+   }
+
if (call->cong_ssthresh > rwind)
call->cong_ssthresh = rwind;
 
@@ -675,6 +681,9 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, 
struct sk_buff *skb,
spin_unlock_bh(>lock);
_net("Net MTU %u (maxdata %u)", peer->mtu, peer->maxdata);
}
+
+   if (wake)
+   wake_up(>waitq);
 }
 
 /*



Re: [PATCH] powerpc: asm: convert directive .llong to .8byte

2017-03-09 Thread Michael Ellerman
Daniel Axtens  writes:

> Hi Tobin,
>
>> .llong is an undocumented PPC specific directive. The generic
>> equivalent is .quad, but even better (because it's self describing) is
>> .8byte.
>>
>> Convert directives .llong -> .8byte
>>
>> Signed-off-by: Tobin C. Harding 
>> ---
>>
>> Fixes: issue #33 (github)
>
> Thanks for tackling these!
>
> I have applied your patch to my local tree. I ran `git grep '\.llong'`,
> and found:
>
> tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S: .llong 
> 0x
>
> That file is also handled by mpe and the powerpc tree even though it
> doesn't live in arch/powerpc - could you please change that one as well?

I can do that one when I apply it.

cheers


Re: [PATCH] powerpc: asm: convert directive .llong to .8byte

2017-03-09 Thread Michael Ellerman
Daniel Axtens  writes:

> Hi Tobin,
>
>> .llong is an undocumented PPC specific directive. The generic
>> equivalent is .quad, but even better (because it's self describing) is
>> .8byte.
>>
>> Convert directives .llong -> .8byte
>>
>> Signed-off-by: Tobin C. Harding 
>> ---
>>
>> Fixes: issue #33 (github)
>
> Thanks for tackling these!
>
> I have applied your patch to my local tree. I ran `git grep '\.llong'`,
> and found:
>
> tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S: .llong 
> 0x
>
> That file is also handled by mpe and the powerpc tree even though it
> doesn't live in arch/powerpc - could you please change that one as well?

I can do that one when I apply it.

cheers


Re: [RFC] mm/compaction: ignore block suitable after check large free page

2017-03-09 Thread Vlastimil Babka
On 03/10/2017 05:20 AM, Yisheng Xie wrote:
> If the migrate target is a large free page and we ignore suitable,
> it may not good for defrag. So move the ignore block suitable after
> check large free page.

Right. But in practice I expect close to no impact, because direct
compaction shouldn't have to be called if there's a >=pageblock_order
page already available.

> Signed-off-by: Yisheng Xie 
> ---
>  mm/compaction.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0fdfde0..4bf2a5d 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -991,9 +991,6 @@ static bool too_many_isolated(struct zone *zone)
>  static bool suitable_migration_target(struct compact_control *cc,
>   struct page *page)
>  {
> - if (cc->ignore_block_suitable)
> - return true;
> -
>   /* If the page is a large free page, then disallow migration */
>   if (PageBuddy(page)) {
>   /*
> @@ -1005,6 +1002,9 @@ static bool suitable_migration_target(struct 
> compact_control *cc,
>   return false;
>   }
>  
> + if (cc->ignore_block_suitable)
> + return true;
> +
>   /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
>   if (migrate_async_suitable(get_pageblock_migratetype(page)))
>   return true;
> 



Re: [RFC] mm/compaction: ignore block suitable after check large free page

2017-03-09 Thread Vlastimil Babka
On 03/10/2017 05:20 AM, Yisheng Xie wrote:
> If the migrate target is a large free page and we ignore suitable,
> it may not good for defrag. So move the ignore block suitable after
> check large free page.

Right. But in practice I expect close to no impact, because direct
compaction shouldn't have to be called if there's a >=pageblock_order
page already available.

> Signed-off-by: Yisheng Xie 
> ---
>  mm/compaction.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0fdfde0..4bf2a5d 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -991,9 +991,6 @@ static bool too_many_isolated(struct zone *zone)
>  static bool suitable_migration_target(struct compact_control *cc,
>   struct page *page)
>  {
> - if (cc->ignore_block_suitable)
> - return true;
> -
>   /* If the page is a large free page, then disallow migration */
>   if (PageBuddy(page)) {
>   /*
> @@ -1005,6 +1002,9 @@ static bool suitable_migration_target(struct 
> compact_control *cc,
>   return false;
>   }
>  
> + if (cc->ignore_block_suitable)
> + return true;
> +
>   /* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
>   if (migrate_async_suitable(get_pageblock_migratetype(page)))
>   return true;
> 



Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

2017-03-09 Thread Marek Vasut
On 03/10/2017 07:38 AM, Maxime Ripard wrote:
> Hi Marek,
> 
> On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
>> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
>>> On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut  wrote:
 On 03/07/2017 09:26 AM, Alban wrote:
> Config data for drivers, like MAC addresses, is often stored in MTD.
> Add a binding that define how such data storage can be represented in
> device tree.
>
> Signed-off-by: Alban 
> ---
> Changelog:
> v2: * Added a "Required properties" section with the nvmem-provider
>   property
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt 
> b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> new file mode 100644
> index 000..8ed25e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,33 @@
> += NVMEM in MTD =
> +
> +Config data for drivers, like MAC addresses, is often stored in MTD.
> +This binding define how such data storage can be represented in device 
> tree.
> +
> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> +property to their node. Data cells can then be defined as child nodes
> +of the partition as defined in nvmem.txt.

 Why don't we just read the data from MTD and be done with it ? What's
 the benefit of complicating things by using nvmem ?
>>>
>>> Well because usually stuff like MAC addresses etc are stored in eeproms.
>>
>> But eeproms are already supported, see drivers/misc/ .
> 
> This the old, free for all, way to support eeproms. We have a proper
> framework for them now, and it's called nvmem.

Ha, so that's why this patchset, I see. Thanks for clarifying.

-- 
Best regards,
Marek Vasut


Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

2017-03-09 Thread Marek Vasut
On 03/10/2017 07:38 AM, Maxime Ripard wrote:
> Hi Marek,
> 
> On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
>> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
>>> On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut  wrote:
 On 03/07/2017 09:26 AM, Alban wrote:
> Config data for drivers, like MAC addresses, is often stored in MTD.
> Add a binding that define how such data storage can be represented in
> device tree.
>
> Signed-off-by: Alban 
> ---
> Changelog:
> v2: * Added a "Required properties" section with the nvmem-provider
>   property
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt 
> b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> new file mode 100644
> index 000..8ed25e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,33 @@
> += NVMEM in MTD =
> +
> +Config data for drivers, like MAC addresses, is often stored in MTD.
> +This binding define how such data storage can be represented in device 
> tree.
> +
> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> +property to their node. Data cells can then be defined as child nodes
> +of the partition as defined in nvmem.txt.

 Why don't we just read the data from MTD and be done with it ? What's
 the benefit of complicating things by using nvmem ?
>>>
>>> Well because usually stuff like MAC addresses etc are stored in eeproms.
>>
>> But eeproms are already supported, see drivers/misc/ .
> 
> This the old, free for all, way to support eeproms. We have a proper
> framework for them now, and it's called nvmem.

Ha, so that's why this patchset, I see. Thanks for clarifying.

-- 
Best regards,
Marek Vasut


Re: [PATCH] refcount: add refcount_t API kernel-doc comments

2017-03-09 Thread Ingo Molnar

* David Windsor  wrote:

> This adds kernel-doc comments for the new refcount_t API.
> 
> v2: incorporate fixes from Peter Zijlstra and Ingo Molnar
> 
> Signed-off-by: David Windsor 
> ---
>  lib/refcount.c | 122 
> +++--
>  1 file changed, 110 insertions(+), 12 deletions(-)

Patch does not apply cleanly anymore, could you please merge it to Linus's 
latest 
and resend?

Thanks!

Ingo


Re: [PATCH] refcount: add refcount_t API kernel-doc comments

2017-03-09 Thread Ingo Molnar

* David Windsor  wrote:

> This adds kernel-doc comments for the new refcount_t API.
> 
> v2: incorporate fixes from Peter Zijlstra and Ingo Molnar
> 
> Signed-off-by: David Windsor 
> ---
>  lib/refcount.c | 122 
> +++--
>  1 file changed, 110 insertions(+), 12 deletions(-)

Patch does not apply cleanly anymore, could you please merge it to Linus's 
latest 
and resend?

Thanks!

Ingo


Re: [GIT pull] CPU hotplug updates for 4.9

2017-03-09 Thread Ingo Molnar

* Bart Van Assche  wrote:

> On Thu, 2017-03-09 at 18:43 +0100, Thomas Gleixner wrote:
> > Ok, so it's random. Now it would be interesting what the rest of the system
> > does when this happens. I still have no idea why that IOAT setting has any
> > influence.
> 
> Hello Thomas,
> 
> The cpuhp_issue_call() hang happens during boot and before I get the chance 
> to log
> in with ssh. Can you be more specific about what information you are looking 
> for?
> 
> Anyway, the result of a new bisect I ran is as follows:
> * good: 631ddaba5905 ("Merge branches 'pm-sleep' and 'powercap'").
> * good: 80f1b3dea9d4 ("Merge branch 'device-properties'").
> * bad:  a67485d4bf97 ("Merge tag 'acpi-4.10-rc1' of
>   git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm").
> 
> Does this make sense to you?

The bisection information is really useful, if the failure mode is 
deterministic.

It would be nice to have more bisection points, the above range is about 5,000 
commits.

Thanks,

Ingo


Re: [GIT pull] CPU hotplug updates for 4.9

2017-03-09 Thread Ingo Molnar

* Bart Van Assche  wrote:

> On Thu, 2017-03-09 at 18:43 +0100, Thomas Gleixner wrote:
> > Ok, so it's random. Now it would be interesting what the rest of the system
> > does when this happens. I still have no idea why that IOAT setting has any
> > influence.
> 
> Hello Thomas,
> 
> The cpuhp_issue_call() hang happens during boot and before I get the chance 
> to log
> in with ssh. Can you be more specific about what information you are looking 
> for?
> 
> Anyway, the result of a new bisect I ran is as follows:
> * good: 631ddaba5905 ("Merge branches 'pm-sleep' and 'powercap'").
> * good: 80f1b3dea9d4 ("Merge branch 'device-properties'").
> * bad:  a67485d4bf97 ("Merge tag 'acpi-4.10-rc1' of
>   git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm").
> 
> Does this make sense to you?

The bisection information is really useful, if the failure mode is 
deterministic.

It would be nice to have more bisection points, the above range is about 5,000 
commits.

Thanks,

Ingo


Re: [PATCH 1/2] x86/nmi: Optimize the check for being in the repeat_nmi code

2017-03-09 Thread Ingo Molnar

* Andy Lutomirski  wrote:

> > It had nothing to do with speedup. Linus said that the current code makes 
> > the 
> > assembly programmer in him die a little. I want to cure that.
> 
> One might argue that the world would be a better place if the assembly 
> programmer in some people died a little.

Joking aside, I'll bite: while in the kernel we try to avoid ever actually 
_writing_ new assembly code, assembly programming is still an invaluable skill, 
because it indirectly improves all the other 99% of non-assembly .c code:

 - Looking at the C compiler's assembly output tells us how close the code is to
   optimal.

 - Being able to tell whether our C abstractions are too far removed from how 
the
   compiler will map it to machine instructions is invaluable.

 - Being able to shape data structures and code in a machine-friendly way.

Much would be lost if the assembly programmer went extinct and it's no 
accident that annotated assembly output is just two  keys away
after launching 'perf top' or 'perf report'. The more developers know
assembly the better, IMHO.

Thanks,

Ingo


Re: [PATCH 1/2] x86/nmi: Optimize the check for being in the repeat_nmi code

2017-03-09 Thread Ingo Molnar

* Andy Lutomirski  wrote:

> > It had nothing to do with speedup. Linus said that the current code makes 
> > the 
> > assembly programmer in him die a little. I want to cure that.
> 
> One might argue that the world would be a better place if the assembly 
> programmer in some people died a little.

Joking aside, I'll bite: while in the kernel we try to avoid ever actually 
_writing_ new assembly code, assembly programming is still an invaluable skill, 
because it indirectly improves all the other 99% of non-assembly .c code:

 - Looking at the C compiler's assembly output tells us how close the code is to
   optimal.

 - Being able to tell whether our C abstractions are too far removed from how 
the
   compiler will map it to machine instructions is invaluable.

 - Being able to shape data structures and code in a machine-friendly way.

Much would be lost if the assembly programmer went extinct and it's no 
accident that annotated assembly output is just two  keys away
after launching 'perf top' or 'perf report'. The more developers know
assembly the better, IMHO.

Thanks,

Ingo


Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2017-03-09 Thread Baolin Wang
On 10 March 2017 at 14:30, Jun Li  wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port.  Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. 
>> Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy  and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).

That will include these implementation when adding extcon_dev.

> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to 
> findup it.

PMIC can find extcon device by phandle.

>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?

>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.

-- 
Baolin.wang
Best Regards


Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2017-03-09 Thread Baolin Wang
On 10 March 2017 at 14:30, Jun Li  wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port.  Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. 
>> Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy  and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).

That will include these implementation when adding extcon_dev.

> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to 
> findup it.

PMIC can find extcon device by phandle.

>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?

>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.

-- 
Baolin.wang
Best Regards


Re: [RFC PATCH] phy: samsung: move the Samsung specific phy files to "samsung" directory

2017-03-09 Thread Jaehoon Chung
Hi All,

On 03/09/2017 09:10 PM, Krzysztof Kozlowski wrote:
> On Thu, Mar 9, 2017 at 1:56 PM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Thursday 09 March 2017 05:03 PM, Jaehoon Chung wrote:
>>> Make the "samsung" directory and move the Samsung specific files to
>>> there for maintaining the files relevant to Samsung.
>>
>> The number of phy drivers in drivers/phy is getting unmanageable. I think 
>> this
>> is a good step to make it a little better. Can you also add a MAINTAINER for
>> drivers/phy/samsung?
> 
> There is such:
> 
> 10903 SAMSUNG USB2 PHY DRIVER
> 10904 M:  Kamil Debski 
> 10905 M:  Sylwester Nawrocki 
> 10906 L:  linux-kernel@vger.kernel.org
> 10907 S:  Supported
> 10908 F:  Documentation/devicetree/bindings/phy/samsung-phy.txt
> 10909 F:  Documentation/phy/samsung-usb2.txt
> 10910 F:  drivers/phy/phy-exynos4210-usb2.c
> 10911 F:  drivers/phy/phy-exynos4x12-usb2.c
> 10912 F:  drivers/phy/phy-exynos5250-usb2.c
> 10913 F:  drivers/phy/phy-s5pv210-usb2.c
> 10914 F:  drivers/phy/phy-samsung-usb2.c
> 10915 F:  drivers/phy/phy-samsung-usb2.h
> 
> but this patchset does not update it. Paths *everywhere* have to be updated.

Will update..How about the below updating?
M:  Kamil Debski 
M:  Sylwester Nawrocki 
M:  Jaehoon Chung 
L:  linux-kernel@vger.kernel.org
S:  Supported
F:  Documentation/devicetree/bindings/phy/samsung-phy.txt
F:  Documentation/phy/samsung-usb2.txt
F:  driver/phy/samsung/

Let me know your opinion.

Best Regards,
Jaehoon Chung

> 
> Best regards,
> Krzysztof
> 
> 
> 



Re: [RFC PATCH] phy: samsung: move the Samsung specific phy files to "samsung" directory

2017-03-09 Thread Jaehoon Chung
Hi All,

On 03/09/2017 09:10 PM, Krzysztof Kozlowski wrote:
> On Thu, Mar 9, 2017 at 1:56 PM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Thursday 09 March 2017 05:03 PM, Jaehoon Chung wrote:
>>> Make the "samsung" directory and move the Samsung specific files to
>>> there for maintaining the files relevant to Samsung.
>>
>> The number of phy drivers in drivers/phy is getting unmanageable. I think 
>> this
>> is a good step to make it a little better. Can you also add a MAINTAINER for
>> drivers/phy/samsung?
> 
> There is such:
> 
> 10903 SAMSUNG USB2 PHY DRIVER
> 10904 M:  Kamil Debski 
> 10905 M:  Sylwester Nawrocki 
> 10906 L:  linux-kernel@vger.kernel.org
> 10907 S:  Supported
> 10908 F:  Documentation/devicetree/bindings/phy/samsung-phy.txt
> 10909 F:  Documentation/phy/samsung-usb2.txt
> 10910 F:  drivers/phy/phy-exynos4210-usb2.c
> 10911 F:  drivers/phy/phy-exynos4x12-usb2.c
> 10912 F:  drivers/phy/phy-exynos5250-usb2.c
> 10913 F:  drivers/phy/phy-s5pv210-usb2.c
> 10914 F:  drivers/phy/phy-samsung-usb2.c
> 10915 F:  drivers/phy/phy-samsung-usb2.h
> 
> but this patchset does not update it. Paths *everywhere* have to be updated.

Will update..How about the below updating?
M:  Kamil Debski 
M:  Sylwester Nawrocki 
M:  Jaehoon Chung 
L:  linux-kernel@vger.kernel.org
S:  Supported
F:  Documentation/devicetree/bindings/phy/samsung-phy.txt
F:  Documentation/phy/samsung-usb2.txt
F:  driver/phy/samsung/

Let me know your opinion.

Best Regards,
Jaehoon Chung

> 
> Best regards,
> Krzysztof
> 
> 
> 



Re: [PATCH] sched: Wake up all non-exclusive waiters in __wake_up_common()

2017-03-09 Thread Byungchul Park
On Wed, Mar 08, 2017 at 09:21:52AM +0900, Byungchul Park wrote:
> __wake_up_common() should wake up all non-exclusive waiters and
> exclusive waiters as many as nr_exclusive, but currently it does not.
> 
> Consider a wait queue like the following for example:
> 
>A(exclusive) -> B(non-exclusive) -> C(non-exclusive)
> 
> Current code will wake up only A when nr_exclusive = 1, but has to wake
> up A, B and C. Make it do as we expect.

I'm wondering if I was wrong. Am I wrong?

> 
> Signed-off-by: Byungchul Park 
> ---
>  kernel/sched/wait.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 9453efe..0ea1083 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -67,12 +67,23 @@ static void __wake_up_common(wait_queue_head_t *q, 
> unsigned int mode,
>  {
>   wait_queue_t *curr, *next;
>  
> + /*
> +  * We use nr_exclusive = 0 to wake up all no matter whether
> +  * WQ_FLAG_EXCLUSIVE is set. However, we have to distinguish
> +  * between the case and having finished all exclusive wake-up.
> +  * So make nr_exclusive non-zero in advance in the former case.
> +  */
> + nr_exclusive = nr_exclusive ?: -1;
> +
>   list_for_each_entry_safe(curr, next, >task_list, task_list) {
>   unsigned flags = curr->flags;
>  
> + if ((flags & WQ_FLAG_EXCLUSIVE) && !nr_exclusive)
> + continue;
> +
>   if (curr->func(curr, mode, wake_flags, key) &&
> - (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
> - break;
> + (flags & WQ_FLAG_EXCLUSIVE))
> + nr_exclusive--;
>   }
>  }
>  
> -- 
> 1.9.1


Re: [PATCH] sched: Wake up all non-exclusive waiters in __wake_up_common()

2017-03-09 Thread Byungchul Park
On Wed, Mar 08, 2017 at 09:21:52AM +0900, Byungchul Park wrote:
> __wake_up_common() should wake up all non-exclusive waiters and
> exclusive waiters as many as nr_exclusive, but currently it does not.
> 
> Consider a wait queue like the following for example:
> 
>A(exclusive) -> B(non-exclusive) -> C(non-exclusive)
> 
> Current code will wake up only A when nr_exclusive = 1, but has to wake
> up A, B and C. Make it do as we expect.

I'm wondering if I was wrong. Am I wrong?

> 
> Signed-off-by: Byungchul Park 
> ---
>  kernel/sched/wait.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 9453efe..0ea1083 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -67,12 +67,23 @@ static void __wake_up_common(wait_queue_head_t *q, 
> unsigned int mode,
>  {
>   wait_queue_t *curr, *next;
>  
> + /*
> +  * We use nr_exclusive = 0 to wake up all no matter whether
> +  * WQ_FLAG_EXCLUSIVE is set. However, we have to distinguish
> +  * between the case and having finished all exclusive wake-up.
> +  * So make nr_exclusive non-zero in advance in the former case.
> +  */
> + nr_exclusive = nr_exclusive ?: -1;
> +
>   list_for_each_entry_safe(curr, next, >task_list, task_list) {
>   unsigned flags = curr->flags;
>  
> + if ((flags & WQ_FLAG_EXCLUSIVE) && !nr_exclusive)
> + continue;
> +
>   if (curr->func(curr, mode, wake_flags, key) &&
> - (flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
> - break;
> + (flags & WQ_FLAG_EXCLUSIVE))
> + nr_exclusive--;
>   }
>  }
>  
> -- 
> 1.9.1


Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

2017-03-09 Thread Willy Tarreau
Hi Jacek,

On Thu, Mar 09, 2017 at 09:48:39PM +0100, Jacek Anaszewski wrote:
> Hi Willy,
> 
> Thanks for the patch.
> 
> Unfortunately I'm getting following build break, while trying to
> test it on recent linux-next:
> 
> drivers/leds/trigger/ledtrig-activity.c: In function
> 'led_activity_function':
> drivers/leds/trigger/ledtrig-activity.c:67:14: error: implicit
> declaration of function 'cputime64_to_jiffies64'
> [-Werror=implicit-function-declaration]
>   curr_idle = cputime64_to_jiffies64(curr_idle);

Thanks for letting me know, I'll check this ASAP.

Cheers,
Willy


Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

2017-03-09 Thread Willy Tarreau
Hi Jacek,

On Thu, Mar 09, 2017 at 09:48:39PM +0100, Jacek Anaszewski wrote:
> Hi Willy,
> 
> Thanks for the patch.
> 
> Unfortunately I'm getting following build break, while trying to
> test it on recent linux-next:
> 
> drivers/leds/trigger/ledtrig-activity.c: In function
> 'led_activity_function':
> drivers/leds/trigger/ledtrig-activity.c:67:14: error: implicit
> declaration of function 'cputime64_to_jiffies64'
> [-Werror=implicit-function-declaration]
>   curr_idle = cputime64_to_jiffies64(curr_idle);

Thanks for letting me know, I'll check this ASAP.

Cheers,
Willy


[PATCH] Fix V8 device information issue

2017-03-09 Thread Masaki Ota
From: Masaki Ota 
-Fix the issue that V8(E7=73 03 28) devices are not assined correct device 
information from OTP.
-Specified correct OTP bit for the V8 device setting of Button pad, DualPoint 
and Touchpad size.

Signed-off-by: Masaki Ota 
---
 drivers/input/mouse/alps.c | 74 --
 drivers/input/mouse/alps.h |  6 
 2 files changed, 64 insertions(+), 16 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index e761955..462871c 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2467,21 +2467,46 @@ static int alps_update_device_area_ss4_v2(unsigned char 
otp[][4],
int num_y_electrode;
int x_pitch, y_pitch, x_phys, y_phys;
 
-   num_x_electrode = SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
-   num_y_electrode = SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
+   if (priv->dev_id[2] == 0x28) {
+   num_x_electrode =
+   SS4PLUS_NUMSENSOR_XOFFSET + (otp[0][2] & 0x0F);
+   num_y_electrode =
+   SS4PLUS_NUMSENSOR_YOFFSET + ((otp[0][2] >> 4) & 0x0F);
 
-   priv->x_max = (num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
-   priv->y_max = (num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+   priv->x_max =
+   (num_x_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
+   priv->y_max =
+   (num_y_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
 
-   x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
-   y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
+   x_pitch = (otp[0][1] & 0x0F) + SS4PLUS_MIN_PITCH_MM;
+   y_pitch = ((otp[0][1] >> 4) & 0x0F) + SS4PLUS_MIN_PITCH_MM;
 
-   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
-   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
+   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
+   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
 
-   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
-   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
+   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+
+   } else {
+   num_x_electrode =
+   SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
+   num_y_electrode =
+   SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
+
+   priv->x_max =
+   (num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+   priv->y_max =
+   (num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+
+   x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
+   y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
 
+   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
+   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
+
+   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
+   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+   }
return 0;
 }
 
@@ -2490,7 +2515,10 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
 {
unsigned char is_btnless;
 
-   is_btnless = (otp[1][1] >> 3) & 0x01;
+   if (priv->dev_id[2] == 0x28)
+   is_btnless = (otp[1][0] >> 1) & 0x01;
+   else
+   is_btnless = (otp[1][1] >> 3) & 0x01;
 
if (is_btnless)
priv->flags |= ALPS_BUTTONPAD;
@@ -2498,6 +2526,21 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
return 0;
 }
 
+static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
+  struct alps_data *priv)
+{
+   unsigned char is_dual = 0;
+
+   if (priv->dev_id[2] == 0x28)
+   is_dual = (otp[0][0] >> 4) & 0x01;
+
+   if (is_dual)
+   priv->flags |= ALPS_DUALPOINT |
+   ALPS_DUALPOINT_WITH_PRESSURE;
+
+   return 0;
+}
+
 static int alps_set_defaults_ss4_v2(struct psmouse *psmouse,
struct alps_data *priv)
 {
@@ -2513,6 +2556,8 @@ static int alps_set_defaults_ss4_v2(struct psmouse 
*psmouse,
 
alps_update_btn_info_ss4_v2(otp, priv);
 
+   alps_update_dual_info_ss4_v2(otp, priv);
+
return 0;
 }
 
@@ -2758,10 +2803,6 @@ static int alps_set_protocol(struct psmouse *psmouse,
if (alps_set_defaults_ss4_v2(psmouse, priv))
return -EIO;
 
-   if (priv->fw_ver[1] == 0x1)
-   priv->flags |= ALPS_DUALPOINT |
-   ALPS_DUALPOINT_WITH_PRESSURE;
-
break;

[PATCH] Fix V8 device information issue

2017-03-09 Thread Masaki Ota
From: Masaki Ota 
-Fix the issue that V8(E7=73 03 28) devices are not assined correct device 
information from OTP.
-Specified correct OTP bit for the V8 device setting of Button pad, DualPoint 
and Touchpad size.

Signed-off-by: Masaki Ota 
---
 drivers/input/mouse/alps.c | 74 --
 drivers/input/mouse/alps.h |  6 
 2 files changed, 64 insertions(+), 16 deletions(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index e761955..462871c 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2467,21 +2467,46 @@ static int alps_update_device_area_ss4_v2(unsigned char 
otp[][4],
int num_y_electrode;
int x_pitch, y_pitch, x_phys, y_phys;
 
-   num_x_electrode = SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
-   num_y_electrode = SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
+   if (priv->dev_id[2] == 0x28) {
+   num_x_electrode =
+   SS4PLUS_NUMSENSOR_XOFFSET + (otp[0][2] & 0x0F);
+   num_y_electrode =
+   SS4PLUS_NUMSENSOR_YOFFSET + ((otp[0][2] >> 4) & 0x0F);
 
-   priv->x_max = (num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
-   priv->y_max = (num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+   priv->x_max =
+   (num_x_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
+   priv->y_max =
+   (num_y_electrode - 1) * SS4PLUS_COUNT_PER_ELECTRODE;
 
-   x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
-   y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
+   x_pitch = (otp[0][1] & 0x0F) + SS4PLUS_MIN_PITCH_MM;
+   y_pitch = ((otp[0][1] >> 4) & 0x0F) + SS4PLUS_MIN_PITCH_MM;
 
-   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
-   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
+   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
+   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
 
-   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
-   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
+   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+
+   } else {
+   num_x_electrode =
+   SS4_NUMSENSOR_XOFFSET + (otp[1][0] & 0x0F);
+   num_y_electrode =
+   SS4_NUMSENSOR_YOFFSET + ((otp[1][0] >> 4) & 0x0F);
+
+   priv->x_max =
+   (num_x_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+   priv->y_max =
+   (num_y_electrode - 1) * SS4_COUNT_PER_ELECTRODE;
+
+   x_pitch = ((otp[1][2] >> 2) & 0x07) + SS4_MIN_PITCH_MM;
+   y_pitch = ((otp[1][2] >> 5) & 0x07) + SS4_MIN_PITCH_MM;
 
+   x_phys = x_pitch * (num_x_electrode - 1); /* In 0.1 mm units */
+   y_phys = y_pitch * (num_y_electrode - 1); /* In 0.1 mm units */
+
+   priv->x_res = priv->x_max * 10 / x_phys; /* units / mm */
+   priv->y_res = priv->y_max * 10 / y_phys; /* units / mm */
+   }
return 0;
 }
 
@@ -2490,7 +2515,10 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
 {
unsigned char is_btnless;
 
-   is_btnless = (otp[1][1] >> 3) & 0x01;
+   if (priv->dev_id[2] == 0x28)
+   is_btnless = (otp[1][0] >> 1) & 0x01;
+   else
+   is_btnless = (otp[1][1] >> 3) & 0x01;
 
if (is_btnless)
priv->flags |= ALPS_BUTTONPAD;
@@ -2498,6 +2526,21 @@ static int alps_update_btn_info_ss4_v2(unsigned char 
otp[][4],
return 0;
 }
 
+static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
+  struct alps_data *priv)
+{
+   unsigned char is_dual = 0;
+
+   if (priv->dev_id[2] == 0x28)
+   is_dual = (otp[0][0] >> 4) & 0x01;
+
+   if (is_dual)
+   priv->flags |= ALPS_DUALPOINT |
+   ALPS_DUALPOINT_WITH_PRESSURE;
+
+   return 0;
+}
+
 static int alps_set_defaults_ss4_v2(struct psmouse *psmouse,
struct alps_data *priv)
 {
@@ -2513,6 +2556,8 @@ static int alps_set_defaults_ss4_v2(struct psmouse 
*psmouse,
 
alps_update_btn_info_ss4_v2(otp, priv);
 
+   alps_update_dual_info_ss4_v2(otp, priv);
+
return 0;
 }
 
@@ -2758,10 +2803,6 @@ static int alps_set_protocol(struct psmouse *psmouse,
if (alps_set_defaults_ss4_v2(psmouse, priv))
return -EIO;
 
-   if (priv->fw_ver[1] == 0x1)
-   priv->flags |= ALPS_DUALPOINT |
-   ALPS_DUALPOINT_WITH_PRESSURE;
-
break;
}
 
@@ -2850,7 +2891,8 @@ static int 

Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

2017-03-09 Thread Maxime Ripard
Hi Marek,

On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
> > On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut  wrote:
> >> On 03/07/2017 09:26 AM, Alban wrote:
> >>> Config data for drivers, like MAC addresses, is often stored in MTD.
> >>> Add a binding that define how such data storage can be represented in
> >>> device tree.
> >>>
> >>> Signed-off-by: Alban 
> >>> ---
> >>> Changelog:
> >>> v2: * Added a "Required properties" section with the nvmem-provider
> >>>   property
> >>> ---
> >>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 33 
> >>> ++
> >>>  1 file changed, 33 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt 
> >>> b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>> new file mode 100644
> >>> index 000..8ed25e6
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>> @@ -0,0 +1,33 @@
> >>> += NVMEM in MTD =
> >>> +
> >>> +Config data for drivers, like MAC addresses, is often stored in MTD.
> >>> +This binding define how such data storage can be represented in device 
> >>> tree.
> >>> +
> >>> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> >>> +property to their node. Data cells can then be defined as child nodes
> >>> +of the partition as defined in nvmem.txt.
> >>
> >> Why don't we just read the data from MTD and be done with it ? What's
> >> the benefit of complicating things by using nvmem ?
> > 
> > Well because usually stuff like MAC addresses etc are stored in eeproms.
> 
> But eeproms are already supported, see drivers/misc/ .

This the old, free for all, way to support eeproms. We have a proper
framework for them now, and it's called nvmem.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

2017-03-09 Thread Maxime Ripard
Hi Marek,

On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
> > On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut  wrote:
> >> On 03/07/2017 09:26 AM, Alban wrote:
> >>> Config data for drivers, like MAC addresses, is often stored in MTD.
> >>> Add a binding that define how such data storage can be represented in
> >>> device tree.
> >>>
> >>> Signed-off-by: Alban 
> >>> ---
> >>> Changelog:
> >>> v2: * Added a "Required properties" section with the nvmem-provider
> >>>   property
> >>> ---
> >>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 33 
> >>> ++
> >>>  1 file changed, 33 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt 
> >>> b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>> new file mode 100644
> >>> index 000..8ed25e6
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>> @@ -0,0 +1,33 @@
> >>> += NVMEM in MTD =
> >>> +
> >>> +Config data for drivers, like MAC addresses, is often stored in MTD.
> >>> +This binding define how such data storage can be represented in device 
> >>> tree.
> >>> +
> >>> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> >>> +property to their node. Data cells can then be defined as child nodes
> >>> +of the partition as defined in nvmem.txt.
> >>
> >> Why don't we just read the data from MTD and be done with it ? What's
> >> the benefit of complicating things by using nvmem ?
> > 
> > Well because usually stuff like MAC addresses etc are stored in eeproms.
> 
> But eeproms are already supported, see drivers/misc/ .

This the old, free for all, way to support eeproms. We have a proper
framework for them now, and it's called nvmem.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2017-03-09 Thread Jun Li


> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 9 March 2017 at 18:34, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li 
> >> Cc: NeilBrown ; Felipe Balbi ; Greg
> >> KH ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Marek Szyprowski
> >> ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li  wrote:
> >> > Hi,
> >> >
> >> >> -Original Message-
> >> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown 
> >> >> Cc: Felipe Balbi ; Greg KH
> >> >> ; Sebastian Reichel ;
> >> >> Dmitry Eremin-Solenikov ; David
> Woodhouse
> >> >> ; r...@kernel.org; Jun Li ;
> >> >> Marek Szyprowski ; Ruslan Bilovol
> >> >> ; Peter Chen
> ;
> >> >> Alan Stern ; grygorii.stras...@ti.com;
> >> >> Yoshihiro Shimoda ; Lee Jones
> >> >> ; Mark Brown ; John
> >> >> Stultz ; Charles Keepax
> >> >> ;
> >> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> >> p...@vger.kernel.org>; USB ; device-
> >> >> mainlin...@lists.linuxfoundation.org; LKML
> >> >> 
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> 

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2017-03-09 Thread Jun Li


> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 9 March 2017 at 18:34, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li 
> >> Cc: NeilBrown ; Felipe Balbi ; Greg
> >> KH ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Marek Szyprowski
> >> ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li  wrote:
> >> > Hi,
> >> >
> >> >> -Original Message-
> >> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown 
> >> >> Cc: Felipe Balbi ; Greg KH
> >> >> ; Sebastian Reichel ;
> >> >> Dmitry Eremin-Solenikov ; David
> Woodhouse
> >> >> ; r...@kernel.org; Jun Li ;
> >> >> Marek Szyprowski ; Ruslan Bilovol
> >> >> ; Peter Chen
> ;
> >> >> Alan Stern ; grygorii.stras...@ti.com;
> >> >> Yoshihiro Shimoda ; Lee Jones
> >> >> ; Mark Brown ; John
> >> >> Stultz ; Charles Keepax
> >> >> ;
> >> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> >> p...@vger.kernel.org>; USB ; device-
> >> >> mainlin...@lists.linuxfoundation.org; LKML
> >> >> 
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> >> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >> >>
> >> >> >> (2) Instead of using 'set_power' callback in phy drivers, we
> >> >> >> will introduce USB charger to set PMIC current drawn from USB
> >> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> >> implement anything to set PMIC current, thus remove them by
> >> following links:
> >> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> >> current, we can remove them in future. (I have no platform with
> >> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> >> converted 'set_power' callback to USB
> >> >> >> charger.)
> >> >> >>
> >> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> >> appropriate
> >> >> notifications.
> >> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> >> 

[PATCH v6 09/11] drivers: perf: hisi: Miscellanous node(MN) event counting in perf

2017-03-09 Thread Anurup M
From: Shaokun Zhang 

1. Add support to count MN hardware events.
2. Mn events are listed in sysfs at /sys/devices/hisi_mn_2/events/
   The events can be selected as shown in perf list
   e.g.: For MN_READ_REQUEST event for Super CPU cluster 2 the
   event format is -e "hisi_mn_2/read_req/"

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/Makefile |   2 +-
 drivers/perf/hisilicon/hisi_uncore_mn.c | 489 
 2 files changed, 490 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 0887b56..26b2507 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o
+obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o 
hisi_uncore_mn.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_mn.c 
b/drivers/perf/hisilicon/hisi_uncore_mn.c
new file mode 100644
index 000..18316dc
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_mn.c
@@ -0,0 +1,489 @@
+/*
+ * HiSilicon SoC MN Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang 
+ *
+ * This code is based on the uncore PMU's like arm-cci and
+ * arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/*
+ * ARMv8 HiSilicon MN event types.
+ */
+enum armv8_hisi_mn_event_types {
+   HISI_HWEVENT_MN_EO_BARR_REQ = 0x0,
+   HISI_HWEVENT_MN_EC_BARR_REQ = 0x01,
+   HISI_HWEVENT_MN_DVM_OP_REQ  = 0x02,
+   HISI_HWEVENT_MN_DVM_SYNC_REQ= 0x03,
+   HISI_HWEVENT_MN_READ_REQ= 0x04,
+   HISI_HWEVENT_MN_WRITE_REQ   = 0x05,
+   HISI_HWEVENT_MN_EVENT_MAX   = 0x08,
+};
+
+/*
+ * ARMv8 HiSilicon Hardware counter Index.
+ */
+enum armv8_hisi_mn_counters {
+   HISI_IDX_MN_COUNTER0= 0x0,
+   HISI_IDX_MN_COUNTER_MAX = 0x4,
+};
+
+#define HISI_MAX_CFG_MN_CNTR   0x04
+#define MN1_EVTYPE_REG_OFF 0x48
+#define MN1_EVCTRL_REG_OFF 0x40
+#define MN1_CNT0_REG_OFF 0x30
+#define MN1_EVENT_EN 0x01
+#define MN1_BANK_SELECT 0x01
+
+#define GET_MODULE_ID(hwmod_data) hwmod_data->mn_hwcfg.module_id
+
+struct hisi_mn_hwcfg {
+   u32 module_id;
+};
+
+struct hisi_mn_data {
+   struct hisi_djtag_client *client;
+   DECLARE_BITMAP(event_used_mask, HISI_MAX_CFG_MN_CNTR);
+   struct hisi_mn_hwcfg mn_hwcfg;
+};
+
+static inline int hisi_mn_counter_valid(int idx)
+{
+   return (idx >= HISI_IDX_MN_COUNTER0 &&
+   idx < HISI_IDX_MN_COUNTER_MAX);
+}
+
+/* Select the counter register offset from the index */
+static inline u32 get_counter_reg_off(int cntr_idx)
+{
+   return (MN1_CNT0_REG_OFF + (cntr_idx * 4));
+}
+
+static u32 hisi_mn_read_counter(struct hisi_mn_data *mn_data, int cntr_idx)
+{
+   struct hisi_djtag_client *client = mn_data->client;
+   u32 module_id = GET_MODULE_ID(mn_data);
+   u32 reg_off, value;
+
+   reg_off = get_counter_reg_off(cntr_idx);
+   hisi_djtag_readreg(module_id, MN1_BANK_SELECT, reg_off,
+  client, );
+
+   return value;
+}
+
+static u64 hisi_mn_event_update(struct perf_event *event,
+   struct hw_perf_event *hwc, int idx)
+{
+   struct hisi_pmu *mn_pmu = to_hisi_pmu(event->pmu);
+   struct hisi_mn_data *mn_data = mn_pmu->hwmod_data;
+   u64 delta, prev_raw_count, new_raw_count = 0;
+
+   if (!hisi_mn_counter_valid(idx)) {
+   dev_err(mn_pmu->dev,
+   "Unsupported event index:%d!\n", idx);
+   return 0;
+   }
+
+   do {
+   /* Get count from the MN */
+   prev_raw_count = local64_read(>prev_count);
+   new_raw_count = hisi_mn_read_counter(mn_data, idx);
+   delta = (new_raw_count - prev_raw_count) & HISI_MAX_PERIOD;
+
+   local64_add(delta, >count);
+   } while (local64_cmpxchg(>prev_count, prev_raw_count,
+new_raw_count) != prev_raw_count);
+
+   return new_raw_count;
+}
+
+static void hisi_mn_set_evtype(struct hisi_pmu *mn_pmu, 

[PATCH v6 11/11] dts: arm64: hip07: Add Hisilicon SoC PMU support

2017-03-09 Thread Anurup M
Add nodes for djtag, L3 cache and MN to support uncore events.

Signed-off-by: Anurup M 
---
 arch/arm64/boot/dts/hisilicon/hip07.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 5144eb1..3155ee3 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1056,4 +1056,83 @@
status = "disabled";
};
};
+
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   /* L3 cache bank 0 for socket0 CPU die scl#3 */
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   /* L3 cache bank 1 for socket0 CPU die scl#3 */
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   /* L3 cache bank 2 for socket0 CPU die scl#3 */
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   /* L3 cache bank 3 for socket0 CPU die scl#3 */
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   /*
+* Miscellaneous node for socket0
+* CPU die scl#2
+*/
+   pmumn0 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
+   };
+
+   djtag1: djtag@4001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x4001 0x0 0x1>;
+   hisilicon,scl-id = <0x01>;
+
+   /* L3 cache bank 0 for socket0 CPU die scl#1 */
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   /* L3 cache bank 1 for socket0 CPU die scl#1 */
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   /* L3 cache bank 2 for socket0 CPU die scl#1 */
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   /* L3 cache bank 3 for socket0 CPU die scl#1 */
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   /*
+* Miscellaneous node for socket0
+* CPU die scl#1
+*/
+   pmumn1 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
+   };
+
 };
-- 
2.1.4



[PATCH v6 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-03-09 Thread Anurup M
Add hrtimer support which use poll method to avoid counter overflow
when overflow IRQ is not supported in hardware.
The L3 cache PMU use N-N SPI interrupt which has no support in kernel
mainline. So use hrtimer to poll and update event counter to avoid
overflow condition for L3 cache PMU.
An interval of 10 seconds is used for the hrtimer.

Signed-off-by: Dikshit N 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 47 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 82 
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 17 +++
 3 files changed, 146 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
index 7f80d07..f23fbc2 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +55,22 @@ enum armv8_hisi_l3c_counters {
 #define L3C_CNT0_REG_OFF 0x170
 #define L3C_EVENT_EN 0x100
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz, Therefore Access time = 0.4ns
+ * L1 cache - 2 way set associative
+ * L2  - 16 way set associative
+ * L3  - 16 way set associative. L3 cache has 4 banks.
+ *
+ * Overflow time = 2^31 * (access time L1 + access time L2 + access time L3)
+ * = 2^31 * ((2 * 0.4ns) + (16 * 0.4ns) + (4 * 16 * 0.4ns)) = 70 seconds
+ *
+ * L3 cache is also used by devices like PCIe, SAS etc. at
+ * the same time. So the overflow time could be even smaller.
+ * So on a safe side we use a timer interval of 10sec
+ */
+#define L3C_HRTIMER_INTERVAL (10LL * MSEC_PER_SEC)
+
 #define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
 #define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
 
@@ -474,11 +492,24 @@ static const struct attribute_group 
hisi_l3c_cpumask_attr_group = {
.attrs = hisi_l3c_cpumask_attrs,
 };
 
+static DEVICE_ATTR(hrtimer_interval, 0444, hisi_hrtimer_interval_sysfs_show,
+  NULL);
+
+static struct attribute *hisi_l3c_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_l3c_hrtimer_interval_attr_group = {
+   .attrs = hisi_l3c_hrtimer_interval_attrs,
+};
+
 static const struct attribute_group *hisi_l3c_pmu_attr_groups[] = {
_l3c_attr_group,
_l3c_format_group,
_l3c_events_group,
_l3c_cpumask_attr_group,
+   _l3c_hrtimer_interval_attr_group,
NULL,
 };
 
@@ -494,6 +525,15 @@ static struct hisi_uncore_ops hisi_uncore_l3c_ops = {
.write_counter = hisi_l3c_write_counter,
 };
 
+/* Initialize hrtimer to poll for avoiding counter overflow */
+static void hisi_l3c_hrtimer_init(struct hisi_pmu *l3c_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   l3c_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   l3c_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(l3c_pmu, L3C_HRTIMER_INTERVAL);
+}
+
 static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 struct hisi_djtag_client *client)
 {
@@ -503,6 +543,7 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 
l3c_pmu->num_events = HISI_HWEVENT_L3C_EVENT_MAX;
l3c_pmu->num_counters = HISI_IDX_L3C_COUNTER_MAX;
+   l3c_pmu->num_active = 0;
l3c_pmu->scl_id = hisi_djtag_get_sclid(client);
 
l3c_pmu->name = kasprintf(GFP_KERNEL, "hisi_l3c%u_%u",
@@ -513,6 +554,12 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
/* Pick one core to use for cpumask attributes */
cpumask_set_cpu(smp_processor_id(), _pmu->cpu);
 
+   /*
+* Use poll method to avoid counter overflow as overflow IRQ
+* is not supported in v1,v2 hardware.
+*/
+   hisi_l3c_hrtimer_init(l3c_pmu);
+
return 0;
 }
 
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
index 0e7b5f1..787602b 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -65,6 +65,70 @@ ssize_t hisi_cpumask_sysfs_show(struct device *dev,
return cpumap_print_to_pagebuf(true, buf, _pmu->cpu);
 }
 
+/*
+ * sysfs hrtimer_interval attributes
+ */
+ssize_t hisi_hrtimer_interval_sysfs_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct pmu *pmu = dev_get_drvdata(dev);
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
+
+   if (hisi_pmu->hrt_duration)
+   return sprintf(buf, "%llu\n", hisi_pmu->hrt_duration);
+   return 0;
+}
+
+/* The counter overflow IRQ is not supported for some PMUs
+ * use hrtimer to periodically poll and avoid overflow
+ */

[PATCH v6 09/11] drivers: perf: hisi: Miscellanous node(MN) event counting in perf

2017-03-09 Thread Anurup M
From: Shaokun Zhang 

1. Add support to count MN hardware events.
2. Mn events are listed in sysfs at /sys/devices/hisi_mn_2/events/
   The events can be selected as shown in perf list
   e.g.: For MN_READ_REQUEST event for Super CPU cluster 2 the
   event format is -e "hisi_mn_2/read_req/"

Signed-off-by: Shaokun Zhang 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/Makefile |   2 +-
 drivers/perf/hisilicon/hisi_uncore_mn.c | 489 
 2 files changed, 490 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 0887b56..26b2507 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o
+obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o 
hisi_uncore_mn.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_mn.c 
b/drivers/perf/hisilicon/hisi_uncore_mn.c
new file mode 100644
index 000..18316dc
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_mn.c
@@ -0,0 +1,489 @@
+/*
+ * HiSilicon SoC MN Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang 
+ *
+ * This code is based on the uncore PMU's like arm-cci and
+ * arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/*
+ * ARMv8 HiSilicon MN event types.
+ */
+enum armv8_hisi_mn_event_types {
+   HISI_HWEVENT_MN_EO_BARR_REQ = 0x0,
+   HISI_HWEVENT_MN_EC_BARR_REQ = 0x01,
+   HISI_HWEVENT_MN_DVM_OP_REQ  = 0x02,
+   HISI_HWEVENT_MN_DVM_SYNC_REQ= 0x03,
+   HISI_HWEVENT_MN_READ_REQ= 0x04,
+   HISI_HWEVENT_MN_WRITE_REQ   = 0x05,
+   HISI_HWEVENT_MN_EVENT_MAX   = 0x08,
+};
+
+/*
+ * ARMv8 HiSilicon Hardware counter Index.
+ */
+enum armv8_hisi_mn_counters {
+   HISI_IDX_MN_COUNTER0= 0x0,
+   HISI_IDX_MN_COUNTER_MAX = 0x4,
+};
+
+#define HISI_MAX_CFG_MN_CNTR   0x04
+#define MN1_EVTYPE_REG_OFF 0x48
+#define MN1_EVCTRL_REG_OFF 0x40
+#define MN1_CNT0_REG_OFF 0x30
+#define MN1_EVENT_EN 0x01
+#define MN1_BANK_SELECT 0x01
+
+#define GET_MODULE_ID(hwmod_data) hwmod_data->mn_hwcfg.module_id
+
+struct hisi_mn_hwcfg {
+   u32 module_id;
+};
+
+struct hisi_mn_data {
+   struct hisi_djtag_client *client;
+   DECLARE_BITMAP(event_used_mask, HISI_MAX_CFG_MN_CNTR);
+   struct hisi_mn_hwcfg mn_hwcfg;
+};
+
+static inline int hisi_mn_counter_valid(int idx)
+{
+   return (idx >= HISI_IDX_MN_COUNTER0 &&
+   idx < HISI_IDX_MN_COUNTER_MAX);
+}
+
+/* Select the counter register offset from the index */
+static inline u32 get_counter_reg_off(int cntr_idx)
+{
+   return (MN1_CNT0_REG_OFF + (cntr_idx * 4));
+}
+
+static u32 hisi_mn_read_counter(struct hisi_mn_data *mn_data, int cntr_idx)
+{
+   struct hisi_djtag_client *client = mn_data->client;
+   u32 module_id = GET_MODULE_ID(mn_data);
+   u32 reg_off, value;
+
+   reg_off = get_counter_reg_off(cntr_idx);
+   hisi_djtag_readreg(module_id, MN1_BANK_SELECT, reg_off,
+  client, );
+
+   return value;
+}
+
+static u64 hisi_mn_event_update(struct perf_event *event,
+   struct hw_perf_event *hwc, int idx)
+{
+   struct hisi_pmu *mn_pmu = to_hisi_pmu(event->pmu);
+   struct hisi_mn_data *mn_data = mn_pmu->hwmod_data;
+   u64 delta, prev_raw_count, new_raw_count = 0;
+
+   if (!hisi_mn_counter_valid(idx)) {
+   dev_err(mn_pmu->dev,
+   "Unsupported event index:%d!\n", idx);
+   return 0;
+   }
+
+   do {
+   /* Get count from the MN */
+   prev_raw_count = local64_read(>prev_count);
+   new_raw_count = hisi_mn_read_counter(mn_data, idx);
+   delta = (new_raw_count - prev_raw_count) & HISI_MAX_PERIOD;
+
+   local64_add(delta, >count);
+   } while (local64_cmpxchg(>prev_count, prev_raw_count,
+new_raw_count) != prev_raw_count);
+
+   return new_raw_count;
+}
+
+static void hisi_mn_set_evtype(struct hisi_pmu *mn_pmu, int idx, u32 val)
+{
+   struct hisi_mn_data *mn_data = mn_pmu->hwmod_data;
+   struct 

[PATCH v6 11/11] dts: arm64: hip07: Add Hisilicon SoC PMU support

2017-03-09 Thread Anurup M
Add nodes for djtag, L3 cache and MN to support uncore events.

Signed-off-by: Anurup M 
---
 arch/arm64/boot/dts/hisilicon/hip07.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 5144eb1..3155ee3 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1056,4 +1056,83 @@
status = "disabled";
};
};
+
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   /* L3 cache bank 0 for socket0 CPU die scl#3 */
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   /* L3 cache bank 1 for socket0 CPU die scl#3 */
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   /* L3 cache bank 2 for socket0 CPU die scl#3 */
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   /* L3 cache bank 3 for socket0 CPU die scl#3 */
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   /*
+* Miscellaneous node for socket0
+* CPU die scl#2
+*/
+   pmumn0 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
+   };
+
+   djtag1: djtag@4001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x4001 0x0 0x1>;
+   hisilicon,scl-id = <0x01>;
+
+   /* L3 cache bank 0 for socket0 CPU die scl#1 */
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   /* L3 cache bank 1 for socket0 CPU die scl#1 */
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   /* L3 cache bank 2 for socket0 CPU die scl#1 */
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   /* L3 cache bank 3 for socket0 CPU die scl#1 */
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   /*
+* Miscellaneous node for socket0
+* CPU die scl#1
+*/
+   pmumn1 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
+   };
+
 };
-- 
2.1.4



[PATCH v6 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

2017-03-09 Thread Anurup M
Add hrtimer support which use poll method to avoid counter overflow
when overflow IRQ is not supported in hardware.
The L3 cache PMU use N-N SPI interrupt which has no support in kernel
mainline. So use hrtimer to poll and update event counter to avoid
overflow condition for L3 cache PMU.
An interval of 10 seconds is used for the hrtimer.

Signed-off-by: Dikshit N 
Signed-off-by: Anurup M 
---
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 47 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 82 
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 17 +++
 3 files changed, 146 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
index 7f80d07..f23fbc2 100644
--- a/drivers/perf/hisilicon/hisi_uncore_l3c.c
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -53,6 +55,22 @@ enum armv8_hisi_l3c_counters {
 #define L3C_CNT0_REG_OFF 0x170
 #define L3C_EVENT_EN 0x100
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz, Therefore Access time = 0.4ns
+ * L1 cache - 2 way set associative
+ * L2  - 16 way set associative
+ * L3  - 16 way set associative. L3 cache has 4 banks.
+ *
+ * Overflow time = 2^31 * (access time L1 + access time L2 + access time L3)
+ * = 2^31 * ((2 * 0.4ns) + (16 * 0.4ns) + (4 * 16 * 0.4ns)) = 70 seconds
+ *
+ * L3 cache is also used by devices like PCIe, SAS etc. at
+ * the same time. So the overflow time could be even smaller.
+ * So on a safe side we use a timer interval of 10sec
+ */
+#define L3C_HRTIMER_INTERVAL (10LL * MSEC_PER_SEC)
+
 #define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
 #define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
 
@@ -474,11 +492,24 @@ static const struct attribute_group 
hisi_l3c_cpumask_attr_group = {
.attrs = hisi_l3c_cpumask_attrs,
 };
 
+static DEVICE_ATTR(hrtimer_interval, 0444, hisi_hrtimer_interval_sysfs_show,
+  NULL);
+
+static struct attribute *hisi_l3c_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_l3c_hrtimer_interval_attr_group = {
+   .attrs = hisi_l3c_hrtimer_interval_attrs,
+};
+
 static const struct attribute_group *hisi_l3c_pmu_attr_groups[] = {
_l3c_attr_group,
_l3c_format_group,
_l3c_events_group,
_l3c_cpumask_attr_group,
+   _l3c_hrtimer_interval_attr_group,
NULL,
 };
 
@@ -494,6 +525,15 @@ static struct hisi_uncore_ops hisi_uncore_l3c_ops = {
.write_counter = hisi_l3c_write_counter,
 };
 
+/* Initialize hrtimer to poll for avoiding counter overflow */
+static void hisi_l3c_hrtimer_init(struct hisi_pmu *l3c_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   l3c_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   l3c_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(l3c_pmu, L3C_HRTIMER_INTERVAL);
+}
+
 static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 struct hisi_djtag_client *client)
 {
@@ -503,6 +543,7 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
 
l3c_pmu->num_events = HISI_HWEVENT_L3C_EVENT_MAX;
l3c_pmu->num_counters = HISI_IDX_L3C_COUNTER_MAX;
+   l3c_pmu->num_active = 0;
l3c_pmu->scl_id = hisi_djtag_get_sclid(client);
 
l3c_pmu->name = kasprintf(GFP_KERNEL, "hisi_l3c%u_%u",
@@ -513,6 +554,12 @@ static int hisi_l3c_pmu_init(struct hisi_pmu *l3c_pmu,
/* Pick one core to use for cpumask attributes */
cpumask_set_cpu(smp_processor_id(), _pmu->cpu);
 
+   /*
+* Use poll method to avoid counter overflow as overflow IRQ
+* is not supported in v1,v2 hardware.
+*/
+   hisi_l3c_hrtimer_init(l3c_pmu);
+
return 0;
 }
 
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c 
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
index 0e7b5f1..787602b 100644
--- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -65,6 +65,70 @@ ssize_t hisi_cpumask_sysfs_show(struct device *dev,
return cpumap_print_to_pagebuf(true, buf, _pmu->cpu);
 }
 
+/*
+ * sysfs hrtimer_interval attributes
+ */
+ssize_t hisi_hrtimer_interval_sysfs_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct pmu *pmu = dev_get_drvdata(dev);
+   struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
+
+   if (hisi_pmu->hrt_duration)
+   return sprintf(buf, "%llu\n", hisi_pmu->hrt_duration);
+   return 0;
+}
+
+/* The counter overflow IRQ is not supported for some PMUs
+ * use hrtimer to periodically poll and avoid overflow
+ */
+static enum hrtimer_restart 

[PATCH v6 07/11] drivers: perf: hisi: Add support for Hisilicon SoC event counters

2017-03-09 Thread Anurup M
1. HiP05/06/07 uncore PMU to support different hardware event counters.
2. Hisilicon PMU shall use the DJTAG hardware interface to access
   hardware event counters and configuration register.
3. Routines to enable/disable/add/del/start/stop hardware event counting.
4. Add support to count L3 cache hardware events. Each L3 cache banks will
   be registered as separate PMU with perf.
5. L3C events will be listed at /sys/devices/hisi_l3cX_Y/events/

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: John Garry 
---
 drivers/perf/hisilicon/Makefile  |   2 +-
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 606 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 363 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 120 ++
 4 files changed, 1090 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index be8f093..0887b56 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += djtag.o
+obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
new file mode 100644
index 000..7f80d07
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -0,0 +1,606 @@
+/*
+ * HiSilicon SoC L3C Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M 
+ *
+ * This code is based on the uncore PMU's like arm-cci and
+ * arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/*
+ * ARMv8 HiSilicon L3C event types.
+ */
+enum armv8_hisi_l3c_event_types {
+   HISI_HWEVENT_L3C_READ_ALLOCATE  = 0x0,
+   HISI_HWEVENT_L3C_WRITE_ALLOCATE = 0x01,
+   HISI_HWEVENT_L3C_READ_NOALLOCATE= 0x02,
+   HISI_HWEVENT_L3C_WRITE_NOALLOCATE   = 0x03,
+   HISI_HWEVENT_L3C_READ_HIT   = 0x04,
+   HISI_HWEVENT_L3C_WRITE_HIT  = 0x05,
+   HISI_HWEVENT_L3C_EVENT_MAX  = 0x15,
+};
+
+/*
+ * ARMv8 HiSilicon Hardware counter Index.
+ */
+enum armv8_hisi_l3c_counters {
+   HISI_IDX_L3C_COUNTER0   = 0x0,
+   HISI_IDX_L3C_COUNTER_MAX= 0x8,
+};
+
+#define HISI_MAX_CFG_L3C_CNTR  0x08
+#define L3C_EVTYPE_REG_OFF 0x140
+#define L3C_EVCTRL_REG_OFF 0x04
+#define L3C_CNT0_REG_OFF 0x170
+#define L3C_EVENT_EN 0x100
+
+#define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
+#define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
+
+struct hisi_l3c_hwcfg {
+   u32 module_id;
+   u32 bank_select;
+   u32 bank_id;
+};
+
+struct hisi_l3c_data {
+   struct hisi_djtag_client *client;
+   DECLARE_BITMAP(event_used_mask, HISI_MAX_CFG_L3C_CNTR);
+   struct hisi_l3c_hwcfg l3c_hwcfg;
+};
+
+struct hisi_l3c_hw_diff {
+   u32 (*get_bank_id)(u32 module_id, u32 bank_select);
+};
+
+/* hip05/06 chips L3C bank identifier */
+static u32 l3c_bankid_map_v1[MAX_BANKS] = {
+   0x02, 0x04, 0x01, 0x08,
+};
+
+/* hip07 chip L3C bank identifier */
+static u32 l3c_bankid_map_v2[MAX_BANKS] = {
+   0x01, 0x02, 0x03, 0x04,
+};
+
+/* Return the L3C bank index to use in PMU name */
+static u32 get_l3c_bank_v1(u32 module_id, u32 bank_select)
+{
+   u32 i;
+
+   /*
+* For v1 chip (hip05/06) the index of bank_select
+* in the bankid_map gives the bank index.
+*/
+   for (i = 0 ; i < MAX_BANKS; i++)
+   if (l3c_bankid_map_v1[i] == bank_select)
+   break;
+
+   return i;
+}
+
+/* Return the L3C bank index to use in PMU name */
+static u32 get_l3c_bank_v2(u32 module_id, u32 bank_select)
+{
+   u32 i;
+
+   /*
+* For v2 chip (hip07) each bank has different
+* module ID. So index of module ID in the
+* bankid_map gives the bank index.
+*/
+   for (i = 0 ; i < MAX_BANKS; i++)
+   if (l3c_bankid_map_v2[i] == module_id)
+   break;
+
+   return i;
+}
+

[PATCH v6 10/11] drivers: perf: hisi: use poll method when no IRQ for MN counter overflow

2017-03-09 Thread Anurup M
When no IRQ is supported in hardware, use hrtimer to poll and
update event counter and avoid overflow condition for MN PMU.
An interval of 8 seconds is used for the hrtimer.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: Dikshit N 
---
 drivers/perf/hisilicon/hisi_uncore_mn.c | 39 +
 1 file changed, 39 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_mn.c 
b/drivers/perf/hisilicon/hisi_uncore_mn.c
index 18316dc..55b6165 100644
--- a/drivers/perf/hisilicon/hisi_uncore_mn.c
+++ b/drivers/perf/hisilicon/hisi_uncore_mn.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +58,15 @@ enum armv8_hisi_mn_counters {
 
 #define GET_MODULE_ID(hwmod_data) hwmod_data->mn_hwcfg.module_id
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz and number of CPU cores in a SCCL is 16.
+ * For a single MN event on a CPU core consumes 200 cycles.
+ * So overflow time = (2^31 * 200) / (16 * 2.4G) which is about 21 seconds
+ * So on a safe side we use a timer interval of 8sec
+ */
+#define MN1_HRTIMER_INTERVAL (8LL * MSEC_PER_SEC)
+
 struct hisi_mn_hwcfg {
u32 module_id;
 };
@@ -272,6 +283,15 @@ static const struct of_device_id mn_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mn_of_match);
 
+/* Use hrtimer when no IRQ, to poll for avoiding counter overflow */
+static void hisi_mn_hrtimer_init(struct hisi_pmu *mn_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   mn_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   mn_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(mn_pmu, MN1_HRTIMER_INTERVAL);
+}
+
 static int hisi_mn_init_data(struct hisi_pmu *mn_pmu,
 struct hisi_djtag_client *client)
 {
@@ -314,6 +334,12 @@ static int hisi_mn_init_data(struct hisi_pmu *mn_pmu,
} else
return -EINVAL;
 
+   /*
+* Use poll method to avoid counter overflow as
+* overflow IRQ is not supported in hardware.
+*/
+   hisi_mn_hrtimer_init(mn_pmu);
+
return 0;
 }
 
@@ -361,11 +387,24 @@ static const struct attribute_group 
hisi_mn_cpumask_attr_group = {
.attrs = hisi_mn_cpumask_attrs,
 };
 
+static DEVICE_ATTR(hrtimer_interval, 0444, hisi_hrtimer_interval_sysfs_show,
+  NULL);
+
+static struct attribute *hisi_mn_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_mn_hrtimer_interval_attr_group = {
+   .attrs = hisi_mn_hrtimer_interval_attrs,
+};
+
 static const struct attribute_group *hisi_mn_pmu_attr_groups[] = {
_mn_attr_group,
_mn_format_group,
_mn_events_group,
_mn_cpumask_attr_group,
+   _mn_hrtimer_interval_attr_group,
NULL,
 };
 
-- 
2.1.4



[PATCH v6 06/11] drivers: perf: hisi: Add support for Hisilicon Djtag driver

2017-03-09 Thread Anurup M
From: Tan Xiaojun 

The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
can be configured to access the registers of connecting components
(like L3 cache) during real time debugging.

Signed-off-by: Tan Xiaojun 
Signed-off-by: John Garry 
Signed-off-by: Anurup M 
---
 drivers/perf/Makefile   |   1 +
 drivers/perf/hisilicon/Makefile |   1 +
 drivers/perf/hisilicon/djtag.c  | 773 
 drivers/perf/hisilicon/djtag.h  |  42 +++
 4 files changed, 817 insertions(+)
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/djtag.c
 create mode 100644 drivers/perf/hisilicon/djtag.h

diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 3a5e22f..d262fff 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM_PMU) += arm_pmu.o
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
new file mode 100644
index 000..be8f093
--- /dev/null
+++ b/drivers/perf/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HISI_PMU) += djtag.o
diff --git a/drivers/perf/hisilicon/djtag.c b/drivers/perf/hisilicon/djtag.c
new file mode 100644
index 000..88b6a90
--- /dev/null
+++ b/drivers/perf/hisilicon/djtag.c
@@ -0,0 +1,773 @@
+/*
+ * Driver for Hisilicon Djtag r/w which use CPU sysctrl.
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Tan Xiaojun 
+ * Anurup M 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "djtag.h"
+
+#define SC_DJTAG_TIMEOUT_US(100 * USEC_PER_MSEC) /* 100ms */
+
+/* for djtag v1 */
+#define SC_DJTAG_MSTR_EN   0x6800
+#define DJTAG_NOR_CFG  BIT(1)  /* accelerate R,W */
+#define DJTAG_MSTR_EN  BIT(0)
+#define SC_DJTAG_MSTR_START_EN 0x6804
+#define DJTAG_MSTR_START_EN0x1
+#define SC_DJTAG_DEBUG_MODULE_SEL  0x680c
+#define SC_DJTAG_MSTR_WR   0x6810
+#define DJTAG_MSTR_W   0x1
+#define DJTAG_MSTR_R   0x0
+#define SC_DJTAG_CHAIN_UNIT_CFG_EN 0x6814
+#define CHAIN_UNIT_CFG_EN  0x
+#define SC_DJTAG_MSTR_ADDR 0x6818
+#define SC_DJTAG_MSTR_DATA 0x681c
+#define SC_DJTAG_RD_DATA_BASE  0xe800
+
+/* for djtag v2 */
+#define SC_DJTAG_SEC_ACC_EN_EX 0xd800
+#define DJTAG_SEC_ACC_EN_EX0x1
+#define SC_DJTAG_MSTR_CFG_EX   0xd818
+#define DJTAG_MSTR_RW_SHIFT_EX 29
+#define DJTAG_MSTR_RD_EX   (0x0 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DJTAG_MSTR_WR_EX   (0x1 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DEBUG_MODULE_SEL_SHIFT_EX  16
+#define CHAIN_UNIT_CFG_EN_EX   0x
+#define SC_DJTAG_MSTR_ADDR_EX  0xd810
+#define SC_DJTAG_MSTR_DATA_EX  0xd814
+#define SC_DJTAG_MSTR_START_EN_EX  0xd81c
+#define DJTAG_MSTR_START_EN_EX 0x1
+#define SC_DJTAG_RD_DATA_BASE_EX   0xe800
+#define SC_DJTAG_OP_ST_EX  0xe828
+#define DJTAG_OP_DONE_EX   BIT(8)
+
+#define DJTAG_PREFIX "hisi-djtag-dev-"
+
+static DEFINE_IDR(djtag_hosts_idr);
+static DEFINE_IDR(djtag_clients_idr);
+
+struct hisi_djtag_ops {
+   int (*djtag_read)(void __iomem *regs_base, u32 offset,
+ u32 mod_sel, u32 mod_mask, int chain_id, u32 *rval);
+   int (*djtag_write)(void __iomem *regs_base, u32 offset,
+  u32 mod_sel, u32 mod_mask, u32 wval, int chain_id);
+};
+
+struct hisi_djtag_host {
+   spinlock_t lock;
+   int id;
+   u32 scl_id;
+   struct device dev;
+   struct list_head client_list;
+   void __iomem *sysctl_reg_map;
+   struct device_node *of_node;
+   const struct hisi_djtag_ops *djtag_ops;
+};
+
+#define to_hisi_djtag_client(d) container_of(d, struct hisi_djtag_client, dev)
+#define to_hisi_djtag_driver(d) container_of(d, struct hisi_djtag_driver, \
+driver)
+#define MODULE_PREFIX "hisi_djtag:"
+
+static void djtag_prepare_v1(void __iomem *regs_base, u32 offset,
+u32 mod_sel, u32 mod_mask)
+{
+   /* djtag master enable & accelerate R,W */
+   writel(DJTAG_NOR_CFG | DJTAG_MSTR_EN, regs_base + SC_DJTAG_MSTR_EN);
+
+   /* select module */
+   writel(mod_sel, regs_base + 

[PATCH v6 10/11] drivers: perf: hisi: use poll method when no IRQ for MN counter overflow

2017-03-09 Thread Anurup M
When no IRQ is supported in hardware, use hrtimer to poll and
update event counter and avoid overflow condition for MN PMU.
An interval of 8 seconds is used for the hrtimer.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: Dikshit N 
---
 drivers/perf/hisilicon/hisi_uncore_mn.c | 39 +
 1 file changed, 39 insertions(+)

diff --git a/drivers/perf/hisilicon/hisi_uncore_mn.c 
b/drivers/perf/hisilicon/hisi_uncore_mn.c
index 18316dc..55b6165 100644
--- a/drivers/perf/hisilicon/hisi_uncore_mn.c
+++ b/drivers/perf/hisilicon/hisi_uncore_mn.c
@@ -20,6 +20,8 @@
  * along with this program.  If not, see .
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +58,15 @@ enum armv8_hisi_mn_counters {
 
 #define GET_MODULE_ID(hwmod_data) hwmod_data->mn_hwcfg.module_id
 
+/*
+ * Default timer frequency to poll and avoid counter overflow.
+ * CPU speed = 2.4Ghz and number of CPU cores in a SCCL is 16.
+ * For a single MN event on a CPU core consumes 200 cycles.
+ * So overflow time = (2^31 * 200) / (16 * 2.4G) which is about 21 seconds
+ * So on a safe side we use a timer interval of 8sec
+ */
+#define MN1_HRTIMER_INTERVAL (8LL * MSEC_PER_SEC)
+
 struct hisi_mn_hwcfg {
u32 module_id;
 };
@@ -272,6 +283,15 @@ static const struct of_device_id mn_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mn_of_match);
 
+/* Use hrtimer when no IRQ, to poll for avoiding counter overflow */
+static void hisi_mn_hrtimer_init(struct hisi_pmu *mn_pmu)
+{
+   INIT_LIST_HEAD(_pmu->active_list);
+   mn_pmu->ops->start_hrtimer = hisi_hrtimer_start;
+   mn_pmu->ops->stop_hrtimer = hisi_hrtimer_stop;
+   hisi_hrtimer_init(mn_pmu, MN1_HRTIMER_INTERVAL);
+}
+
 static int hisi_mn_init_data(struct hisi_pmu *mn_pmu,
 struct hisi_djtag_client *client)
 {
@@ -314,6 +334,12 @@ static int hisi_mn_init_data(struct hisi_pmu *mn_pmu,
} else
return -EINVAL;
 
+   /*
+* Use poll method to avoid counter overflow as
+* overflow IRQ is not supported in hardware.
+*/
+   hisi_mn_hrtimer_init(mn_pmu);
+
return 0;
 }
 
@@ -361,11 +387,24 @@ static const struct attribute_group 
hisi_mn_cpumask_attr_group = {
.attrs = hisi_mn_cpumask_attrs,
 };
 
+static DEVICE_ATTR(hrtimer_interval, 0444, hisi_hrtimer_interval_sysfs_show,
+  NULL);
+
+static struct attribute *hisi_mn_hrtimer_interval_attrs[] = {
+   _attr_hrtimer_interval.attr,
+   NULL,
+};
+
+static const struct attribute_group hisi_mn_hrtimer_interval_attr_group = {
+   .attrs = hisi_mn_hrtimer_interval_attrs,
+};
+
 static const struct attribute_group *hisi_mn_pmu_attr_groups[] = {
_mn_attr_group,
_mn_format_group,
_mn_events_group,
_mn_cpumask_attr_group,
+   _mn_hrtimer_interval_attr_group,
NULL,
 };
 
-- 
2.1.4



[PATCH v6 06/11] drivers: perf: hisi: Add support for Hisilicon Djtag driver

2017-03-09 Thread Anurup M
From: Tan Xiaojun 

The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
can be configured to access the registers of connecting components
(like L3 cache) during real time debugging.

Signed-off-by: Tan Xiaojun 
Signed-off-by: John Garry 
Signed-off-by: Anurup M 
---
 drivers/perf/Makefile   |   1 +
 drivers/perf/hisilicon/Makefile |   1 +
 drivers/perf/hisilicon/djtag.c  | 773 
 drivers/perf/hisilicon/djtag.h  |  42 +++
 4 files changed, 817 insertions(+)
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/djtag.c
 create mode 100644 drivers/perf/hisilicon/djtag.h

diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 3a5e22f..d262fff 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM_PMU) += arm_pmu.o
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
new file mode 100644
index 000..be8f093
--- /dev/null
+++ b/drivers/perf/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HISI_PMU) += djtag.o
diff --git a/drivers/perf/hisilicon/djtag.c b/drivers/perf/hisilicon/djtag.c
new file mode 100644
index 000..88b6a90
--- /dev/null
+++ b/drivers/perf/hisilicon/djtag.c
@@ -0,0 +1,773 @@
+/*
+ * Driver for Hisilicon Djtag r/w which use CPU sysctrl.
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Tan Xiaojun 
+ * Anurup M 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "djtag.h"
+
+#define SC_DJTAG_TIMEOUT_US(100 * USEC_PER_MSEC) /* 100ms */
+
+/* for djtag v1 */
+#define SC_DJTAG_MSTR_EN   0x6800
+#define DJTAG_NOR_CFG  BIT(1)  /* accelerate R,W */
+#define DJTAG_MSTR_EN  BIT(0)
+#define SC_DJTAG_MSTR_START_EN 0x6804
+#define DJTAG_MSTR_START_EN0x1
+#define SC_DJTAG_DEBUG_MODULE_SEL  0x680c
+#define SC_DJTAG_MSTR_WR   0x6810
+#define DJTAG_MSTR_W   0x1
+#define DJTAG_MSTR_R   0x0
+#define SC_DJTAG_CHAIN_UNIT_CFG_EN 0x6814
+#define CHAIN_UNIT_CFG_EN  0x
+#define SC_DJTAG_MSTR_ADDR 0x6818
+#define SC_DJTAG_MSTR_DATA 0x681c
+#define SC_DJTAG_RD_DATA_BASE  0xe800
+
+/* for djtag v2 */
+#define SC_DJTAG_SEC_ACC_EN_EX 0xd800
+#define DJTAG_SEC_ACC_EN_EX0x1
+#define SC_DJTAG_MSTR_CFG_EX   0xd818
+#define DJTAG_MSTR_RW_SHIFT_EX 29
+#define DJTAG_MSTR_RD_EX   (0x0 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DJTAG_MSTR_WR_EX   (0x1 << DJTAG_MSTR_RW_SHIFT_EX)
+#define DEBUG_MODULE_SEL_SHIFT_EX  16
+#define CHAIN_UNIT_CFG_EN_EX   0x
+#define SC_DJTAG_MSTR_ADDR_EX  0xd810
+#define SC_DJTAG_MSTR_DATA_EX  0xd814
+#define SC_DJTAG_MSTR_START_EN_EX  0xd81c
+#define DJTAG_MSTR_START_EN_EX 0x1
+#define SC_DJTAG_RD_DATA_BASE_EX   0xe800
+#define SC_DJTAG_OP_ST_EX  0xe828
+#define DJTAG_OP_DONE_EX   BIT(8)
+
+#define DJTAG_PREFIX "hisi-djtag-dev-"
+
+static DEFINE_IDR(djtag_hosts_idr);
+static DEFINE_IDR(djtag_clients_idr);
+
+struct hisi_djtag_ops {
+   int (*djtag_read)(void __iomem *regs_base, u32 offset,
+ u32 mod_sel, u32 mod_mask, int chain_id, u32 *rval);
+   int (*djtag_write)(void __iomem *regs_base, u32 offset,
+  u32 mod_sel, u32 mod_mask, u32 wval, int chain_id);
+};
+
+struct hisi_djtag_host {
+   spinlock_t lock;
+   int id;
+   u32 scl_id;
+   struct device dev;
+   struct list_head client_list;
+   void __iomem *sysctl_reg_map;
+   struct device_node *of_node;
+   const struct hisi_djtag_ops *djtag_ops;
+};
+
+#define to_hisi_djtag_client(d) container_of(d, struct hisi_djtag_client, dev)
+#define to_hisi_djtag_driver(d) container_of(d, struct hisi_djtag_driver, \
+driver)
+#define MODULE_PREFIX "hisi_djtag:"
+
+static void djtag_prepare_v1(void __iomem *regs_base, u32 offset,
+u32 mod_sel, u32 mod_mask)
+{
+   /* djtag master enable & accelerate R,W */
+   writel(DJTAG_NOR_CFG | DJTAG_MSTR_EN, regs_base + SC_DJTAG_MSTR_EN);
+
+   /* select module */
+   writel(mod_sel, regs_base + SC_DJTAG_DEBUG_MODULE_SEL);
+   writel(mod_mask & CHAIN_UNIT_CFG_EN,
+   regs_base + SC_DJTAG_CHAIN_UNIT_CFG_EN);
+
+   /* 

[PATCH v6 07/11] drivers: perf: hisi: Add support for Hisilicon SoC event counters

2017-03-09 Thread Anurup M
1. HiP05/06/07 uncore PMU to support different hardware event counters.
2. Hisilicon PMU shall use the DJTAG hardware interface to access
   hardware event counters and configuration register.
3. Routines to enable/disable/add/del/start/stop hardware event counting.
4. Add support to count L3 cache hardware events. Each L3 cache banks will
   be registered as separate PMU with perf.
5. L3C events will be listed at /sys/devices/hisi_l3cX_Y/events/

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: John Garry 
---
 drivers/perf/hisilicon/Makefile  |   2 +-
 drivers/perf/hisilicon/hisi_uncore_l3c.c | 606 +++
 drivers/perf/hisilicon/hisi_uncore_pmu.c | 363 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.h | 120 ++
 4 files changed, 1090 insertions(+), 1 deletion(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index be8f093..0887b56 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += djtag.o
+obj-$(CONFIG_HISI_PMU) += djtag.o hisi_uncore_pmu.o hisi_uncore_l3c.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c.c 
b/drivers/perf/hisilicon/hisi_uncore_l3c.c
new file mode 100644
index 000..7f80d07
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c.c
@@ -0,0 +1,606 @@
+/*
+ * HiSilicon SoC L3C Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M 
+ *
+ * This code is based on the uncore PMU's like arm-cci and
+ * arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hisi_uncore_pmu.h"
+
+/*
+ * ARMv8 HiSilicon L3C event types.
+ */
+enum armv8_hisi_l3c_event_types {
+   HISI_HWEVENT_L3C_READ_ALLOCATE  = 0x0,
+   HISI_HWEVENT_L3C_WRITE_ALLOCATE = 0x01,
+   HISI_HWEVENT_L3C_READ_NOALLOCATE= 0x02,
+   HISI_HWEVENT_L3C_WRITE_NOALLOCATE   = 0x03,
+   HISI_HWEVENT_L3C_READ_HIT   = 0x04,
+   HISI_HWEVENT_L3C_WRITE_HIT  = 0x05,
+   HISI_HWEVENT_L3C_EVENT_MAX  = 0x15,
+};
+
+/*
+ * ARMv8 HiSilicon Hardware counter Index.
+ */
+enum armv8_hisi_l3c_counters {
+   HISI_IDX_L3C_COUNTER0   = 0x0,
+   HISI_IDX_L3C_COUNTER_MAX= 0x8,
+};
+
+#define HISI_MAX_CFG_L3C_CNTR  0x08
+#define L3C_EVTYPE_REG_OFF 0x140
+#define L3C_EVCTRL_REG_OFF 0x04
+#define L3C_CNT0_REG_OFF 0x170
+#define L3C_EVENT_EN 0x100
+
+#define GET_MODULE_ID(hwmod_data) hwmod_data->l3c_hwcfg.module_id
+#define GET_BANK_SEL(hwmod_data) hwmod_data->l3c_hwcfg.bank_select
+
+struct hisi_l3c_hwcfg {
+   u32 module_id;
+   u32 bank_select;
+   u32 bank_id;
+};
+
+struct hisi_l3c_data {
+   struct hisi_djtag_client *client;
+   DECLARE_BITMAP(event_used_mask, HISI_MAX_CFG_L3C_CNTR);
+   struct hisi_l3c_hwcfg l3c_hwcfg;
+};
+
+struct hisi_l3c_hw_diff {
+   u32 (*get_bank_id)(u32 module_id, u32 bank_select);
+};
+
+/* hip05/06 chips L3C bank identifier */
+static u32 l3c_bankid_map_v1[MAX_BANKS] = {
+   0x02, 0x04, 0x01, 0x08,
+};
+
+/* hip07 chip L3C bank identifier */
+static u32 l3c_bankid_map_v2[MAX_BANKS] = {
+   0x01, 0x02, 0x03, 0x04,
+};
+
+/* Return the L3C bank index to use in PMU name */
+static u32 get_l3c_bank_v1(u32 module_id, u32 bank_select)
+{
+   u32 i;
+
+   /*
+* For v1 chip (hip05/06) the index of bank_select
+* in the bankid_map gives the bank index.
+*/
+   for (i = 0 ; i < MAX_BANKS; i++)
+   if (l3c_bankid_map_v1[i] == bank_select)
+   break;
+
+   return i;
+}
+
+/* Return the L3C bank index to use in PMU name */
+static u32 get_l3c_bank_v2(u32 module_id, u32 bank_select)
+{
+   u32 i;
+
+   /*
+* For v2 chip (hip07) each bank has different
+* module ID. So index of module ID in the
+* bankid_map gives the bank index.
+*/
+   for (i = 0 ; i < MAX_BANKS; i++)
+   if (l3c_bankid_map_v2[i] == module_id)
+   break;
+
+   return i;
+}
+
+static inline int hisi_l3c_counter_valid(int idx)
+{
+   return (idx >= 

[PATCH v6 05/11] drivers: perf: hisi: Update Kconfig for Hisilicon PMU support

2017-03-09 Thread Anurup M
Update Kconfig for HiP05/06/07 PMU support.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: John Garry 
---
 drivers/perf/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 1e95d6a..f0aa818 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -32,4 +32,12 @@ config ARM_PMU_ACPI
def_bool y
depends on ARM_PMU && ACPI
 
+config HISI_PMU
+   bool "HiSilicon SoC PMU"
+   depends on PERF_EVENTS && ARM64
+   help
+ Enable hardware event counter support for hardware event counters
+ in Hisilicon HiP05/06/07 SoC. The hardware modules like L3C and MN
+ have hardware events and counters.
+
 endmenu
-- 
2.1.4



[PATCH v6 05/11] drivers: perf: hisi: Update Kconfig for Hisilicon PMU support

2017-03-09 Thread Anurup M
Update Kconfig for HiP05/06/07 PMU support.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Signed-off-by: John Garry 
---
 drivers/perf/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 1e95d6a..f0aa818 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -32,4 +32,12 @@ config ARM_PMU_ACPI
def_bool y
depends on ARM_PMU && ACPI
 
+config HISI_PMU
+   bool "HiSilicon SoC PMU"
+   depends on PERF_EVENTS && ARM64
+   help
+ Enable hardware event counter support for hardware event counters
+ in Hisilicon HiP05/06/07 SoC. The hardware modules like L3C and MN
+ have hardware events and counters.
+
 endmenu
-- 
2.1.4



[PATCH v6 04/11] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

2017-03-09 Thread Anurup M
Documentation for perf usage and Hisilicon SoC PMU uncore events.
The Hisilicon SOC has event counters for hardware modules like
L3 cache, Miscellaneous node etc. These events are all uncore.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
---
 Documentation/perf/hisi-pmu.txt | 76 +
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt

diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..e3ac562
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,76 @@
+Hisilicon SoC PMU (Performance Monitoring Unit)
+
+The Hisilicon SoC HiP05/06/07 chips consist of various independent system
+device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
+These PMU devices are independent and have hardware logic to gather
+statistics and performance information.
+
+HiP0x chips are encapsulated by multiple CPU and IO die's. The CPU die is
+called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
+Each SCCL has 1 L3 cache and 1 MN units.
+
+The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
+(or instances). Each bank or instance of L3C has Eight 32-bit counter
+registers and also event control registers. The HiP05/06 chip L3 cache has
+22 statistics events. The HiP07 chip has 66 statistics events. These events
+are very useful for debugging.
+
+The MN module is also shared by all CPU cores in a CPU die. It receives
+barriers and DVM(Distributed Virtual Memory) messages from cpu or smmu, and
+perform the required actions and return response messages. These events are
+very useful for debugging. The MN has total 9 statistics events and support
+four 32-bit counter registers in HiP05/06/07 chips.
+
+There is no memory mapping for L3 cache and MN registers. It can be accessed
+by using the Hisilicon djtag interface. The Djtag in a SCCL is an independent
+module which connects with some modules in the SoC by Debug Bus.
+
+Hisilicon SoC (HiP05/06/07) PMU driver
+--
+The HiP0x PMU driver shall register perf PMU drivers like L3 cache, MN, etc.
+The available events and configuration options shall be described in the sysfs.
+The "perf list" shall list the available events from sysfs.
+
+The L3 cache in a SCCL is divided as 4 banks. Each L3 cache bank have separate
+PMU registers for event counting and control. The L3 cache banks also do not
+have any CPU affinity. So each L3 cache banks are registered with perf as a
+separate PMU.
+The PMU name will appear in event listing as hisi_l3c_.
+where "bank-id" is the bank index (0 to 3) and "scl-id" is the SCCL identifier
+e.g. hisi_l3c0_2/read_hit is READ_HIT event of L3 cache bank #0 SCCL ID #2.
+
+The MN in a SCCL is registered as a separate PMU with perf.
+The PMU name will appear in event listing as hisi_mn_.
+e.g. hisi_mn_2/read_req. READ_REQUEST event of MN of Super CPU cluster #2.
+
+The event code is represented by 12 bits.
+   i) event 0-11
+   The event code will be represented using the LSB 12 bits.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_l3c0_2/read_hit/ [kernel PMU event]
+--
+hisi_l3c1_2/write_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/read_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/write_hit/ [kernel PMU event]
+--
+hisi_mn_2/read_req/ [kernel PMU event]
+hisi_mn_2/write_req/ [kernel PMU event]
+--
+
+$# perf stat -a -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+$# perf stat -A -C 0 -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+The current driver doesnot support sampling. so "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
-- 
2.1.4



[PATCH v6 04/11] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

2017-03-09 Thread Anurup M
Documentation for perf usage and Hisilicon SoC PMU uncore events.
The Hisilicon SOC has event counters for hardware modules like
L3 cache, Miscellaneous node etc. These events are all uncore.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
---
 Documentation/perf/hisi-pmu.txt | 76 +
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt

diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..e3ac562
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,76 @@
+Hisilicon SoC PMU (Performance Monitoring Unit)
+
+The Hisilicon SoC HiP05/06/07 chips consist of various independent system
+device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
+These PMU devices are independent and have hardware logic to gather
+statistics and performance information.
+
+HiP0x chips are encapsulated by multiple CPU and IO die's. The CPU die is
+called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
+Each SCCL has 1 L3 cache and 1 MN units.
+
+The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
+(or instances). Each bank or instance of L3C has Eight 32-bit counter
+registers and also event control registers. The HiP05/06 chip L3 cache has
+22 statistics events. The HiP07 chip has 66 statistics events. These events
+are very useful for debugging.
+
+The MN module is also shared by all CPU cores in a CPU die. It receives
+barriers and DVM(Distributed Virtual Memory) messages from cpu or smmu, and
+perform the required actions and return response messages. These events are
+very useful for debugging. The MN has total 9 statistics events and support
+four 32-bit counter registers in HiP05/06/07 chips.
+
+There is no memory mapping for L3 cache and MN registers. It can be accessed
+by using the Hisilicon djtag interface. The Djtag in a SCCL is an independent
+module which connects with some modules in the SoC by Debug Bus.
+
+Hisilicon SoC (HiP05/06/07) PMU driver
+--
+The HiP0x PMU driver shall register perf PMU drivers like L3 cache, MN, etc.
+The available events and configuration options shall be described in the sysfs.
+The "perf list" shall list the available events from sysfs.
+
+The L3 cache in a SCCL is divided as 4 banks. Each L3 cache bank have separate
+PMU registers for event counting and control. The L3 cache banks also do not
+have any CPU affinity. So each L3 cache banks are registered with perf as a
+separate PMU.
+The PMU name will appear in event listing as hisi_l3c_.
+where "bank-id" is the bank index (0 to 3) and "scl-id" is the SCCL identifier
+e.g. hisi_l3c0_2/read_hit is READ_HIT event of L3 cache bank #0 SCCL ID #2.
+
+The MN in a SCCL is registered as a separate PMU with perf.
+The PMU name will appear in event listing as hisi_mn_.
+e.g. hisi_mn_2/read_req. READ_REQUEST event of MN of Super CPU cluster #2.
+
+The event code is represented by 12 bits.
+   i) event 0-11
+   The event code will be represented using the LSB 12 bits.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_l3c0_2/read_hit/ [kernel PMU event]
+--
+hisi_l3c1_2/write_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/read_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/write_hit/ [kernel PMU event]
+--
+hisi_mn_2/read_req/ [kernel PMU event]
+hisi_mn_2/write_req/ [kernel PMU event]
+--
+
+$# perf stat -a -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+$# perf stat -A -C 0 -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+The current driver doesnot support sampling. so "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
-- 
2.1.4



[PATCH v6 03/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

2017-03-09 Thread Anurup M
1) Device tree bindings for Hisilicon SoC PMU.
2) Add example for Hisilicon L3 cache and MN PMU.
3) Add child nodes of L3C and MN in djtag bindings example.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/djtag.txt| 25 +++
 .../devicetree/bindings/arm/hisilicon/pmu.txt  | 87 ++
 2 files changed, 112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
index fde5bab..5c46a9c 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -27,6 +27,31 @@ Example 1: Djtag for CPU die in HiP07
hisilicon,scl-id = <0x03>;
 
/* All connecting components will appear as child nodes */
+
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   pmumn0 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
};
 
 Hisilicon HiP05/06/07 djtag for IO die
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
new file mode 100644
index 000..ad38cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
@@ -0,0 +1,87 @@
+Hisilicon SoC HiP05/06/07 ARMv8 PMU
+===
+
+The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
+system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
+PMU devices are independent and have hardware logic to gather statistics and
+performance information.
+
+HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
+is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
+4 cpu-cores each.
+e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
+The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
+
+The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
+For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
+the parent node will be the djtag node of the corresponding CPU die (SCCL).
+
+L3 cache
+-
+The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
+L3 cache banks. Each L3 cache bank have separate DT nodes.
+
+Required properties:
+
+   - compatible : This value should be as follows
+   (a) "hisilicon,hip05-pmu-l3c-v1" for v1 hw in HiP05 chipset
+   (b) "hisilicon,hip06-pmu-l3c-v1" for v1 hw in HiP06 chipset
+   (c) "hisilicon,hip07-pmu-l3c-v2" for v2 hw in HiP07 chipset
+
+   - hisilicon,module-id : This property is a combination of two values
+   in the below order.
+   a) Module ID: The module identifier for djtag.
+   b) Instance or Bank ID: This will identify the L3 cache bank
+or instance.
+
+   *The counter overflow IRQ is not supported in v1, v2 hardware 
(HiP05/06/07).
+
+Miscellaneous Node
+--
+The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
+for each SCCL.
+
+Required properties:
+
+   - compatible : This value should be as follows
+   (a) "hisilicon,hip05-pmu-mn-v1" for v1 hw in HiP05 chipset
+   (b) "hisilicon,hip06-pmu-mn-v1" for v1 hw in HiP06 chipset
+   (c) "hisilicon,hip07-pmu-mn-v2" for v2 hw in HiP07 chipset
+
+   - hisilicon,module-id : Module ID to input for djtag.
+
+   *The counter overflow IRQ is not supported in v1, v2 hardware 
(HiP05/06/07).
+
+Example:
+
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+

[PATCH v6 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

2017-03-09 Thread Anurup M
From: Tan Xiaojun 

Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die

Signed-off-by: Tan Xiaojun 
Signed-off-by: Anurup M 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/djtag.txt| 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
new file mode 100644
index 000..fde5bab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -0,0 +1,51 @@
+The Hisilicon Djtag is an independent component which connects with some other
+components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
+in the chip. The djtag controls access to connecting modules of CPU and IO
+dies.
+The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
+are accessed by djtag during real time debugging. In IO die there are 
connecting
+components like RSA. These components appear as devices attached to djtag bus.
+
+Hisilicon HiP05/06/07 djtag for CPU die
+Required properties:
+  - compatible : The value should be as follows
+   (a) "hisilicon,hip05-cpu-djtag-v1" for CPU die which use v1 hw in
+   HiP05 chipset.
+   (b) "hisilicon,hip06-cpu-djtag-v1" for CPU die which use v1 hw in
+   HiP06 chipset.
+   (c) "hisilicon,hip07-cpu-djtag-v2" for CPU die which use v2 hw in
+   HiP07 chipset.
+  - reg : Register address and size
+  - hisilicon,scl-id : The Super Cluster ID for CPU or IO die
+
+Example 1: Djtag for CPU die in HiP07
+
+   /* for Hisilicon HiP07 djtag for CPU Die */
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   /* All connecting components will appear as child nodes */
+   };
+
+Hisilicon HiP05/06/07 djtag for IO die
+Required properties:
+  - compatible : The value should be as follows
+   (a) "hisilicon,hip05-io-djtag-v1" for IO die which use v1 hw in
+   HiP05 chipset.
+   (c) "hisilicon,hip06-io-djtag-v2" for IO die which use v2 hw in
+   HiP06 chipset.
+   (d) "hisilicon,hip07-io-djtag-v2" for IO die which use v2 hw in
+   HiP07 chipset
+
+Example 2: Djtag for IO die in HiP05
+
+   /* for Hisilicon HiP05 djtag for IO Die */
+   djtag1: djtag@d000 {
+   compatible = "hisilicon,hip05-io-djtag-v1";
+   reg = <0x0 0xd000 0x0 0x1>;
+   hisilicon,scl-id = <0x0>;
+
+   /* All connecting components will appear as child nodes */
+   };
-- 
2.1.4



[PATCH v6 03/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

2017-03-09 Thread Anurup M
1) Device tree bindings for Hisilicon SoC PMU.
2) Add example for Hisilicon L3 cache and MN PMU.
3) Add child nodes of L3C and MN in djtag bindings example.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/djtag.txt| 25 +++
 .../devicetree/bindings/arm/hisilicon/pmu.txt  | 87 ++
 2 files changed, 112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
index fde5bab..5c46a9c 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -27,6 +27,31 @@ Example 1: Djtag for CPU die in HiP07
hisilicon,scl-id = <0x03>;
 
/* All connecting components will appear as child nodes */
+
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   pmul3c1 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x02 0x01>;
+   };
+
+   pmul3c2 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x03 0x01>;
+   };
+
+   pmul3c3 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x04 0x01>;
+   };
+
+   pmumn0 {
+   compatible = "hisilicon,hip07-pmu-mn-v2";
+   hisilicon,module-id = <0x21>;
+   };
};
 
 Hisilicon HiP05/06/07 djtag for IO die
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
new file mode 100644
index 000..ad38cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
@@ -0,0 +1,87 @@
+Hisilicon SoC HiP05/06/07 ARMv8 PMU
+===
+
+The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
+system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
+PMU devices are independent and have hardware logic to gather statistics and
+performance information.
+
+HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
+is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
+4 cpu-cores each.
+e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
+The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
+
+The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
+For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
+the parent node will be the djtag node of the corresponding CPU die (SCCL).
+
+L3 cache
+-
+The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
+L3 cache banks. Each L3 cache bank have separate DT nodes.
+
+Required properties:
+
+   - compatible : This value should be as follows
+   (a) "hisilicon,hip05-pmu-l3c-v1" for v1 hw in HiP05 chipset
+   (b) "hisilicon,hip06-pmu-l3c-v1" for v1 hw in HiP06 chipset
+   (c) "hisilicon,hip07-pmu-l3c-v2" for v2 hw in HiP07 chipset
+
+   - hisilicon,module-id : This property is a combination of two values
+   in the below order.
+   a) Module ID: The module identifier for djtag.
+   b) Instance or Bank ID: This will identify the L3 cache bank
+or instance.
+
+   *The counter overflow IRQ is not supported in v1, v2 hardware 
(HiP05/06/07).
+
+Miscellaneous Node
+--
+The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
+for each SCCL.
+
+Required properties:
+
+   - compatible : This value should be as follows
+   (a) "hisilicon,hip05-pmu-mn-v1" for v1 hw in HiP05 chipset
+   (b) "hisilicon,hip06-pmu-mn-v1" for v1 hw in HiP06 chipset
+   (c) "hisilicon,hip07-pmu-mn-v2" for v2 hw in HiP07 chipset
+
+   - hisilicon,module-id : Module ID to input for djtag.
+
+   *The counter overflow IRQ is not supported in v1, v2 hardware 
(HiP05/06/07).
+
+Example:
+
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   pmul3c0 {
+   compatible = "hisilicon,hip07-pmu-l3c-v2";
+   hisilicon,module-id = <0x01 0x01>;
+   };
+
+   pmul3c1 {
+   compatible = 

[PATCH v6 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

2017-03-09 Thread Anurup M
From: Tan Xiaojun 

Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die

Signed-off-by: Tan Xiaojun 
Signed-off-by: Anurup M 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/djtag.txt| 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
new file mode 100644
index 000..fde5bab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -0,0 +1,51 @@
+The Hisilicon Djtag is an independent component which connects with some other
+components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
+in the chip. The djtag controls access to connecting modules of CPU and IO
+dies.
+The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
+are accessed by djtag during real time debugging. In IO die there are 
connecting
+components like RSA. These components appear as devices attached to djtag bus.
+
+Hisilicon HiP05/06/07 djtag for CPU die
+Required properties:
+  - compatible : The value should be as follows
+   (a) "hisilicon,hip05-cpu-djtag-v1" for CPU die which use v1 hw in
+   HiP05 chipset.
+   (b) "hisilicon,hip06-cpu-djtag-v1" for CPU die which use v1 hw in
+   HiP06 chipset.
+   (c) "hisilicon,hip07-cpu-djtag-v2" for CPU die which use v2 hw in
+   HiP07 chipset.
+  - reg : Register address and size
+  - hisilicon,scl-id : The Super Cluster ID for CPU or IO die
+
+Example 1: Djtag for CPU die in HiP07
+
+   /* for Hisilicon HiP07 djtag for CPU Die */
+   djtag0: djtag@6001 {
+   compatible = "hisilicon,hip07-cpu-djtag-v2";
+   reg = <0x0 0x6001 0x0 0x1>;
+   hisilicon,scl-id = <0x03>;
+
+   /* All connecting components will appear as child nodes */
+   };
+
+Hisilicon HiP05/06/07 djtag for IO die
+Required properties:
+  - compatible : The value should be as follows
+   (a) "hisilicon,hip05-io-djtag-v1" for IO die which use v1 hw in
+   HiP05 chipset.
+   (c) "hisilicon,hip06-io-djtag-v2" for IO die which use v2 hw in
+   HiP06 chipset.
+   (d) "hisilicon,hip07-io-djtag-v2" for IO die which use v2 hw in
+   HiP07 chipset
+
+Example 2: Djtag for IO die in HiP05
+
+   /* for Hisilicon HiP05 djtag for IO Die */
+   djtag1: djtag@d000 {
+   compatible = "hisilicon,hip05-io-djtag-v1";
+   reg = <0x0 0xd000 0x0 0x1>;
+   hisilicon,scl-id = <0x0>;
+
+   /* All connecting components will appear as child nodes */
+   };
-- 
2.1.4



[PATCH v6 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support

2017-03-09 Thread Anurup M
Add support for Hisilicon SoC hardware event counters
for HiP05/06/07 chip versions.

Signed-off-by: Anurup M 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d7b7a7..c2f9806 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5958,6 +5958,15 @@ S:   Maintained
 F: drivers/net/ethernet/hisilicon/
 F: Documentation/devicetree/bindings/net/hisilicon*.txt
 
+HISILICON SOC PMU
+M: Anurup M 
+W: http://www.hisilicon.com
+S: Supported
+F: drivers/perf/hisilicon/
+F: Documentation/perf/hisi-pmu.txt
+F: Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
+F: Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
+
 HISILICON ROCE DRIVER
 M: Lijun Ou 
 M: Wei Hu(Xavier) 
-- 
2.1.4



[PATCH v6 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support

2017-03-09 Thread Anurup M
Add support for Hisilicon SoC hardware event counters
for HiP05/06/07 chip versions.

Signed-off-by: Anurup M 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d7b7a7..c2f9806 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5958,6 +5958,15 @@ S:   Maintained
 F: drivers/net/ethernet/hisilicon/
 F: Documentation/devicetree/bindings/net/hisilicon*.txt
 
+HISILICON SOC PMU
+M: Anurup M 
+W: http://www.hisilicon.com
+S: Supported
+F: drivers/perf/hisilicon/
+F: Documentation/perf/hisi-pmu.txt
+F: Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
+F: Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
+
 HISILICON ROCE DRIVER
 M: Lijun Ou 
 M: Wei Hu(Xavier) 
-- 
2.1.4



[PATCH v6 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters

2017-03-09 Thread Anurup M
Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.

This v6 version is rebased to 4.11-rc1.

This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.

Support for Hisilicon L3 cache(L3C) and Miscellaneous nodes(MN) hardware
events and counters are added in this implementation.

The uncore PMU units are registered as separate PMUs. 
e.g. in the case of L3 cache, which consist of 4 banks/instances, each bank
is registered with perf as separate PMU, as each bank have separate control
registers and interrupts. These units are also not CPU affine in the current
chip versions.

The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.

There is no counter overflow IRQ support in hardware for these uncore PMUs.
So the driver use poll method using hrtimer to avoid overflow.

ToDo:
1) ACPI probe and reset support.

Version history
---
v6
--
- Rebase to 4.11-rc1
- Modify Copyright year to 2017.

v5
--
- Use hrtimer to avoid overflow as MN counter overflow IRQ is broken
  in hardware.
- Remove IRQ handling of MN in driver and update pmu dt-bindings.
- Fix reveiw comments in v4 version.

v4
--
- Counter overflow IRQ handling for MN PMU.
- Use hrtimer to avoid counter overflow in L3 Cache PMU.
- Use hisi-cpu- and hisi-io- for djtag compatible field.
- Fix reveiw comments in v3 version.

v3
--
- Fix review comments of v2 version.
- Handle event groups. Do not allow group of mixed PMUs.
- Use hip0x prefix for compatible names.
- Fix all sparse and gcc W=1 warnings.

v2
--
- Fix review comments of v1 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
  and remove chip version as driver only depend on djtag
  hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
  depend on djtag it will be send separately.

v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.

Anurup M (8):
  arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
  dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
  Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event
counting.
  drivers: perf: hisi: Update Kconfig for Hisilicon PMU support
  drivers: perf: hisi: Add support for Hisilicon SoC event counters
  drivers: perf: hisi: use poll method to avoid L3C counter overflow
  drivers: perf: hisi: use poll method when no IRQ for MN counter
overflow
  dts: arm64: hip07: Add Hisilicon SoC PMU support

Shaokun Zhang (1):
  drivers: perf: hisi: Miscellanous node(MN) event counting in perf

Tan Xiaojun (2):
  dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
  drivers: perf: hisi: Add support for Hisilicon Djtag driver

 .../devicetree/bindings/arm/hisilicon/djtag.txt|  76 ++
 .../devicetree/bindings/arm/hisilicon/pmu.txt  |  87 +++
 Documentation/perf/hisi-pmu.txt|  76 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  79 +++
 drivers/perf/Kconfig   |   8 +
 drivers/perf/Makefile  |   1 +
 drivers/perf/hisilicon/Makefile|   1 +
 drivers/perf/hisilicon/djtag.c | 773 +
 drivers/perf/hisilicon/djtag.h |  42 ++
 drivers/perf/hisilicon/hisi_uncore_l3c.c   | 653 +
 drivers/perf/hisilicon/hisi_uncore_mn.c| 528 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.c   | 445 
 drivers/perf/hisilicon/hisi_uncore_pmu.h   | 137 
 14 files changed, 2915 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
 create mode 100644 Documentation/perf/hisi-pmu.txt
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/djtag.c
 create mode 100644 drivers/perf/hisilicon/djtag.h
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

-- 
2.1.4



[PATCH v6 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters

2017-03-09 Thread Anurup M
Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.

This v6 version is rebased to 4.11-rc1.

This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.

Support for Hisilicon L3 cache(L3C) and Miscellaneous nodes(MN) hardware
events and counters are added in this implementation.

The uncore PMU units are registered as separate PMUs. 
e.g. in the case of L3 cache, which consist of 4 banks/instances, each bank
is registered with perf as separate PMU, as each bank have separate control
registers and interrupts. These units are also not CPU affine in the current
chip versions.

The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.

There is no counter overflow IRQ support in hardware for these uncore PMUs.
So the driver use poll method using hrtimer to avoid overflow.

ToDo:
1) ACPI probe and reset support.

Version history
---
v6
--
- Rebase to 4.11-rc1
- Modify Copyright year to 2017.

v5
--
- Use hrtimer to avoid overflow as MN counter overflow IRQ is broken
  in hardware.
- Remove IRQ handling of MN in driver and update pmu dt-bindings.
- Fix reveiw comments in v4 version.

v4
--
- Counter overflow IRQ handling for MN PMU.
- Use hrtimer to avoid counter overflow in L3 Cache PMU.
- Use hisi-cpu- and hisi-io- for djtag compatible field.
- Fix reveiw comments in v3 version.

v3
--
- Fix review comments of v2 version.
- Handle event groups. Do not allow group of mixed PMUs.
- Use hip0x prefix for compatible names.
- Fix all sparse and gcc W=1 warnings.

v2
--
- Fix review comments of v1 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
  and remove chip version as driver only depend on djtag
  hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
  depend on djtag it will be send separately.

v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.

Anurup M (8):
  arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
  dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
  Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event
counting.
  drivers: perf: hisi: Update Kconfig for Hisilicon PMU support
  drivers: perf: hisi: Add support for Hisilicon SoC event counters
  drivers: perf: hisi: use poll method to avoid L3C counter overflow
  drivers: perf: hisi: use poll method when no IRQ for MN counter
overflow
  dts: arm64: hip07: Add Hisilicon SoC PMU support

Shaokun Zhang (1):
  drivers: perf: hisi: Miscellanous node(MN) event counting in perf

Tan Xiaojun (2):
  dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
  drivers: perf: hisi: Add support for Hisilicon Djtag driver

 .../devicetree/bindings/arm/hisilicon/djtag.txt|  76 ++
 .../devicetree/bindings/arm/hisilicon/pmu.txt  |  87 +++
 Documentation/perf/hisi-pmu.txt|  76 ++
 MAINTAINERS|   9 +
 arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  79 +++
 drivers/perf/Kconfig   |   8 +
 drivers/perf/Makefile  |   1 +
 drivers/perf/hisilicon/Makefile|   1 +
 drivers/perf/hisilicon/djtag.c | 773 +
 drivers/perf/hisilicon/djtag.h |  42 ++
 drivers/perf/hisilicon/hisi_uncore_l3c.c   | 653 +
 drivers/perf/hisilicon/hisi_uncore_mn.c| 528 ++
 drivers/perf/hisilicon/hisi_uncore_pmu.c   | 445 
 drivers/perf/hisilicon/hisi_uncore_pmu.h   | 137 
 14 files changed, 2915 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
 create mode 100644 Documentation/perf/hisi-pmu.txt
 create mode 100644 drivers/perf/hisilicon/Makefile
 create mode 100644 drivers/perf/hisilicon/djtag.c
 create mode 100644 drivers/perf/hisilicon/djtag.h
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h

-- 
2.1.4



Re: [PATCH v5 3/4] dt-bindings: phy: Add support for QMP phy

2017-03-09 Thread Vivek Gautam



On 03/09/2017 04:37 PM, Bjorn Andersson wrote:

On Thu 09 Mar 10:07 CET 2017, Vivek Gautam wrote:

[..]

+   phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x488>;

Drop the leading 0 from the address.


Okay, will drop it.




+   #clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>;
+   reset-names = "phy", "common", "cfg";
+
+   pciephy_0: lane@0 {

The "@xyz" part should match the first value in "reg", i.e. 35000 here.


Right, i think this came from my older version of patches. Will correct it.

Regards
Vivek



+   reg = <0x035000 0x130>,
+   <0x035200 0x200>,
+   <0x035400 0x1dc>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_PCIE_0_PIPE_CLK>;
+   clock-names = "pipe0";
+   resets = < GCC_PCIE_0_PHY_BCR>;
+   reset-names = "lane0";
+   };
+
+   pciephy_1: lane@1 {
+   ...
+   ...
+   };

Regards,
Bjorn


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



Re: [PATCH v5 3/4] dt-bindings: phy: Add support for QMP phy

2017-03-09 Thread Vivek Gautam



On 03/09/2017 04:37 PM, Bjorn Andersson wrote:

On Thu 09 Mar 10:07 CET 2017, Vivek Gautam wrote:

[..]

+   phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x488>;

Drop the leading 0 from the address.


Okay, will drop it.




+   #clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>;
+   reset-names = "phy", "common", "cfg";
+
+   pciephy_0: lane@0 {

The "@xyz" part should match the first value in "reg", i.e. 35000 here.


Right, i think this came from my older version of patches. Will correct it.

Regards
Vivek



+   reg = <0x035000 0x130>,
+   <0x035200 0x200>,
+   <0x035400 0x1dc>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_PCIE_0_PIPE_CLK>;
+   clock-names = "pipe0";
+   resets = < GCC_PCIE_0_PHY_BCR>;
+   reset-names = "lane0";
+   };
+
+   pciephy_1: lane@1 {
+   ...
+   ...
+   };

Regards,
Bjorn


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



[PATCH 5/5] block_dev: make blkdev_dio_pool a non-rescuing bioset

2017-03-09 Thread NeilBrown
Allocations from blkdev_dio_pool are never made under
generic_make_request, so this bioset does not need a rescuer thread.

Signed-off-by: NeilBrown 
---
 fs/block_dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index c0ca5f0d0369..2eca00ec4370 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -436,7 +436,7 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
 
 static __init int blkdev_init(void)
 {
-   blkdev_dio_pool = bioset_create_rescued(4, offsetof(struct blkdev_dio, 
bio));
+   blkdev_dio_pool = bioset_create(4, offsetof(struct blkdev_dio, bio));
if (!blkdev_dio_pool)
return -ENOMEM;
return 0;




[PATCH 4/5] blk: use non-rescuing bioset for q->bio_split.

2017-03-09 Thread NeilBrown
A rescuing bioset is only useful if there might be bios from
that same bioset on the bio_list_on_stack queue at a time
when bio_alloc_bioset() is called.  This never applies to
q->bio_split.

Allocations from q->bio_split are only ever made from
blk_queue_split() which is only ever called early in each of
various make_request_fn()s.  The original bio (call this A)
is then passed to generic_make_request() and is placed on
the bio_list_on_stack queue, and the bio that was allocated
from q->bio_split (B) is processed.

The processing of this may cause other bios to be passed to
generic_make_request() or may even cause the bio B itself to
be passed, possible after some prefix has been split off
(using some other bioset).

generic_make_request() now guarantees that all of these bios
(B and dependants) will be fully processed before the tail
of the original bio A gets handled.  None of these early bios
can possible trigger an allocation from the original
q->bio_split as they are either too small to require
splitting or (more likely) are destined for a different queue.

The next time that the original q->bio_split might be used
by this thread is when A is processed again, as it might
still be too big to handle directly.  By this time there
cannot be any other bios allocated from q->bio_split in the
generic_make_request() queue.  So no rescuing will ever be
needed.

Signed-off-by: NeilBrown 
---
 block/blk-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 430c82f646eb..fae7966e1f98 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -712,7 +712,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
if (q->id < 0)
goto fail_q;
 
-   q->bio_split = bioset_create_rescued(BIO_POOL_SIZE, 0);
+   q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
if (!q->bio_split)
goto fail_id;
 




[PATCH 5/5] block_dev: make blkdev_dio_pool a non-rescuing bioset

2017-03-09 Thread NeilBrown
Allocations from blkdev_dio_pool are never made under
generic_make_request, so this bioset does not need a rescuer thread.

Signed-off-by: NeilBrown 
---
 fs/block_dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index c0ca5f0d0369..2eca00ec4370 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -436,7 +436,7 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
 
 static __init int blkdev_init(void)
 {
-   blkdev_dio_pool = bioset_create_rescued(4, offsetof(struct blkdev_dio, 
bio));
+   blkdev_dio_pool = bioset_create(4, offsetof(struct blkdev_dio, bio));
if (!blkdev_dio_pool)
return -ENOMEM;
return 0;




[PATCH 4/5] blk: use non-rescuing bioset for q->bio_split.

2017-03-09 Thread NeilBrown
A rescuing bioset is only useful if there might be bios from
that same bioset on the bio_list_on_stack queue at a time
when bio_alloc_bioset() is called.  This never applies to
q->bio_split.

Allocations from q->bio_split are only ever made from
blk_queue_split() which is only ever called early in each of
various make_request_fn()s.  The original bio (call this A)
is then passed to generic_make_request() and is placed on
the bio_list_on_stack queue, and the bio that was allocated
from q->bio_split (B) is processed.

The processing of this may cause other bios to be passed to
generic_make_request() or may even cause the bio B itself to
be passed, possible after some prefix has been split off
(using some other bioset).

generic_make_request() now guarantees that all of these bios
(B and dependants) will be fully processed before the tail
of the original bio A gets handled.  None of these early bios
can possible trigger an allocation from the original
q->bio_split as they are either too small to require
splitting or (more likely) are destined for a different queue.

The next time that the original q->bio_split might be used
by this thread is when A is processed again, as it might
still be too big to handle directly.  By this time there
cannot be any other bios allocated from q->bio_split in the
generic_make_request() queue.  So no rescuing will ever be
needed.

Signed-off-by: NeilBrown 
---
 block/blk-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 430c82f646eb..fae7966e1f98 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -712,7 +712,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
if (q->id < 0)
goto fail_q;
 
-   q->bio_split = bioset_create_rescued(BIO_POOL_SIZE, 0);
+   q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
if (!q->bio_split)
goto fail_id;
 




[PATCH 2/5] blk: remove bio_set arg from blk_queue_split()

2017-03-09 Thread NeilBrown
blk_queue_split() is always called with the last arg being q->bio_split,
where 'q' is the first arg.

Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
q->bio_split.

This is inconsistent and unnecessary.  Remove the last arg and always use
q->bio_split inside blk_queue_split()

Signed-off-by: NeilBrown 
---
 block/blk-core.c  |2 +-
 block/blk-merge.c |7 +++
 block/blk-mq.c|4 ++--
 drivers/block/drbd/drbd_req.c |2 +-
 drivers/block/pktcdvd.c   |2 +-
 drivers/block/ps3vram.c   |2 +-
 drivers/block/rsxx/dev.c  |2 +-
 drivers/block/umem.c  |2 +-
 drivers/block/zram/zram_drv.c |2 +-
 drivers/lightnvm/rrpc.c   |2 +-
 drivers/md/md.c   |2 +-
 drivers/s390/block/dcssblk.c  |2 +-
 drivers/s390/block/xpram.c|2 +-
 include/linux/blkdev.h|3 +--
 14 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index d772c221cc17..fae7966e1f98 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1635,7 +1635,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
 */
blk_queue_bounce(q, );
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio->bi_error = -EIO;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2afa262425d1..ce8838aff7f7 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -188,8 +188,7 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
return do_split ? new : NULL;
 }
 
-void blk_queue_split(struct request_queue *q, struct bio **bio,
-struct bio_set *bs)
+void blk_queue_split(struct request_queue *q, struct bio **bio)
 {
struct bio *split, *res;
unsigned nsegs;
@@ -197,14 +196,14 @@ void blk_queue_split(struct request_queue *q, struct bio 
**bio,
switch (bio_op(*bio)) {
case REQ_OP_DISCARD:
case REQ_OP_SECURE_ERASE:
-   split = blk_bio_discard_split(q, *bio, bs, );
+   split = blk_bio_discard_split(q, *bio, q->bio_split, );
break;
case REQ_OP_WRITE_ZEROES:
split = NULL;
nsegs = (*bio)->bi_phys_segments;
break;
case REQ_OP_WRITE_SAME:
-   split = blk_bio_write_same_split(q, *bio, bs, );
+   split = blk_bio_write_same_split(q, *bio, q->bio_split, );
break;
default:
split = blk_bio_segment_split(q, *bio, q->bio_split, );
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 159187a28d66..e582d7f7511e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1502,7 +1502,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue 
*q, struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (!is_flush_fua && !blk_queue_nomerges(q) &&
blk_attempt_plug_merge(q, bio, _count, _queue_rq))
@@ -1624,7 +1624,7 @@ static blk_qc_t blk_sq_make_request(struct request_queue 
*q, struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (!is_flush_fua && !blk_queue_nomerges(q)) {
if (blk_attempt_plug_merge(q, bio, _count, NULL))
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 652114ae1a8a..f6ed6f7f5ab2 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1554,7 +1554,7 @@ blk_qc_t drbd_make_request(struct request_queue *q, 
struct bio *bio)
struct drbd_device *device = (struct drbd_device *) q->queuedata;
unsigned long start_jif;
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
start_jif = jiffies;
 
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 66d846ba85a9..98394d034c29 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2414,7 +2414,7 @@ static blk_qc_t pkt_make_request(struct request_queue *q, 
struct bio *bio)
 
blk_queue_bounce(q, );
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
pd = q->queuedata;
if (!pd) {
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 456b4fe21559..48072c0c1010 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -606,7 +606,7 @@ static blk_qc_t ps3vram_make_request(struct request_queue 
*q, struct bio *bio)
 
dev_dbg(>core, "%s\n", __func__);
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
spin_lock_irq(>lock);
busy = !bio_list_empty(>list);
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index f81d70b39d10..8c8024f616ae 100644

[PATCH 3/5] blk: make the bioset rescue_workqueue optional.

2017-03-09 Thread NeilBrown
This patch converts bioset_create() and bioset_create_nobvec()
to not create a workqueue so alloctions will never trigger
punt_bios_to_rescuer().
It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued()
which preserve the old behaviour.

*All* callers of bioset_create() and bioset_create_nobvec() are
converted to the _rescued() version, so that no change in behaviour
is experienced.

It is hoped that most, if not all, biosets can end up being the
non-rescued version.

Signed-off-by: NeilBrown 
---
 block/bio.c |   30 +-
 block/blk-core.c|2 +-
 drivers/block/drbd/drbd_main.c  |2 +-
 drivers/md/bcache/super.c   |4 ++--
 drivers/md/dm-crypt.c   |2 +-
 drivers/md/dm-io.c  |2 +-
 drivers/md/dm.c |5 +++--
 drivers/md/md.c |2 +-
 drivers/md/raid5-cache.c|2 +-
 drivers/target/target_core_iblock.c |2 +-
 fs/block_dev.c  |2 +-
 fs/btrfs/extent_io.c|4 ++--
 fs/xfs/xfs_super.c  |2 +-
 include/linux/bio.h |2 ++
 14 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index e75878f8b14a..3790c3f376b6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -362,6 +362,8 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
struct bio_list punt, nopunt;
struct bio *bio;
 
+   if (!WARN_ON_ONCE(!bs->rescue_workqueue))
+   return;
/*
 * In order to guarantee forward progress we must punt only bios that
 * were allocated from this bio_set; otherwise, if there was a bio on
@@ -472,7 +474,8 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, 
struct bio_set *bs)
 
if (current->bio_list &&
(!bio_list_empty(>bio_list[0]) ||
-!bio_list_empty(>bio_list[1])))
+!bio_list_empty(>bio_list[1])) &&
+   bs->rescue_workqueue)
gfp_mask &= ~__GFP_DIRECT_RECLAIM;
 
p = mempool_alloc(bs->bio_pool, gfp_mask);
@@ -1941,7 +1944,8 @@ EXPORT_SYMBOL(bioset_free);
 
 static struct bio_set *__bioset_create(unsigned int pool_size,
   unsigned int front_pad,
-  bool create_bvec_pool)
+  bool create_bvec_pool,
+  bool create_rescue_workqueue)
 {
unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec);
struct bio_set *bs;
@@ -1972,6 +1976,9 @@ static struct bio_set *__bioset_create(unsigned int 
pool_size,
goto bad;
}
 
+   if (!create_rescue_workqueue)
+   return bs;
+
bs->rescue_workqueue = alloc_workqueue("bioset", WQ_MEM_RECLAIM, 0);
if (!bs->rescue_workqueue)
goto bad;
@@ -1997,10 +2004,16 @@ static struct bio_set *__bioset_create(unsigned int 
pool_size,
  */
 struct bio_set *bioset_create(unsigned int pool_size, unsigned int front_pad)
 {
-   return __bioset_create(pool_size, front_pad, true);
+   return __bioset_create(pool_size, front_pad, true, false);
 }
 EXPORT_SYMBOL(bioset_create);
 
+struct bio_set *bioset_create_rescued(unsigned int pool_size, unsigned int 
front_pad)
+{
+   return __bioset_create(pool_size, front_pad, true, true);
+}
+EXPORT_SYMBOL(bioset_create_rescued);
+
 /**
  * bioset_create_nobvec  - Create a bio_set without bio_vec mempool
  * @pool_size: Number of bio to cache in the mempool
@@ -2012,10 +2025,17 @@ EXPORT_SYMBOL(bioset_create);
  */
 struct bio_set *bioset_create_nobvec(unsigned int pool_size, unsigned int 
front_pad)
 {
-   return __bioset_create(pool_size, front_pad, false);
+   return __bioset_create(pool_size, front_pad, false, false);
 }
 EXPORT_SYMBOL(bioset_create_nobvec);
 
+struct bio_set *bioset_create_nobvec_rescued(unsigned int pool_size,
+unsigned int front_pad)
+{
+   return __bioset_create(pool_size, front_pad, false, true);
+}
+EXPORT_SYMBOL(bioset_create_nobvec_rescued);
+
 #ifdef CONFIG_BLK_CGROUP
 
 /**
@@ -2130,7 +2150,7 @@ static int __init init_bio(void)
bio_integrity_init();
biovec_init_slabs();
 
-   fs_bio_set = bioset_create(BIO_POOL_SIZE, 0);
+   fs_bio_set = bioset_create_rescued(BIO_POOL_SIZE, 0);
if (!fs_bio_set)
panic("bio: can't allocate bios\n");
 
diff --git a/block/blk-core.c b/block/blk-core.c
index fae7966e1f98..430c82f646eb 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -712,7 +712,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
if (q->id < 0)
goto fail_q;
 
-   q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
+

[PATCH 2/5] blk: remove bio_set arg from blk_queue_split()

2017-03-09 Thread NeilBrown
blk_queue_split() is always called with the last arg being q->bio_split,
where 'q' is the first arg.

Also blk_queue_split() sometimes uses the passed-in 'bs' and sometimes uses
q->bio_split.

This is inconsistent and unnecessary.  Remove the last arg and always use
q->bio_split inside blk_queue_split()

Signed-off-by: NeilBrown 
---
 block/blk-core.c  |2 +-
 block/blk-merge.c |7 +++
 block/blk-mq.c|4 ++--
 drivers/block/drbd/drbd_req.c |2 +-
 drivers/block/pktcdvd.c   |2 +-
 drivers/block/ps3vram.c   |2 +-
 drivers/block/rsxx/dev.c  |2 +-
 drivers/block/umem.c  |2 +-
 drivers/block/zram/zram_drv.c |2 +-
 drivers/lightnvm/rrpc.c   |2 +-
 drivers/md/md.c   |2 +-
 drivers/s390/block/dcssblk.c  |2 +-
 drivers/s390/block/xpram.c|2 +-
 include/linux/blkdev.h|3 +--
 14 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index d772c221cc17..fae7966e1f98 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1635,7 +1635,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
 */
blk_queue_bounce(q, );
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio->bi_error = -EIO;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2afa262425d1..ce8838aff7f7 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -188,8 +188,7 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
return do_split ? new : NULL;
 }
 
-void blk_queue_split(struct request_queue *q, struct bio **bio,
-struct bio_set *bs)
+void blk_queue_split(struct request_queue *q, struct bio **bio)
 {
struct bio *split, *res;
unsigned nsegs;
@@ -197,14 +196,14 @@ void blk_queue_split(struct request_queue *q, struct bio 
**bio,
switch (bio_op(*bio)) {
case REQ_OP_DISCARD:
case REQ_OP_SECURE_ERASE:
-   split = blk_bio_discard_split(q, *bio, bs, );
+   split = blk_bio_discard_split(q, *bio, q->bio_split, );
break;
case REQ_OP_WRITE_ZEROES:
split = NULL;
nsegs = (*bio)->bi_phys_segments;
break;
case REQ_OP_WRITE_SAME:
-   split = blk_bio_write_same_split(q, *bio, bs, );
+   split = blk_bio_write_same_split(q, *bio, q->bio_split, );
break;
default:
split = blk_bio_segment_split(q, *bio, q->bio_split, );
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 159187a28d66..e582d7f7511e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1502,7 +1502,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue 
*q, struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (!is_flush_fua && !blk_queue_nomerges(q) &&
blk_attempt_plug_merge(q, bio, _count, _queue_rq))
@@ -1624,7 +1624,7 @@ static blk_qc_t blk_sq_make_request(struct request_queue 
*q, struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
if (!is_flush_fua && !blk_queue_nomerges(q)) {
if (blk_attempt_plug_merge(q, bio, _count, NULL))
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 652114ae1a8a..f6ed6f7f5ab2 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1554,7 +1554,7 @@ blk_qc_t drbd_make_request(struct request_queue *q, 
struct bio *bio)
struct drbd_device *device = (struct drbd_device *) q->queuedata;
unsigned long start_jif;
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
start_jif = jiffies;
 
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 66d846ba85a9..98394d034c29 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2414,7 +2414,7 @@ static blk_qc_t pkt_make_request(struct request_queue *q, 
struct bio *bio)
 
blk_queue_bounce(q, );
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
pd = q->queuedata;
if (!pd) {
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 456b4fe21559..48072c0c1010 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -606,7 +606,7 @@ static blk_qc_t ps3vram_make_request(struct request_queue 
*q, struct bio *bio)
 
dev_dbg(>core, "%s\n", __func__);
 
-   blk_queue_split(q, , q->bio_split);
+   blk_queue_split(q, );
 
spin_lock_irq(>lock);
busy = !bio_list_empty(>list);
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index f81d70b39d10..8c8024f616ae 100644
--- 

[PATCH 3/5] blk: make the bioset rescue_workqueue optional.

2017-03-09 Thread NeilBrown
This patch converts bioset_create() and bioset_create_nobvec()
to not create a workqueue so alloctions will never trigger
punt_bios_to_rescuer().
It also introduces bioset_create_rescued() and bioset_create_nobvec_rescued()
which preserve the old behaviour.

*All* callers of bioset_create() and bioset_create_nobvec() are
converted to the _rescued() version, so that no change in behaviour
is experienced.

It is hoped that most, if not all, biosets can end up being the
non-rescued version.

Signed-off-by: NeilBrown 
---
 block/bio.c |   30 +-
 block/blk-core.c|2 +-
 drivers/block/drbd/drbd_main.c  |2 +-
 drivers/md/bcache/super.c   |4 ++--
 drivers/md/dm-crypt.c   |2 +-
 drivers/md/dm-io.c  |2 +-
 drivers/md/dm.c |5 +++--
 drivers/md/md.c |2 +-
 drivers/md/raid5-cache.c|2 +-
 drivers/target/target_core_iblock.c |2 +-
 fs/block_dev.c  |2 +-
 fs/btrfs/extent_io.c|4 ++--
 fs/xfs/xfs_super.c  |2 +-
 include/linux/bio.h |2 ++
 14 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index e75878f8b14a..3790c3f376b6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -362,6 +362,8 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
struct bio_list punt, nopunt;
struct bio *bio;
 
+   if (!WARN_ON_ONCE(!bs->rescue_workqueue))
+   return;
/*
 * In order to guarantee forward progress we must punt only bios that
 * were allocated from this bio_set; otherwise, if there was a bio on
@@ -472,7 +474,8 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, 
struct bio_set *bs)
 
if (current->bio_list &&
(!bio_list_empty(>bio_list[0]) ||
-!bio_list_empty(>bio_list[1])))
+!bio_list_empty(>bio_list[1])) &&
+   bs->rescue_workqueue)
gfp_mask &= ~__GFP_DIRECT_RECLAIM;
 
p = mempool_alloc(bs->bio_pool, gfp_mask);
@@ -1941,7 +1944,8 @@ EXPORT_SYMBOL(bioset_free);
 
 static struct bio_set *__bioset_create(unsigned int pool_size,
   unsigned int front_pad,
-  bool create_bvec_pool)
+  bool create_bvec_pool,
+  bool create_rescue_workqueue)
 {
unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec);
struct bio_set *bs;
@@ -1972,6 +1976,9 @@ static struct bio_set *__bioset_create(unsigned int 
pool_size,
goto bad;
}
 
+   if (!create_rescue_workqueue)
+   return bs;
+
bs->rescue_workqueue = alloc_workqueue("bioset", WQ_MEM_RECLAIM, 0);
if (!bs->rescue_workqueue)
goto bad;
@@ -1997,10 +2004,16 @@ static struct bio_set *__bioset_create(unsigned int 
pool_size,
  */
 struct bio_set *bioset_create(unsigned int pool_size, unsigned int front_pad)
 {
-   return __bioset_create(pool_size, front_pad, true);
+   return __bioset_create(pool_size, front_pad, true, false);
 }
 EXPORT_SYMBOL(bioset_create);
 
+struct bio_set *bioset_create_rescued(unsigned int pool_size, unsigned int 
front_pad)
+{
+   return __bioset_create(pool_size, front_pad, true, true);
+}
+EXPORT_SYMBOL(bioset_create_rescued);
+
 /**
  * bioset_create_nobvec  - Create a bio_set without bio_vec mempool
  * @pool_size: Number of bio to cache in the mempool
@@ -2012,10 +2025,17 @@ EXPORT_SYMBOL(bioset_create);
  */
 struct bio_set *bioset_create_nobvec(unsigned int pool_size, unsigned int 
front_pad)
 {
-   return __bioset_create(pool_size, front_pad, false);
+   return __bioset_create(pool_size, front_pad, false, false);
 }
 EXPORT_SYMBOL(bioset_create_nobvec);
 
+struct bio_set *bioset_create_nobvec_rescued(unsigned int pool_size,
+unsigned int front_pad)
+{
+   return __bioset_create(pool_size, front_pad, false, true);
+}
+EXPORT_SYMBOL(bioset_create_nobvec_rescued);
+
 #ifdef CONFIG_BLK_CGROUP
 
 /**
@@ -2130,7 +2150,7 @@ static int __init init_bio(void)
bio_integrity_init();
biovec_init_slabs();
 
-   fs_bio_set = bioset_create(BIO_POOL_SIZE, 0);
+   fs_bio_set = bioset_create_rescued(BIO_POOL_SIZE, 0);
if (!fs_bio_set)
panic("bio: can't allocate bios\n");
 
diff --git a/block/blk-core.c b/block/blk-core.c
index fae7966e1f98..430c82f646eb 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -712,7 +712,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, 
int node_id)
if (q->id < 0)
goto fail_q;
 
-   q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
+   q->bio_split 

[PATCH 1/5] blk: Ensure users for current->bio_list can see the full list.

2017-03-09 Thread NeilBrown
Commit 79bd99596b73 ("blk: improve order of bio handling in 
generic_make_request()")
changed current->bio_list so that it did not contain *all* of the
queued bios, but only those submitted by the currently running
make_request_fn.

There are two places which walk the list and requeue selected bios,
and others that check if the list is empty.  These are no longer
correct.

So redefine current->bio_list to point to an array of two lists, which
contain all queued bios, and adjust various code to test or walk both
lists.

Signed-off-by: NeilBrown 
---
 block/bio.c |   12 +---
 block/blk-core.c|   30 ++
 drivers/md/dm.c |   29 -
 drivers/md/raid10.c |3 ++-
 4 files changed, 45 insertions(+), 29 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 5eec5e08417f..e75878f8b14a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -376,10 +376,14 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
bio_list_init();
bio_list_init();
 
-   while ((bio = bio_list_pop(current->bio_list)))
+   while ((bio = bio_list_pop(>bio_list[0])))
bio_list_add(bio->bi_pool == bs ?  : , bio);
+   current->bio_list[0] = nopunt;
 
-   *current->bio_list = nopunt;
+   bio_list_init();
+   while ((bio = bio_list_pop(>bio_list[1])))
+   bio_list_add(bio->bi_pool == bs ?  : , bio);
+   current->bio_list[1] = nopunt;
 
spin_lock(>rescue_lock);
bio_list_merge(>rescue_list, );
@@ -466,7 +470,9 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, 
struct bio_set *bs)
 * we retry with the original gfp_flags.
 */
 
-   if (current->bio_list && !bio_list_empty(current->bio_list))
+   if (current->bio_list &&
+   (!bio_list_empty(>bio_list[0]) ||
+!bio_list_empty(>bio_list[1])))
gfp_mask &= ~__GFP_DIRECT_RECLAIM;
 
p = mempool_alloc(bs->bio_pool, gfp_mask);
diff --git a/block/blk-core.c b/block/blk-core.c
index 0eeb99ef654f..d772c221cc17 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1973,7 +1973,14 @@ generic_make_request_checks(struct bio *bio)
  */
 blk_qc_t generic_make_request(struct bio *bio)
 {
-   struct bio_list bio_list_on_stack;
+   /*
+* bio_list_on_stack[0] contains bios submitted by the current
+* make_request_fn.
+* bio_list_on_stack[1] contains bios that were submitted before
+* the current make_request_fn, but that haven't been processed
+* yet.
+*/
+   struct bio_list bio_list_on_stack[2];
blk_qc_t ret = BLK_QC_T_NONE;
 
if (!generic_make_request_checks(bio))
@@ -1990,7 +1997,7 @@ blk_qc_t generic_make_request(struct bio *bio)
 * should be added at the tail
 */
if (current->bio_list) {
-   bio_list_add(current->bio_list, bio);
+   bio_list_add(>bio_list[0], bio);
goto out;
}
 
@@ -2009,18 +2016,17 @@ blk_qc_t generic_make_request(struct bio *bio)
 * bio_list, and call into ->make_request() again.
 */
BUG_ON(bio->bi_next);
-   bio_list_init(_list_on_stack);
-   current->bio_list = _list_on_stack;
+   bio_list_init(_list_on_stack[0]);
+   current->bio_list = bio_list_on_stack;
do {
struct request_queue *q = bdev_get_queue(bio->bi_bdev);
 
if (likely(blk_queue_enter(q, false) == 0)) {
-   struct bio_list hold;
struct bio_list lower, same;
 
/* Create a fresh bio_list for all subordinate requests 
*/
-   hold = bio_list_on_stack;
-   bio_list_init(_list_on_stack);
+   bio_list_on_stack[1] = bio_list_on_stack[0];
+   bio_list_init(_list_on_stack[0]);
ret = q->make_request_fn(q, bio);
 
blk_queue_exit(q);
@@ -2030,19 +2036,19 @@ blk_qc_t generic_make_request(struct bio *bio)
 */
bio_list_init();
bio_list_init();
-   while ((bio = bio_list_pop(_list_on_stack)) != NULL)
+   while ((bio = bio_list_pop(_list_on_stack[0])) != 
NULL)
if (q == bdev_get_queue(bio->bi_bdev))
bio_list_add(, bio);
else
bio_list_add(, bio);
/* now assemble so we handle the lowest level first */
-   bio_list_merge(_list_on_stack, );
-   bio_list_merge(_list_on_stack, );
-   bio_list_merge(_list_on_stack, );
+   bio_list_merge(_list_on_stack[0], );
+

[PATCH 1/5] blk: Ensure users for current->bio_list can see the full list.

2017-03-09 Thread NeilBrown
Commit 79bd99596b73 ("blk: improve order of bio handling in 
generic_make_request()")
changed current->bio_list so that it did not contain *all* of the
queued bios, but only those submitted by the currently running
make_request_fn.

There are two places which walk the list and requeue selected bios,
and others that check if the list is empty.  These are no longer
correct.

So redefine current->bio_list to point to an array of two lists, which
contain all queued bios, and adjust various code to test or walk both
lists.

Signed-off-by: NeilBrown 
---
 block/bio.c |   12 +---
 block/blk-core.c|   30 ++
 drivers/md/dm.c |   29 -
 drivers/md/raid10.c |3 ++-
 4 files changed, 45 insertions(+), 29 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 5eec5e08417f..e75878f8b14a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -376,10 +376,14 @@ static void punt_bios_to_rescuer(struct bio_set *bs)
bio_list_init();
bio_list_init();
 
-   while ((bio = bio_list_pop(current->bio_list)))
+   while ((bio = bio_list_pop(>bio_list[0])))
bio_list_add(bio->bi_pool == bs ?  : , bio);
+   current->bio_list[0] = nopunt;
 
-   *current->bio_list = nopunt;
+   bio_list_init();
+   while ((bio = bio_list_pop(>bio_list[1])))
+   bio_list_add(bio->bi_pool == bs ?  : , bio);
+   current->bio_list[1] = nopunt;
 
spin_lock(>rescue_lock);
bio_list_merge(>rescue_list, );
@@ -466,7 +470,9 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, 
struct bio_set *bs)
 * we retry with the original gfp_flags.
 */
 
-   if (current->bio_list && !bio_list_empty(current->bio_list))
+   if (current->bio_list &&
+   (!bio_list_empty(>bio_list[0]) ||
+!bio_list_empty(>bio_list[1])))
gfp_mask &= ~__GFP_DIRECT_RECLAIM;
 
p = mempool_alloc(bs->bio_pool, gfp_mask);
diff --git a/block/blk-core.c b/block/blk-core.c
index 0eeb99ef654f..d772c221cc17 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1973,7 +1973,14 @@ generic_make_request_checks(struct bio *bio)
  */
 blk_qc_t generic_make_request(struct bio *bio)
 {
-   struct bio_list bio_list_on_stack;
+   /*
+* bio_list_on_stack[0] contains bios submitted by the current
+* make_request_fn.
+* bio_list_on_stack[1] contains bios that were submitted before
+* the current make_request_fn, but that haven't been processed
+* yet.
+*/
+   struct bio_list bio_list_on_stack[2];
blk_qc_t ret = BLK_QC_T_NONE;
 
if (!generic_make_request_checks(bio))
@@ -1990,7 +1997,7 @@ blk_qc_t generic_make_request(struct bio *bio)
 * should be added at the tail
 */
if (current->bio_list) {
-   bio_list_add(current->bio_list, bio);
+   bio_list_add(>bio_list[0], bio);
goto out;
}
 
@@ -2009,18 +2016,17 @@ blk_qc_t generic_make_request(struct bio *bio)
 * bio_list, and call into ->make_request() again.
 */
BUG_ON(bio->bi_next);
-   bio_list_init(_list_on_stack);
-   current->bio_list = _list_on_stack;
+   bio_list_init(_list_on_stack[0]);
+   current->bio_list = bio_list_on_stack;
do {
struct request_queue *q = bdev_get_queue(bio->bi_bdev);
 
if (likely(blk_queue_enter(q, false) == 0)) {
-   struct bio_list hold;
struct bio_list lower, same;
 
/* Create a fresh bio_list for all subordinate requests 
*/
-   hold = bio_list_on_stack;
-   bio_list_init(_list_on_stack);
+   bio_list_on_stack[1] = bio_list_on_stack[0];
+   bio_list_init(_list_on_stack[0]);
ret = q->make_request_fn(q, bio);
 
blk_queue_exit(q);
@@ -2030,19 +2036,19 @@ blk_qc_t generic_make_request(struct bio *bio)
 */
bio_list_init();
bio_list_init();
-   while ((bio = bio_list_pop(_list_on_stack)) != NULL)
+   while ((bio = bio_list_pop(_list_on_stack[0])) != 
NULL)
if (q == bdev_get_queue(bio->bi_bdev))
bio_list_add(, bio);
else
bio_list_add(, bio);
/* now assemble so we handle the lowest level first */
-   bio_list_merge(_list_on_stack, );
-   bio_list_merge(_list_on_stack, );
-   bio_list_merge(_list_on_stack, );
+   bio_list_merge(_list_on_stack[0], );
+   

[PATCH 0/5] Updates following recent generic_make_request improvement

2017-03-09 Thread NeilBrown
This is a rebase of the series I sent earlier, based on the
very latest from Linus, which included my first patch.

The first fixes a problem that patch introduced, and so should go to
Linux promptly.
The others are more general improvements and can go in the normal
course of events.

It is possible that the changes to btrfs and xfs can just be dropped
as a subsequent patch will be needed to revert them anyway.  They are
there only to be able to say that "blk: make the bioset
rescue_workqueue optional." doesn't change any functionality at all.

Thanks,
NeilBrown

---

NeilBrown (5):
  blk: Ensure users for current->bio_list can see the full list.
  blk: remove bio_set arg from blk_queue_split()
  blk: make the bioset rescue_workqueue optional.
  blk: use non-rescuing bioset for q->bio_split.
  block_dev: make blkdev_dio_pool a non-rescuing bioset


 block/bio.c |   40 +--
 block/blk-core.c|   32 +---
 block/blk-merge.c   |7 +++---
 block/blk-mq.c  |4 ++--
 drivers/block/drbd/drbd_main.c  |2 +-
 drivers/block/drbd/drbd_req.c   |2 +-
 drivers/block/pktcdvd.c |2 +-
 drivers/block/ps3vram.c |2 +-
 drivers/block/rsxx/dev.c|2 +-
 drivers/block/umem.c|2 +-
 drivers/block/zram/zram_drv.c   |2 +-
 drivers/lightnvm/rrpc.c |2 +-
 drivers/md/bcache/super.c   |4 ++--
 drivers/md/dm-crypt.c   |2 +-
 drivers/md/dm-io.c  |2 +-
 drivers/md/dm.c |   32 
 drivers/md/md.c |4 ++--
 drivers/md/raid10.c |3 ++-
 drivers/md/raid5-cache.c|2 +-
 drivers/s390/block/dcssblk.c|2 +-
 drivers/s390/block/xpram.c  |2 +-
 drivers/target/target_core_iblock.c |2 +-
 fs/btrfs/extent_io.c|4 ++--
 fs/xfs/xfs_super.c  |2 +-
 include/linux/bio.h |2 ++
 include/linux/blkdev.h  |3 +--
 26 files changed, 101 insertions(+), 64 deletions(-)

--
Signature



[PATCH 0/5] Updates following recent generic_make_request improvement

2017-03-09 Thread NeilBrown
This is a rebase of the series I sent earlier, based on the
very latest from Linus, which included my first patch.

The first fixes a problem that patch introduced, and so should go to
Linux promptly.
The others are more general improvements and can go in the normal
course of events.

It is possible that the changes to btrfs and xfs can just be dropped
as a subsequent patch will be needed to revert them anyway.  They are
there only to be able to say that "blk: make the bioset
rescue_workqueue optional." doesn't change any functionality at all.

Thanks,
NeilBrown

---

NeilBrown (5):
  blk: Ensure users for current->bio_list can see the full list.
  blk: remove bio_set arg from blk_queue_split()
  blk: make the bioset rescue_workqueue optional.
  blk: use non-rescuing bioset for q->bio_split.
  block_dev: make blkdev_dio_pool a non-rescuing bioset


 block/bio.c |   40 +--
 block/blk-core.c|   32 +---
 block/blk-merge.c   |7 +++---
 block/blk-mq.c  |4 ++--
 drivers/block/drbd/drbd_main.c  |2 +-
 drivers/block/drbd/drbd_req.c   |2 +-
 drivers/block/pktcdvd.c |2 +-
 drivers/block/ps3vram.c |2 +-
 drivers/block/rsxx/dev.c|2 +-
 drivers/block/umem.c|2 +-
 drivers/block/zram/zram_drv.c   |2 +-
 drivers/lightnvm/rrpc.c |2 +-
 drivers/md/bcache/super.c   |4 ++--
 drivers/md/dm-crypt.c   |2 +-
 drivers/md/dm-io.c  |2 +-
 drivers/md/dm.c |   32 
 drivers/md/md.c |4 ++--
 drivers/md/raid10.c |3 ++-
 drivers/md/raid5-cache.c|2 +-
 drivers/s390/block/dcssblk.c|2 +-
 drivers/s390/block/xpram.c  |2 +-
 drivers/target/target_core_iblock.c |2 +-
 fs/btrfs/extent_io.c|4 ++--
 fs/xfs/xfs_super.c  |2 +-
 include/linux/bio.h |2 ++
 include/linux/blkdev.h  |3 +--
 26 files changed, 101 insertions(+), 64 deletions(-)

--
Signature



Re: outreachy

2017-03-09 Thread Greg KH
On Thu, Mar 09, 2017 at 02:15:21PM -0800, Florian Fainelli wrote:
> On 03/09/2017 01:20 PM, Greg KH wrote:
> > On Thu, Mar 09, 2017 at 01:56:49PM -0700, Stephen Warren wrote:
> >> On 03/09/2017 01:51 PM, Scott Branden wrote:
> >>> Hi Julia,
> >>>
> >>> On 17-03-09 12:36 PM, Julia Lawall wrote:
>  Hello,
> 
>  I discussed the issue of outreachy patches for bcm with Greg, and we are
>  not convinced that not having the patches CCd to you is such a good idea.
>  While we don't want to spam you with noise, some of the applicants are
>  starting to make more significant changes that it could be useful for you
>  to be aware of.
> 
>  Could we try a compromise where you are not CCd on whitespace patches,
>  but
>  you are CCd on patches that actually modify the code?
> >>>
> >>> All I'm asking is you work through your outreachy patches internal first
> >>> to get rid of the most basic mistakes and email traffic it is geerating.
> >>>  Once that learning process is through then they can be sent out like
> >>> any other patches to the kernel mailing lists and maintainers.
> >>
> >> +1 from me too; I find these patches rather high volume and had to add a
> >> filter to keep them out of my primary inbox.
> > 
> > Hah!  That's the joy of being a maintainer of a driver in staging.  Even
> > if you filter out outreachy, you are going to get a lot of "basic
> > mistakes" and other type patches cc:ed to you.
> > 
> > I strongly suggest, that if you all don't like this type of stuff,
> > either:
> > - work to get the code out of staging as soon as possible (i.e.
> >   send me coding style fixes for everything right now, and then
> >   fix up the rest of the stuff.)
> > - take yourself off the maintainer list for this code.
> 
> Keep in mind that most people on this CC list are getting these patches
> because of the bcm283* regular expression, and maybe that's what needs
> fixing here in the first place.

Yes, I suggest the someone fixes that if they do not wish to get these
types of emails.  Having a regex like that in MAINTAINERS is very crazy,
from another thread I don't think it's really doing what you all want it
to do (meaning it's hitting a lot more files than expected.)

> > It's your choice, outreachy right now is a lot of patches, but again,
> > it's not going to keep you from getting the "basic" stuff sent to you
> > in ways that is totally wrong.
> 
> That is absolutely true, but the thing is that we really got a big spike
> of patch submissions lately, and that was totally not accepted. I am not
> asking for a "heads-up" email telling people that they are going to
> receive more traffic than usual (because that would be too much over
> head), but if there was an internal review first on the outreachy
> mailing-list and second a proper submission which is going to pass your
> acceptance criteria, we would be de facto reducing the amount of emails
> that we received.
> 
> The outreachy list obviously has people like you and Julia who are
> willing to help and provide feedback, so I really don't see what's the
> problem in setting up a two tier review here, it does not change
> anything for you, but it does change a lot for us.

Again, even if outreachy isn't happening, you are still going to be
getting these types of patches from all of the "normal" people that send
staging cleanup patches.  So it's not going to buy you all that much of
a reprieve.

So please send in a MAINTAINERS patch if you don't wish to get these
kinds of patches.  Or, again, just spend a day and send me cleanup
patches to keep anyone else from needing to send in basic checkpatch
fixes for this code.

thanks,

greg k-h


Re: outreachy

2017-03-09 Thread Greg KH
On Thu, Mar 09, 2017 at 02:15:21PM -0800, Florian Fainelli wrote:
> On 03/09/2017 01:20 PM, Greg KH wrote:
> > On Thu, Mar 09, 2017 at 01:56:49PM -0700, Stephen Warren wrote:
> >> On 03/09/2017 01:51 PM, Scott Branden wrote:
> >>> Hi Julia,
> >>>
> >>> On 17-03-09 12:36 PM, Julia Lawall wrote:
>  Hello,
> 
>  I discussed the issue of outreachy patches for bcm with Greg, and we are
>  not convinced that not having the patches CCd to you is such a good idea.
>  While we don't want to spam you with noise, some of the applicants are
>  starting to make more significant changes that it could be useful for you
>  to be aware of.
> 
>  Could we try a compromise where you are not CCd on whitespace patches,
>  but
>  you are CCd on patches that actually modify the code?
> >>>
> >>> All I'm asking is you work through your outreachy patches internal first
> >>> to get rid of the most basic mistakes and email traffic it is geerating.
> >>>  Once that learning process is through then they can be sent out like
> >>> any other patches to the kernel mailing lists and maintainers.
> >>
> >> +1 from me too; I find these patches rather high volume and had to add a
> >> filter to keep them out of my primary inbox.
> > 
> > Hah!  That's the joy of being a maintainer of a driver in staging.  Even
> > if you filter out outreachy, you are going to get a lot of "basic
> > mistakes" and other type patches cc:ed to you.
> > 
> > I strongly suggest, that if you all don't like this type of stuff,
> > either:
> > - work to get the code out of staging as soon as possible (i.e.
> >   send me coding style fixes for everything right now, and then
> >   fix up the rest of the stuff.)
> > - take yourself off the maintainer list for this code.
> 
> Keep in mind that most people on this CC list are getting these patches
> because of the bcm283* regular expression, and maybe that's what needs
> fixing here in the first place.

Yes, I suggest the someone fixes that if they do not wish to get these
types of emails.  Having a regex like that in MAINTAINERS is very crazy,
from another thread I don't think it's really doing what you all want it
to do (meaning it's hitting a lot more files than expected.)

> > It's your choice, outreachy right now is a lot of patches, but again,
> > it's not going to keep you from getting the "basic" stuff sent to you
> > in ways that is totally wrong.
> 
> That is absolutely true, but the thing is that we really got a big spike
> of patch submissions lately, and that was totally not accepted. I am not
> asking for a "heads-up" email telling people that they are going to
> receive more traffic than usual (because that would be too much over
> head), but if there was an internal review first on the outreachy
> mailing-list and second a proper submission which is going to pass your
> acceptance criteria, we would be de facto reducing the amount of emails
> that we received.
> 
> The outreachy list obviously has people like you and Julia who are
> willing to help and provide feedback, so I really don't see what's the
> problem in setting up a two tier review here, it does not change
> anything for you, but it does change a lot for us.

Again, even if outreachy isn't happening, you are still going to be
getting these types of patches from all of the "normal" people that send
staging cleanup patches.  So it's not going to buy you all that much of
a reprieve.

So please send in a MAINTAINERS patch if you don't wish to get these
kinds of patches.  Or, again, just spend a day and send me cleanup
patches to keep anyone else from needing to send in basic checkpatch
fixes for this code.

thanks,

greg k-h


[PATCH net, v2] dccp/tcp: fix routing redirect race

2017-03-09 Thread Jon Maxwell
As Eric Dumazet pointed out this also needs to be fixed in IPv6.
v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.

We have seen a few incidents lately where a dst_enty has been freed
with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
dst_entry. If the conditions/timings are right a crash then ensues when the
freed dst_entry is referenced later on. A Common crashing back trace is:

 #8 [] page_fault at 8163e648
[exception RIP: __tcp_ack_snd_check+74]
.
.
 #9 [] tcp_rcv_established at 81580b64
#10 [] tcp_v4_do_rcv at 8158b54a
#11 [] tcp_v4_rcv at 8158cd02
#12 [] ip_local_deliver_finish at 815668f4
#13 [] ip_local_deliver at 81566bd9
#14 [] ip_rcv_finish at 8156656d
#15 [] ip_rcv at 81566f06
#16 [] __netif_receive_skb_core at 8152b3a2
#17 [] __netif_receive_skb at 8152b608
#18 [] netif_receive_skb at 8152b690
#19 [] vmxnet3_rq_rx_complete at a015eeaf [vmxnet3]
#20 [] vmxnet3_poll_rx_only at a015f32a [vmxnet3]
#21 [] net_rx_action at 8152bac2
#22 [] __do_softirq at 81084b4f
#23 [] call_softirq at 8164845c
#24 [] do_softirq at 81016fc5
#25 [] irq_exit at 81084ee5
#26 [] do_IRQ at 81648ff8

Of course it may happen with other NIC drivers as well.

It's found the freed dst_entry here:

 224 static bool tcp_in_quickack_mode(struct sock *sk)↩
 225 {↩
 226 ▹   const struct inet_connection_sock *icsk = inet_csk(sk);↩
 227 ▹   const struct dst_entry *dst = __sk_dst_get(sk);↩
 228 ↩
 229 ▹   return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩
 230 ▹   ▹   (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩
 231 }↩

But there are other backtraces attributed to the same freed dst_entry in
netfilter code as well.

All the vmcores showed 2 significant clues:

- Remote hosts behind the default gateway had always been redirected to a
different gateway. A rtable/dst_entry will be added for that host. Making
more dst_entrys with lower reference counts. Making this more probable.

- All vmcores showed a postitive LockDroppedIcmps value, e.g:

LockDroppedIcmps  267

A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
regardless of whether user space has the socket locked. This can result in a
race condition where the same dst_entry cached in sk->sk_dst_entry can be
decremented twice for the same socket via:

do_redirect()->__sk_dst_check()-> dst_release().

Which leads to the dst_entry being prematurely freed with another socket
pointing to it via sk->sk_dst_cache and a subsequent crash.

To fix this skip do_redirect() if usespace has the socket locked. Instead let
the redirect take place later when user space does not have the socket
locked.

The dccp/IPv6 code is very similar in this respect, so fixing it there too.

As Eric Garver pointed out the following commit now invalidates routes. Which
can set the dst->obsolete flag so that ipv4_dst_check() returns null and
triggers the dst_release().

Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
Cc: Eric Garver 
Cc: Hannes Sowa 
Signed-off-by: Jon Maxwell 
---
 net/dccp/ipv4.c | 3 ++-
 net/dccp/ipv6.c | 8 +---
 net/ipv4/tcp_ipv4.c | 3 ++-
 net/ipv6/tcp_ipv6.c | 8 +---
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 409d0cf..b99168b 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -289,7 +289,8 @@ static void dccp_v4_err(struct sk_buff *skb, u32 info)
 
switch (type) {
case ICMP_REDIRECT:
-   dccp_do_redirect(skb, sk);
+   if (!sock_owned_by_user(sk))
+   dccp_do_redirect(skb, sk);
goto out;
case ICMP_SOURCE_QUENCH:
/* Just silently ignore these. */
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 233b573..d9b6a4e 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -122,10 +122,12 @@ static void dccp_v6_err(struct sk_buff *skb, struct 
inet6_skb_parm *opt,
np = inet6_sk(sk);
 
if (type == NDISC_REDIRECT) {
-   struct dst_entry *dst = __sk_dst_check(sk, np->dst_cookie);
+   if (!sock_owned_by_user(sk)) {
+   struct dst_entry *dst = __sk_dst_check(sk, 
np->dst_cookie);
 
-   if (dst)
-   dst->ops->redirect(dst, sk, skb);
+   if (dst)
+   dst->ops->redirect(dst, sk, skb);
+   }
goto out;
}
 
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8f3ec13..575e19d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -431,7 +431,8 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
 
switch (type) {
case ICMP_REDIRECT:
-   do_redirect(icmp_skb, sk);
+   if 

[PATCH net, v2] dccp/tcp: fix routing redirect race

2017-03-09 Thread Jon Maxwell
As Eric Dumazet pointed out this also needs to be fixed in IPv6.
v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.

We have seen a few incidents lately where a dst_enty has been freed
with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
dst_entry. If the conditions/timings are right a crash then ensues when the
freed dst_entry is referenced later on. A Common crashing back trace is:

 #8 [] page_fault at 8163e648
[exception RIP: __tcp_ack_snd_check+74]
.
.
 #9 [] tcp_rcv_established at 81580b64
#10 [] tcp_v4_do_rcv at 8158b54a
#11 [] tcp_v4_rcv at 8158cd02
#12 [] ip_local_deliver_finish at 815668f4
#13 [] ip_local_deliver at 81566bd9
#14 [] ip_rcv_finish at 8156656d
#15 [] ip_rcv at 81566f06
#16 [] __netif_receive_skb_core at 8152b3a2
#17 [] __netif_receive_skb at 8152b608
#18 [] netif_receive_skb at 8152b690
#19 [] vmxnet3_rq_rx_complete at a015eeaf [vmxnet3]
#20 [] vmxnet3_poll_rx_only at a015f32a [vmxnet3]
#21 [] net_rx_action at 8152bac2
#22 [] __do_softirq at 81084b4f
#23 [] call_softirq at 8164845c
#24 [] do_softirq at 81016fc5
#25 [] irq_exit at 81084ee5
#26 [] do_IRQ at 81648ff8

Of course it may happen with other NIC drivers as well.

It's found the freed dst_entry here:

 224 static bool tcp_in_quickack_mode(struct sock *sk)↩
 225 {↩
 226 ▹   const struct inet_connection_sock *icsk = inet_csk(sk);↩
 227 ▹   const struct dst_entry *dst = __sk_dst_get(sk);↩
 228 ↩
 229 ▹   return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩
 230 ▹   ▹   (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩
 231 }↩

But there are other backtraces attributed to the same freed dst_entry in
netfilter code as well.

All the vmcores showed 2 significant clues:

- Remote hosts behind the default gateway had always been redirected to a
different gateway. A rtable/dst_entry will be added for that host. Making
more dst_entrys with lower reference counts. Making this more probable.

- All vmcores showed a postitive LockDroppedIcmps value, e.g:

LockDroppedIcmps  267

A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
regardless of whether user space has the socket locked. This can result in a
race condition where the same dst_entry cached in sk->sk_dst_entry can be
decremented twice for the same socket via:

do_redirect()->__sk_dst_check()-> dst_release().

Which leads to the dst_entry being prematurely freed with another socket
pointing to it via sk->sk_dst_cache and a subsequent crash.

To fix this skip do_redirect() if usespace has the socket locked. Instead let
the redirect take place later when user space does not have the socket
locked.

The dccp/IPv6 code is very similar in this respect, so fixing it there too.

As Eric Garver pointed out the following commit now invalidates routes. Which
can set the dst->obsolete flag so that ipv4_dst_check() returns null and
triggers the dst_release().

Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
Cc: Eric Garver 
Cc: Hannes Sowa 
Signed-off-by: Jon Maxwell 
---
 net/dccp/ipv4.c | 3 ++-
 net/dccp/ipv6.c | 8 +---
 net/ipv4/tcp_ipv4.c | 3 ++-
 net/ipv6/tcp_ipv6.c | 8 +---
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 409d0cf..b99168b 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -289,7 +289,8 @@ static void dccp_v4_err(struct sk_buff *skb, u32 info)
 
switch (type) {
case ICMP_REDIRECT:
-   dccp_do_redirect(skb, sk);
+   if (!sock_owned_by_user(sk))
+   dccp_do_redirect(skb, sk);
goto out;
case ICMP_SOURCE_QUENCH:
/* Just silently ignore these. */
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 233b573..d9b6a4e 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -122,10 +122,12 @@ static void dccp_v6_err(struct sk_buff *skb, struct 
inet6_skb_parm *opt,
np = inet6_sk(sk);
 
if (type == NDISC_REDIRECT) {
-   struct dst_entry *dst = __sk_dst_check(sk, np->dst_cookie);
+   if (!sock_owned_by_user(sk)) {
+   struct dst_entry *dst = __sk_dst_check(sk, 
np->dst_cookie);
 
-   if (dst)
-   dst->ops->redirect(dst, sk, skb);
+   if (dst)
+   dst->ops->redirect(dst, sk, skb);
+   }
goto out;
}
 
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8f3ec13..575e19d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -431,7 +431,8 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
 
switch (type) {
case ICMP_REDIRECT:
-   do_redirect(icmp_skb, sk);
+   if (!sock_owned_by_user(sk))
+   

Re: [PATCH] Minor coding guideline Fix in lusture module

2017-03-09 Thread Dilger, Andreas
On Mar 9, 2017, at 05:22, Pushkar Jambhlekar  wrote:
> Subject: Minor coding guideline Fix in lusture module

I suspect the patchbot is unhappy with the subject line not containing anything
useful, and not containing the subsystem name. Something like:

staging/lustre/llite: replace "unsigned" with "unsigned int"

> Replacing 'unsigned' with 'unsigned int'  in vvp_pgcache_id.

Remove double space, and reference function names like vvp_pgcache_id().
 
> Checkpath.pl passed.

"checkpatch.pl"

Cheers, Andreas

> Signed-off-by: Pushkar Jambhlekar 
> ---
> drivers/staging/lustre/lustre/llite/vvp_dev.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c 
> b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index 12c129f7e..8d78755 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -381,11 +381,10 @@ int cl_sb_fini(struct super_block *sb)
> #define PGC_DEPTH_SHIFT (32)
> 
> struct vvp_pgcache_id {
> - unsigned vpi_bucket;
> - unsigned vpi_depth;
> - uint32_t vpi_index;
> -
> - unsigned vpi_curdep;
> + unsigned intvpi_bucket;
> + unsigned intvpi_depth;
> + uint32_tvpi_index;
> + unsigned intvpi_curdep;
>   struct lu_object_header *vpi_obj;
> };
> 
> -- 
> 2.7.4
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation









Re: [PATCH] Minor coding guideline Fix in lusture module

2017-03-09 Thread Dilger, Andreas
On Mar 9, 2017, at 05:22, Pushkar Jambhlekar  wrote:
> Subject: Minor coding guideline Fix in lusture module

I suspect the patchbot is unhappy with the subject line not containing anything
useful, and not containing the subsystem name. Something like:

staging/lustre/llite: replace "unsigned" with "unsigned int"

> Replacing 'unsigned' with 'unsigned int'  in vvp_pgcache_id.

Remove double space, and reference function names like vvp_pgcache_id().
 
> Checkpath.pl passed.

"checkpatch.pl"

Cheers, Andreas

> Signed-off-by: Pushkar Jambhlekar 
> ---
> drivers/staging/lustre/lustre/llite/vvp_dev.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c 
> b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> index 12c129f7e..8d78755 100644
> --- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
> +++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
> @@ -381,11 +381,10 @@ int cl_sb_fini(struct super_block *sb)
> #define PGC_DEPTH_SHIFT (32)
> 
> struct vvp_pgcache_id {
> - unsigned vpi_bucket;
> - unsigned vpi_depth;
> - uint32_t vpi_index;
> -
> - unsigned vpi_curdep;
> + unsigned intvpi_bucket;
> + unsigned intvpi_depth;
> + uint32_tvpi_index;
> + unsigned intvpi_curdep;
>   struct lu_object_header *vpi_obj;
> };
> 
> -- 
> 2.7.4
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation









Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()

2017-03-09 Thread NeilBrown
On Thu, Mar 09 2017, Jens Axboe wrote:

> On 03/09/2017 09:32 PM, NeilBrown wrote:
>> 
>> I started looking further at the improvements we can make once
>> generic_make_request is fixed, and realised that I had missed an
>> important detail in this patch.
>> Several places test current->bio_list, and two actually edit the list.
>> With this change, that cannot see the whole lists, so it could cause a
>> regression.
>> 
>> So I've revised the patch to make sure that the entire list of queued
>> bios remains visible, and change the relevant code to look at both
>> the new list and the old list.
>> 
>> Following that there are some patches which make the rescuer thread
>> optional, and then starts removing it from some easy-to-fix places.
>
> Neil, note that the v2 patch is already in Linus tree as of earlier
> today. You need to rebase the series, and if we need fixups on
> top of v2, then that should be done separately and with increased
> urgency.

I had checked linux-next, but not the latest from Linus.
I see it now - thanks!
I'll rebase (and ensure nothing gets mangled)

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()

2017-03-09 Thread NeilBrown
On Thu, Mar 09 2017, Jens Axboe wrote:

> On 03/09/2017 09:32 PM, NeilBrown wrote:
>> 
>> I started looking further at the improvements we can make once
>> generic_make_request is fixed, and realised that I had missed an
>> important detail in this patch.
>> Several places test current->bio_list, and two actually edit the list.
>> With this change, that cannot see the whole lists, so it could cause a
>> regression.
>> 
>> So I've revised the patch to make sure that the entire list of queued
>> bios remains visible, and change the relevant code to look at both
>> the new list and the old list.
>> 
>> Following that there are some patches which make the rescuer thread
>> optional, and then starts removing it from some easy-to-fix places.
>
> Neil, note that the v2 patch is already in Linus tree as of earlier
> today. You need to rebase the series, and if we need fixups on
> top of v2, then that should be done separately and with increased
> urgency.

I had checked linux-next, but not the latest from Linus.
I see it now - thanks!
I'll rebase (and ensure nothing gets mangled)

Thanks,
NeilBrown


signature.asc
Description: PGP signature


Re: [PATCH net, v1] dccp/tcp: fix routing redirect race

2017-03-09 Thread Jonathan Maxwell
On Fri, Mar 10, 2017 at 3:23 PM, Eric Dumazet  wrote:
> On Fri, 2017-03-10 at 14:31 +1100, Jon Maxwell wrote:
>> As Eric Dumazet pointed out this also needs to be fixed in IPv6.
>> v1: Contains the IPv6 patch as well.
>
>> Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
>> Cc: Eric Garver 
>> Cc: Hannes Sowa 
>> Signed-off-by: Jon Maxwell 
>> ---
>>  net/dccp/ipv4.c | 3 ++-
>>  net/ipv4/tcp_ipv4.c | 3 ++-
>>  net/ipv6/tcp_ipv6.c | 8 +---
>
> Hi Jon.
>
> You forgot net/dccp/ipv6.c
>
> dccp_v6_err() has the same issue.
>
>

Thanks Eric,

My bad. I'll fix that and post another patch.


Re: [PATCH net, v1] dccp/tcp: fix routing redirect race

2017-03-09 Thread Jonathan Maxwell
On Fri, Mar 10, 2017 at 3:23 PM, Eric Dumazet  wrote:
> On Fri, 2017-03-10 at 14:31 +1100, Jon Maxwell wrote:
>> As Eric Dumazet pointed out this also needs to be fixed in IPv6.
>> v1: Contains the IPv6 patch as well.
>
>> Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
>> Cc: Eric Garver 
>> Cc: Hannes Sowa 
>> Signed-off-by: Jon Maxwell 
>> ---
>>  net/dccp/ipv4.c | 3 ++-
>>  net/ipv4/tcp_ipv4.c | 3 ++-
>>  net/ipv6/tcp_ipv6.c | 8 +---
>
> Hi Jon.
>
> You forgot net/dccp/ipv6.c
>
> dccp_v6_err() has the same issue.
>
>

Thanks Eric,

My bad. I'll fix that and post another patch.


[PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver

2017-03-09 Thread Steve Longerbeam
Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
 Documentation/devicetree/bindings/media/imx.txt | 74 +
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..3059c06
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,74 @@
+Freescale i.MX Media Video Device
+=
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+};
+
+fim child node
+--
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+specified as . The channel number
+must be 0 or 1. The flags can be
+IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+IRQ_TYPE_EDGE_BOTH, and specify which input
+capture signal edge will trigger the input
+capture event. If an input capture channel is
+specified, the FIM will use this method to
+measure frame intervals instead of via the EOF
+interrupt. The input capture method is much
+preferred over EOF as it is not subject to
+interrupt latency errors. However it requires
+routing the VSYNC or FIELD output signals of
+the camera sensor to one of the i.MX input
+capture pads (SD1_DAT0, SD1_DAT1), which also
+gives up support for SD1.
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
+- reg   : physical base address and length of the register set;
+- clocks   : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+ (the D-PHY clock), video_27m (D-PHY PLL reference
+ clock), and eim_podf;
+- clock-names  : must contain "dphy", "ref", "pix";
+- port@*: five port nodes must exist, containing endpoints
+ connecting to the source and sink devices according to
+ of_graph bindings. The first port is an input port,
+ connecting with a MIPI CSI-2 source, and ports 1
+ through 4 are output ports connecting with parallel
+ bus sink endpoint nodes and correspond to the four
+ MIPI CSI-2 virtual channel outputs.
+
+Optional properties:
+- interrupts   : must contain two level-triggered interrupts,
+ in order: 100 and 101;
-- 
2.7.4



[PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver

2017-03-09 Thread Steve Longerbeam
Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
 Documentation/devicetree/bindings/media/imx.txt | 74 +
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..3059c06
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,74 @@
+Freescale i.MX Media Video Device
+=
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+};
+
+fim child node
+--
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+specified as . The channel number
+must be 0 or 1. The flags can be
+IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+IRQ_TYPE_EDGE_BOTH, and specify which input
+capture signal edge will trigger the input
+capture event. If an input capture channel is
+specified, the FIM will use this method to
+measure frame intervals instead of via the EOF
+interrupt. The input capture method is much
+preferred over EOF as it is not subject to
+interrupt latency errors. However it requires
+routing the VSYNC or FIELD output signals of
+the camera sensor to one of the i.MX input
+capture pads (SD1_DAT0, SD1_DAT1), which also
+gives up support for SD1.
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
+- reg   : physical base address and length of the register set;
+- clocks   : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+ (the D-PHY clock), video_27m (D-PHY PLL reference
+ clock), and eim_podf;
+- clock-names  : must contain "dphy", "ref", "pix";
+- port@*: five port nodes must exist, containing endpoints
+ connecting to the source and sink devices according to
+ of_graph bindings. The first port is an input port,
+ connecting with a MIPI CSI-2 source, and ports 1
+ through 4 are output ports connecting with parallel
+ bus sink endpoint nodes and correspond to the four
+ MIPI CSI-2 virtual channel outputs.
+
+Optional properties:
+- interrupts   : must contain two level-triggered interrupts,
+ in order: 100 and 101;
-- 
2.7.4



[PATCH v5 04/39] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2017-03-09 Thread Steve Longerbeam
Add to the MIPI CSI2 receiver node: compatible strings,
interrupt sources, and clocks.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..d28a413 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1134,7 +1134,14 @@
};
 
mipi_csi: mipi@021dc000 {
+   compatible = "fsl,imx6-mipi-csi2", 
"snps,dw-mipi-csi2";
reg = <0x021dc000 0x4000>;
+   interrupts = <0 100 0x04>, <0 101 0x04>;
+   clocks = < IMX6QDL_CLK_HSI_TX>,
+< IMX6QDL_CLK_VIDEO_27M>,
+< IMX6QDL_CLK_EIM_PODF>;
+   clock-names = "dphy", "ref", "pix";
+   status = "disabled";
};
 
mipi_dsi: mipi@021e {
-- 
2.7.4



[PATCH v5 04/39] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2017-03-09 Thread Steve Longerbeam
Add to the MIPI CSI2 receiver node: compatible strings,
interrupt sources, and clocks.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..d28a413 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1134,7 +1134,14 @@
};
 
mipi_csi: mipi@021dc000 {
+   compatible = "fsl,imx6-mipi-csi2", 
"snps,dw-mipi-csi2";
reg = <0x021dc000 0x4000>;
+   interrupts = <0 100 0x04>, <0 101 0x04>;
+   clocks = < IMX6QDL_CLK_HSI_TX>,
+< IMX6QDL_CLK_VIDEO_27M>,
+< IMX6QDL_CLK_EIM_PODF>;
+   clock-names = "dphy", "ref", "pix";
+   status = "disabled";
};
 
mipi_dsi: mipi@021e {
-- 
2.7.4



[PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

2017-03-09 Thread Steve Longerbeam
There is a pin conflict with GPIO_6. This pin functions as a power
input pin to the OV5642 camera sensor, but ENET uses it as the h/w
workaround for erratum ERR006687, to wake-up the ARM cores on normal
RX and TX packet done events. So we need to remove the h/w workaround
to support the OV5642. The result is that the CPUidle driver will no
longer allow entering the deep idle states on the sabrelite.

This is a partial revert of

commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
interrupt.")
commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
for ERR006687")

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 8413179..89dce27 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -270,9 +270,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
-   interrupts-extended = < 6 IRQ_TYPE_LEVEL_HIGH>,
- < 0 119 IRQ_TYPE_LEVEL_HIGH>;
-   fsl,err006687-workaround-present;
status = "okay";
 };
 
@@ -373,7 +370,6 @@
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
/* Phy reset */
MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x000b0
-   MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
};
 
-- 
2.7.4



[PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

2017-03-09 Thread Steve Longerbeam
There is a pin conflict with GPIO_6. This pin functions as a power
input pin to the OV5642 camera sensor, but ENET uses it as the h/w
workaround for erratum ERR006687, to wake-up the ARM cores on normal
RX and TX packet done events. So we need to remove the h/w workaround
to support the OV5642. The result is that the CPUidle driver will no
longer allow entering the deep idle states on the sabrelite.

This is a partial revert of

commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
interrupt.")
commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
for ERR006687")

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 8413179..89dce27 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -270,9 +270,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
-   interrupts-extended = < 6 IRQ_TYPE_LEVEL_HIGH>,
- < 0 119 IRQ_TYPE_LEVEL_HIGH>;
-   fsl,err006687-workaround-present;
status = "okay";
 };
 
@@ -373,7 +370,6 @@
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
/* Phy reset */
MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x000b0
-   MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
};
 
-- 
2.7.4



[PATCH v5 06/39] ARM: dts: imx6qdl: add capture-subsystem device

2017-03-09 Thread Steve Longerbeam
Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl.dtsi | 5 +
 arch/arm/boot/dts/imx6q.dtsi  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 8958c4a..a959c76 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -100,6 +100,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index b833b0d..4cc6579 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -206,6 +206,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>, <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>, <_di0>, <_di1>;
-- 
2.7.4



[PATCH v5 06/39] ARM: dts: imx6qdl: add capture-subsystem device

2017-03-09 Thread Steve Longerbeam
Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl.dtsi | 5 +
 arch/arm/boot/dts/imx6q.dtsi  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 8958c4a..a959c76 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -100,6 +100,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index b833b0d..4cc6579 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -206,6 +206,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>, <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>, <_di0>, <_di1>;
-- 
2.7.4



[PATCH v5 12/39] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

2017-03-09 Thread Steve Longerbeam
Add pinctrl groups for both GPT input capture channels.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 21dea5f..1212f82 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -456,6 +456,18 @@
>;
};
 
+   pinctrl_gpt_input_capture0: gptinputcapture0grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1   0x1b0b0
+   >;
+   };
+
+   pinctrl_gpt_input_capture1: gptinputcapture1grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2   0x1b0b0
+   >;
+   };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
-- 
2.7.4



[PATCH v5 12/39] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

2017-03-09 Thread Steve Longerbeam
Add pinctrl groups for both GPT input capture channels.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 21dea5f..1212f82 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -456,6 +456,18 @@
>;
};
 
+   pinctrl_gpt_input_capture0: gptinputcapture0grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1   0x1b0b0
+   >;
+   };
+
+   pinctrl_gpt_input_capture1: gptinputcapture1grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2   0x1b0b0
+   >;
+   };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
-- 
2.7.4



[PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval

2017-03-09 Thread Steve Longerbeam
If the pads on both sides of a link specify a frame interval, then
those frame intervals should match. Create the exported function
v4l2_subdev_link_validate_frame_interval() to verify this. This
function can be called in a subdevice's media_entity_operations
or v4l2_subdev_pad_ops link_validate callbacks.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/v4l2-core/v4l2-subdev.c | 50 +++
 include/media/v4l2-subdev.h   | 10 +++
 2 files changed, 60 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index da78497..7a0f387 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -521,6 +521,25 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
 EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate_default);
 
 static int
+v4l2_subdev_link_validate_get_fi(struct media_pad *pad,
+struct v4l2_subdev_frame_interval *fi)
+{
+   if (is_media_entity_v4l2_subdev(pad->entity)) {
+   struct v4l2_subdev *sd =
+   media_entity_to_v4l2_subdev(pad->entity);
+
+   fi->pad = pad->index;
+   return v4l2_subdev_call(sd, video, g_frame_interval, fi);
+   }
+
+   WARN(pad->entity->function != MEDIA_ENT_F_IO_V4L,
+"Driver bug! Wrong media entity type 0x%08x, entity %s\n",
+pad->entity->function, pad->entity->name);
+
+   return -EINVAL;
+}
+
+static int
 v4l2_subdev_link_validate_get_format(struct media_pad *pad,
 struct v4l2_subdev_format *fmt)
 {
@@ -540,6 +559,37 @@ v4l2_subdev_link_validate_get_format(struct media_pad *pad,
return -EINVAL;
 }
 
+int v4l2_subdev_link_validate_frame_interval(struct media_link *link)
+{
+   struct v4l2_subdev_frame_interval src_fi, sink_fi;
+   unsigned long src_usec, sink_usec;
+   int rval;
+
+   rval = v4l2_subdev_link_validate_get_fi(link->source, _fi);
+   if (rval < 0)
+   return 0;
+
+   rval = v4l2_subdev_link_validate_get_fi(link->sink, _fi);
+   if (rval < 0)
+   return 0;
+
+   if (src_fi.interval.numerator == 0   ||
+   src_fi.interval.denominator == 0 ||
+   sink_fi.interval.numerator == 0  ||
+   sink_fi.interval.denominator == 0)
+   return -EPIPE;
+
+   src_usec = DIV_ROUND_CLOSEST_ULL(
+   (u64)src_fi.interval.numerator * USEC_PER_SEC,
+   src_fi.interval.denominator);
+   sink_usec = DIV_ROUND_CLOSEST_ULL(
+   (u64)sink_fi.interval.numerator * USEC_PER_SEC,
+   sink_fi.interval.denominator);
+
+   return (src_usec != sink_usec) ? -EPIPE : 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate_frame_interval);
+
 int v4l2_subdev_link_validate(struct media_link *link)
 {
struct v4l2_subdev *sink;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 0ab1c5d..60c941d 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -929,6 +929,16 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
  struct v4l2_subdev_format *sink_fmt);
 
 /**
+ * v4l2_subdev_link_validate_frame_interval - validates a media link
+ *
+ * @link: pointer to  media_link
+ *
+ * This function ensures that the frame intervals, if specified by
+ * both the source and sink subdevs of the link, are equal.
+ */
+int v4l2_subdev_link_validate_frame_interval(struct media_link *link);
+
+/**
  * v4l2_subdev_link_validate - validates a media link
  *
  * @link: pointer to  media_link
-- 
2.7.4



[PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval

2017-03-09 Thread Steve Longerbeam
If the pads on both sides of a link specify a frame interval, then
those frame intervals should match. Create the exported function
v4l2_subdev_link_validate_frame_interval() to verify this. This
function can be called in a subdevice's media_entity_operations
or v4l2_subdev_pad_ops link_validate callbacks.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/v4l2-core/v4l2-subdev.c | 50 +++
 include/media/v4l2-subdev.h   | 10 +++
 2 files changed, 60 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index da78497..7a0f387 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -521,6 +521,25 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
 EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate_default);
 
 static int
+v4l2_subdev_link_validate_get_fi(struct media_pad *pad,
+struct v4l2_subdev_frame_interval *fi)
+{
+   if (is_media_entity_v4l2_subdev(pad->entity)) {
+   struct v4l2_subdev *sd =
+   media_entity_to_v4l2_subdev(pad->entity);
+
+   fi->pad = pad->index;
+   return v4l2_subdev_call(sd, video, g_frame_interval, fi);
+   }
+
+   WARN(pad->entity->function != MEDIA_ENT_F_IO_V4L,
+"Driver bug! Wrong media entity type 0x%08x, entity %s\n",
+pad->entity->function, pad->entity->name);
+
+   return -EINVAL;
+}
+
+static int
 v4l2_subdev_link_validate_get_format(struct media_pad *pad,
 struct v4l2_subdev_format *fmt)
 {
@@ -540,6 +559,37 @@ v4l2_subdev_link_validate_get_format(struct media_pad *pad,
return -EINVAL;
 }
 
+int v4l2_subdev_link_validate_frame_interval(struct media_link *link)
+{
+   struct v4l2_subdev_frame_interval src_fi, sink_fi;
+   unsigned long src_usec, sink_usec;
+   int rval;
+
+   rval = v4l2_subdev_link_validate_get_fi(link->source, _fi);
+   if (rval < 0)
+   return 0;
+
+   rval = v4l2_subdev_link_validate_get_fi(link->sink, _fi);
+   if (rval < 0)
+   return 0;
+
+   if (src_fi.interval.numerator == 0   ||
+   src_fi.interval.denominator == 0 ||
+   sink_fi.interval.numerator == 0  ||
+   sink_fi.interval.denominator == 0)
+   return -EPIPE;
+
+   src_usec = DIV_ROUND_CLOSEST_ULL(
+   (u64)src_fi.interval.numerator * USEC_PER_SEC,
+   src_fi.interval.denominator);
+   sink_usec = DIV_ROUND_CLOSEST_ULL(
+   (u64)sink_fi.interval.numerator * USEC_PER_SEC,
+   sink_fi.interval.denominator);
+
+   return (src_usec != sink_usec) ? -EPIPE : 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate_frame_interval);
+
 int v4l2_subdev_link_validate(struct media_link *link)
 {
struct v4l2_subdev *sink;
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 0ab1c5d..60c941d 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -929,6 +929,16 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
  struct v4l2_subdev_format *sink_fmt);
 
 /**
+ * v4l2_subdev_link_validate_frame_interval - validates a media link
+ *
+ * @link: pointer to  media_link
+ *
+ * This function ensures that the frame intervals, if specified by
+ * both the source and sink subdevs of the link, are equal.
+ */
+int v4l2_subdev_link_validate_frame_interval(struct media_link *link);
+
+/**
  * v4l2_subdev_link_validate - validates a media link
  *
  * @link: pointer to  media_link
-- 
2.7.4



[PATCH v5 14/39] add mux and video interface bridge entity functions

2017-03-09 Thread Steve Longerbeam
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 

- renamed MEDIA_ENT_F_MUX to MEDIA_ENT_F_VID_MUX

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/mediactl/media-types.rst | 22 ++
 include/uapi/linux/media.h|  6 ++
 2 files changed, 28 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 3e03dc2..9d908fe 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -298,6 +298,28 @@ Types and flags used to represent the media graph elements
  received on its sink pad and outputs the statistics data on
  its source pad.
 
+-  ..  row 29
+
+   ..  _MEDIA-ENT-F-VID-MUX:
+
+   -  ``MEDIA_ENT_F_VID_MUX``
+
+   - Video multiplexer. An entity capable of multiplexing must have at
+ least two sink pads and one source pad, and must pass the video
+ frame(s) received from the active sink pad to the source pad. Video
+ frame(s) from the inactive sink pads are discarded.
+
+-  ..  row 30
+
+   ..  _MEDIA-ENT-F-VID-IF-BRIDGE:
+
+   -  ``MEDIA_ENT_F_VID_IF_BRIDGE``
+
+   - Video interface bridge. A video interface bridge entity must have at
+ least one sink pad and one source pad. It receives video frame(s) on
+ its sink pad in one bus format (HDMI, eDP, MIPI CSI-2, ...) and
+ converts them and outputs them on its source pad in another bus format
+ (eDP, MIPI CSI-2, parallel, ...).
 
 ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4890787..fac96c6 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -105,6 +105,12 @@ struct media_device_info {
 #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS  (MEDIA_ENT_F_BASE + 0x4006)
 
 /*
+ * Switch and bridge entitites
+ */
+#define MEDIA_ENT_F_VID_MUX(MEDIA_ENT_F_BASE + 0x5001)
+#define MEDIA_ENT_F_VID_IF_BRIDGE  (MEDIA_ENT_F_BASE + 0x5002)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
2.7.4



[PATCH v5 14/39] add mux and video interface bridge entity functions

2017-03-09 Thread Steve Longerbeam
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 

- renamed MEDIA_ENT_F_MUX to MEDIA_ENT_F_VID_MUX

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/mediactl/media-types.rst | 22 ++
 include/uapi/linux/media.h|  6 ++
 2 files changed, 28 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 3e03dc2..9d908fe 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -298,6 +298,28 @@ Types and flags used to represent the media graph elements
  received on its sink pad and outputs the statistics data on
  its source pad.
 
+-  ..  row 29
+
+   ..  _MEDIA-ENT-F-VID-MUX:
+
+   -  ``MEDIA_ENT_F_VID_MUX``
+
+   - Video multiplexer. An entity capable of multiplexing must have at
+ least two sink pads and one source pad, and must pass the video
+ frame(s) received from the active sink pad to the source pad. Video
+ frame(s) from the inactive sink pads are discarded.
+
+-  ..  row 30
+
+   ..  _MEDIA-ENT-F-VID-IF-BRIDGE:
+
+   -  ``MEDIA_ENT_F_VID_IF_BRIDGE``
+
+   - Video interface bridge. A video interface bridge entity must have at
+ least one sink pad and one source pad. It receives video frame(s) on
+ its sink pad in one bus format (HDMI, eDP, MIPI CSI-2, ...) and
+ converts them and outputs them on its source pad in another bus format
+ (eDP, MIPI CSI-2, parallel, ...).
 
 ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4890787..fac96c6 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -105,6 +105,12 @@ struct media_device_info {
 #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS  (MEDIA_ENT_F_BASE + 0x4006)
 
 /*
+ * Switch and bridge entitites
+ */
+#define MEDIA_ENT_F_VID_MUX(MEDIA_ENT_F_BASE + 0x5001)
+#define MEDIA_ENT_F_VID_IF_BRIDGE  (MEDIA_ENT_F_BASE + 0x5002)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
2.7.4



[PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event

2017-03-09 Thread Steve Longerbeam
Add a NEW_FRAME_BEFORE_EOF event to signal that a video capture or
output device has signaled a new frame is ready before a previous
frame has completed reception or transmission. This usually indicates
a DMA read/write channel is having trouble gaining bus access.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
 Documentation/media/videodev2.h.rst.exceptions  | 1 +
 include/uapi/linux/videodev2.h  | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index dc77363..54bc7ae 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -203,6 +203,12 @@ call.
has measured an interval between the reception or transmit
completion of two consecutive frames of video that is outside
the nominal frame interval by some tolerance value.
+* - ``V4L2_EVENT_NEW_FRAME_BEFORE_EOF``
+  - 8
+  - This event is triggered when the video capture or output device
+   has signaled a new frame is ready before a previous frame has
+   completed reception or transmission. This usually indicates a
+   DMA read/write channel is having trouble gaining bus access.
 * - ``V4L2_EVENT_PRIVATE_START``
   - 0x0800
   - Base event number for driver-private events.
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c7d8fad..be6f332 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -460,6 +460,7 @@ replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
 replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
+replace define V4L2_EVENT_NEW_FRAME_BEFORE_EOF event-type
 replace define V4L2_EVENT_PRIVATE_START event-type
 
 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index cf5a0d0..f54a82a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
 #define V4L2_EVENT_FRAME_INTERVAL_ERROR7
+#define V4L2_EVENT_NEW_FRAME_BEFORE_EOF8
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
-- 
2.7.4



[PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event

2017-03-09 Thread Steve Longerbeam
Add a NEW_FRAME_BEFORE_EOF event to signal that a video capture or
output device has signaled a new frame is ready before a previous
frame has completed reception or transmission. This usually indicates
a DMA read/write channel is having trouble gaining bus access.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
 Documentation/media/videodev2.h.rst.exceptions  | 1 +
 include/uapi/linux/videodev2.h  | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index dc77363..54bc7ae 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -203,6 +203,12 @@ call.
has measured an interval between the reception or transmit
completion of two consecutive frames of video that is outside
the nominal frame interval by some tolerance value.
+* - ``V4L2_EVENT_NEW_FRAME_BEFORE_EOF``
+  - 8
+  - This event is triggered when the video capture or output device
+   has signaled a new frame is ready before a previous frame has
+   completed reception or transmission. This usually indicates a
+   DMA read/write channel is having trouble gaining bus access.
 * - ``V4L2_EVENT_PRIVATE_START``
   - 0x0800
   - Base event number for driver-private events.
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index c7d8fad..be6f332 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -460,6 +460,7 @@ replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
 replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
+replace define V4L2_EVENT_NEW_FRAME_BEFORE_EOF event-type
 replace define V4L2_EVENT_PRIVATE_START event-type
 
 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index cf5a0d0..f54a82a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
 #define V4L2_EVENT_FRAME_INTERVAL_ERROR7
+#define V4L2_EVENT_NEW_FRAME_BEFORE_EOF8
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
-- 
2.7.4



Re: [PATCH v4] soc/imx: Add GPCv2 power gating driver

2017-03-09 Thread Andrey Smirnov
On Wed, Mar 8, 2017 at 3:39 AM, Shawn Guo  wrote:
> On Tue, Feb 28, 2017 at 04:09:16PM -0800, Andrey Smirnov wrote:
>> Add code allowing for control of various power domains managed by GPCv2
>
> GPCv2, is it the name used in i.MX7 SoC manual?

No, the manual refers to it as GPC. GPCv2 came from already existing
irqchip driver

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-imx-gpcv2.c?id=refs/tags/v4.11-rc1

Plus, I think, there were a number of LKML patch submission threads
where that IP block was referred to as as GPCv2 by Freescale devs.

>
>> IP block found in i.MX7 series of SoCs. Power domains covered by this
>> patch are:
>>
>> - PCIE PHY
>> - MIPI PHY
>> - USB HSIC PHY
>> - USB OTG1/2 PHY
>>
>> Support for any other power domain controlled by GPC is not present, and
>> can be added at some later point.
>>
>> Testing of this code was done against a PCIe driver.
>>
>> Cc: yurov...@gmail.com
>> Cc: Lucas Stach 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: Fabio Estevam 
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Acked-by: Rob Herring 
>> Signed-off-by: Andrey Smirnov 
>> ---
>>
>> Changes since v3 (see [v3]):
>>
>>   - Minor device tree bindings documentation fixes as per
>>   feedback from Rob Herring
>>   - Collect Acked-by from Rob
>>
>> Changes since v2 (see [v2]):
>>
>>   - Fix a critical bug where incorrect state of a bit was
>>   expected in a busy wait loop (bit set instead of bit
>>   cleared) imx7_gpc_pu_pgc_sw_pxx_req()
>>
>>   - Add missing step (setting of PCR in GPC_PGC_nCTRL) in power
>>   down procedure
>>
>> Changes since v1 (see [v1]):
>>
>>   - Various small DT bindings description fixes as per feedback
>>   from Rob Herring
>>
>>
>> [v1] https://lkml.org/lkml/2017/2/6/554
>> [v2] https://lkml.org/lkml/2017/2/13/489
>> [v3] https://lkml.org/lkml/2017/2/20/338
>>
>>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt|  71 
>>  drivers/soc/imx/Makefile   |   2 +-
>>  drivers/soc/imx/gpcv2.c| 397 
>> +
>>  include/dt-bindings/power/imx7-power.h |  18 +
>
> Please have fsl,imx-gpcv2.txt and imx7-power.h in a separate dt-bindings
> patch, and attach Rob's ACK to it.

OK, will do in v4.

>
>>  4 files changed, 487 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>>  create mode 100644 drivers/soc/imx/gpcv2.c
>>  create mode 100644 include/dt-bindings/power/imx7-power.h
>>
>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt 
>> b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> new file mode 100644
>> index 000..02f45c6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> @@ -0,0 +1,71 @@
>> +Freescale i.MX General Power Controller v2
>> +==
>> +
>> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
>> +Control (PGC) for various power domains.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "fsl,imx7d-gpc"
>> +
>> +- reg: should be register base and length as documented in the
>> +  datasheet
>> +
>> +- interrupts: Should contain GPC interrupt request 1
>> +
>> +Power domains contained within GPC node are generic power domain
>> +providers, documented in
>> +Documentation/devicetree/bindings/power/power_domain.txt, which are
>> +described as subnodes of the power gating controller 'pgc' node,
>> +which, in turn, is expected to contain the following:
>> +
>> +Required properties:
>> +
>> +- reg: Power domain index. Valid values are defined in
>> +  include/dt-bindings/power/imx7-power.h
>> +
>> +- #power-domain-cells: Should be 0
>> +
>> +Optional properties:
>> +
>> +- power-supply: Power supply used to power the domain
>> +
>> +Example:
>> +
>> + gpc: gpc@303a {
>> + compatible = "fsl,imx7d-gpc";
>> + reg = <0x303a 0x1000>;
>> + interrupt-controller;
>> + interrupts = ;
>> + #interrupt-cells = <3>;
>> + interrupt-parent = <>;
>> +
>> + pgc {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pgc_pcie_phy: power-domain@3 {
>> + #power-domain-cells = <0>;
>> +
>> + reg = ;
>> + power-supply = <_1p0d>;
>> + };
>> + };
>> + };
>> +
>> +
>> +Specifying power domain for IP modules
>> +==
>> +
>> +IP cores belonging to a power domain should 

Re: [PATCH v4] soc/imx: Add GPCv2 power gating driver

2017-03-09 Thread Andrey Smirnov
On Wed, Mar 8, 2017 at 3:39 AM, Shawn Guo  wrote:
> On Tue, Feb 28, 2017 at 04:09:16PM -0800, Andrey Smirnov wrote:
>> Add code allowing for control of various power domains managed by GPCv2
>
> GPCv2, is it the name used in i.MX7 SoC manual?

No, the manual refers to it as GPC. GPCv2 came from already existing
irqchip driver

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-imx-gpcv2.c?id=refs/tags/v4.11-rc1

Plus, I think, there were a number of LKML patch submission threads
where that IP block was referred to as as GPCv2 by Freescale devs.

>
>> IP block found in i.MX7 series of SoCs. Power domains covered by this
>> patch are:
>>
>> - PCIE PHY
>> - MIPI PHY
>> - USB HSIC PHY
>> - USB OTG1/2 PHY
>>
>> Support for any other power domain controlled by GPC is not present, and
>> can be added at some later point.
>>
>> Testing of this code was done against a PCIe driver.
>>
>> Cc: yurov...@gmail.com
>> Cc: Lucas Stach 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: Fabio Estevam 
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Acked-by: Rob Herring 
>> Signed-off-by: Andrey Smirnov 
>> ---
>>
>> Changes since v3 (see [v3]):
>>
>>   - Minor device tree bindings documentation fixes as per
>>   feedback from Rob Herring
>>   - Collect Acked-by from Rob
>>
>> Changes since v2 (see [v2]):
>>
>>   - Fix a critical bug where incorrect state of a bit was
>>   expected in a busy wait loop (bit set instead of bit
>>   cleared) imx7_gpc_pu_pgc_sw_pxx_req()
>>
>>   - Add missing step (setting of PCR in GPC_PGC_nCTRL) in power
>>   down procedure
>>
>> Changes since v1 (see [v1]):
>>
>>   - Various small DT bindings description fixes as per feedback
>>   from Rob Herring
>>
>>
>> [v1] https://lkml.org/lkml/2017/2/6/554
>> [v2] https://lkml.org/lkml/2017/2/13/489
>> [v3] https://lkml.org/lkml/2017/2/20/338
>>
>>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt|  71 
>>  drivers/soc/imx/Makefile   |   2 +-
>>  drivers/soc/imx/gpcv2.c| 397 
>> +
>>  include/dt-bindings/power/imx7-power.h |  18 +
>
> Please have fsl,imx-gpcv2.txt and imx7-power.h in a separate dt-bindings
> patch, and attach Rob's ACK to it.

OK, will do in v4.

>
>>  4 files changed, 487 insertions(+), 1 deletion(-)
>>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>>  create mode 100644 drivers/soc/imx/gpcv2.c
>>  create mode 100644 include/dt-bindings/power/imx7-power.h
>>
>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt 
>> b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> new file mode 100644
>> index 000..02f45c6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> @@ -0,0 +1,71 @@
>> +Freescale i.MX General Power Controller v2
>> +==
>> +
>> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
>> +Control (PGC) for various power domains.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "fsl,imx7d-gpc"
>> +
>> +- reg: should be register base and length as documented in the
>> +  datasheet
>> +
>> +- interrupts: Should contain GPC interrupt request 1
>> +
>> +Power domains contained within GPC node are generic power domain
>> +providers, documented in
>> +Documentation/devicetree/bindings/power/power_domain.txt, which are
>> +described as subnodes of the power gating controller 'pgc' node,
>> +which, in turn, is expected to contain the following:
>> +
>> +Required properties:
>> +
>> +- reg: Power domain index. Valid values are defined in
>> +  include/dt-bindings/power/imx7-power.h
>> +
>> +- #power-domain-cells: Should be 0
>> +
>> +Optional properties:
>> +
>> +- power-supply: Power supply used to power the domain
>> +
>> +Example:
>> +
>> + gpc: gpc@303a {
>> + compatible = "fsl,imx7d-gpc";
>> + reg = <0x303a 0x1000>;
>> + interrupt-controller;
>> + interrupts = ;
>> + #interrupt-cells = <3>;
>> + interrupt-parent = <>;
>> +
>> + pgc {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pgc_pcie_phy: power-domain@3 {
>> + #power-domain-cells = <0>;
>> +
>> + reg = ;
>> + power-supply = <_1p0d>;
>> + };
>> + };
>> + };
>> +
>> +
>> +Specifying power domain for IP modules
>> +==
>> +
>> +IP cores belonging to a power domain should contain a 'power-domains'
>> +property that is a phandle for PGC node representing the domain.
>> +
>> +Example of a device that is part of the PCIE_PHY power 

[PATCH v5 13/39] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

2017-03-09 Thread Steve Longerbeam
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.

The ADV7180 power pin is via max7310_b port expander.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 1212f82..a712ff1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -124,6 +124,21 @@
#size-cells = <0>;
reg = <1>;
 
+   adv7180: camera@21 {
+   compatible = "adi,adv7180";
+   reg = <0x21>;
+   powerdown-gpios = <_b 2 
GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <27 0x8>;
+
+   port {
+   adv7180_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   };
+   };
+   };
+
max7310_a: gpio@30 {
compatible = "maxim,max7310";
reg = <0x30>;
@@ -151,6 +166,25 @@
};
 };
 
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <8>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+
+   /* enable frame interval monitor on this port */
+   fim {
+   status = "okay";
+   };
+};
+
  {
assigned-clocks = < IMX6QDL_PLL4_BYPASS_SRC>,
  < IMX6QDL_PLL4_BYPASS>,
@@ -444,6 +478,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x1b0b0
+   MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+   MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC0x1b0b0
+   MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x1b0b0
+   >;
+   };
+
pinctrl_max7310: max7310grp {
fsl,pins = <
MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0
-- 
2.7.4



[PATCH v5 13/39] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

2017-03-09 Thread Steve Longerbeam
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.

The ADV7180 power pin is via max7310_b port expander.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 1212f82..a712ff1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -124,6 +124,21 @@
#size-cells = <0>;
reg = <1>;
 
+   adv7180: camera@21 {
+   compatible = "adi,adv7180";
+   reg = <0x21>;
+   powerdown-gpios = <_b 2 
GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <27 0x8>;
+
+   port {
+   adv7180_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   };
+   };
+   };
+
max7310_a: gpio@30 {
compatible = "maxim,max7310";
reg = <0x30>;
@@ -151,6 +166,25 @@
};
 };
 
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <8>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+
+   /* enable frame interval monitor on this port */
+   fim {
+   status = "okay";
+   };
+};
+
  {
assigned-clocks = < IMX6QDL_PLL4_BYPASS_SRC>,
  < IMX6QDL_PLL4_BYPASS>,
@@ -444,6 +478,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x1b0b0
+   MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+   MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC0x1b0b0
+   MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x1b0b0
+   >;
+   };
+
pinctrl_max7310: max7310grp {
fsl,pins = <
MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0
-- 
2.7.4



[PATCH v5 17/39] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-09 Thread Steve Longerbeam
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/v4l2-core/v4l2-mc.c | 48 +++
 include/media/v4l2-mc.h   | 25 
 2 files changed, 73 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 303980b..09d4d97 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
 }
 EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
 
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   struct media_entity *entity;
+   struct media_graph graph;
+   struct v4l2_subdev *sd;
+   int ret;
+
+   ret = media_graph_walk_init(, mdev);
+   if (ret)
+   return ret;
+
+   media_graph_walk_start(, start_entity);
+
+   while ((entity = media_graph_walk_next())) {
+   if (!is_media_entity_v4l2_subdev(entity))
+   continue;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
+   sd->ctrl_handler,
+   NULL);
+   if (ret)
+   break;
+   }
+
+   media_graph_walk_cleanup();
+   return ret;
+}
+EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
+
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   int ret;
+
+   mutex_lock(>graph_mutex);
+   ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
+   mutex_unlock(>graph_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
+
 /* 
-
  * Pipeline power management
  *
diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
index 2634d9d..9848e77 100644
--- a/include/media/v4l2-mc.h
+++ b/include/media/v4l2-mc.h
@@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
  */
 int v4l_vb2q_enable_media_source(struct vb2_queue *q);
 
+/**
+ * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
+ * subdev entities in a pipeline to
+ * the given video device.
+ * @vfd: the video device
+ * @start_entity: Starting entity
+ */
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity);
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity);
 
 /**
  * v4l2_pipeline_pm_use - Update the use count of an entity
@@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
vb2_queue *q)
return 0;
 }
 
+static inline int __v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
+static inline int v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
 static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
 {
return 0;
-- 
2.7.4



[PATCH v5 17/39] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-09 Thread Steve Longerbeam
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/v4l2-core/v4l2-mc.c | 48 +++
 include/media/v4l2-mc.h   | 25 
 2 files changed, 73 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 303980b..09d4d97 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
 }
 EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
 
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   struct media_entity *entity;
+   struct media_graph graph;
+   struct v4l2_subdev *sd;
+   int ret;
+
+   ret = media_graph_walk_init(, mdev);
+   if (ret)
+   return ret;
+
+   media_graph_walk_start(, start_entity);
+
+   while ((entity = media_graph_walk_next())) {
+   if (!is_media_entity_v4l2_subdev(entity))
+   continue;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
+   sd->ctrl_handler,
+   NULL);
+   if (ret)
+   break;
+   }
+
+   media_graph_walk_cleanup();
+   return ret;
+}
+EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
+
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   int ret;
+
+   mutex_lock(>graph_mutex);
+   ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
+   mutex_unlock(>graph_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
+
 /* 
-
  * Pipeline power management
  *
diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
index 2634d9d..9848e77 100644
--- a/include/media/v4l2-mc.h
+++ b/include/media/v4l2-mc.h
@@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
  */
 int v4l_vb2q_enable_media_source(struct vb2_queue *q);
 
+/**
+ * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
+ * subdev entities in a pipeline to
+ * the given video device.
+ * @vfd: the video device
+ * @start_entity: Starting entity
+ */
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity);
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity);
 
 /**
  * v4l2_pipeline_pm_use - Update the use count of an entity
@@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
vb2_queue *q)
return 0;
 }
 
+static inline int __v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
+static inline int v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
 static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
 {
return 0;
-- 
2.7.4



[PATCH v5 23/39] media: Add i.MX media core driver

2017-03-09 Thread Steve Longerbeam
Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/v4l-drivers/imx.rst   | 560 
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/imx/Kconfig |   6 +
 drivers/staging/media/imx/Makefile|   5 +
 drivers/staging/media/imx/TODO|  17 +
 drivers/staging/media/imx/imx-media-dev.c | 522 +++
 drivers/staging/media/imx/imx-media-fim.c | 471 +
 drivers/staging/media/imx/imx-media-internal-sd.c | 349 ++
 drivers/staging/media/imx/imx-media-of.c  | 267 
 drivers/staging/media/imx/imx-media-utils.c   | 766 ++
 drivers/staging/media/imx/imx-media.h | 303 +
 include/media/imx.h   |  15 +
 include/uapi/linux/v4l2-controls.h|   4 +
 14 files changed, 3288 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/imx.rst
 create mode 100644 drivers/staging/media/imx/Kconfig
 create mode 100644 drivers/staging/media/imx/Makefile
 create mode 100644 drivers/staging/media/imx/TODO
 create mode 100644 drivers/staging/media/imx/imx-media-dev.c
 create mode 100644 drivers/staging/media/imx/imx-media-fim.c
 create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
 create mode 100644 drivers/staging/media/imx/imx-media-of.c
 create mode 100644 drivers/staging/media/imx/imx-media-utils.c
 create mode 100644 drivers/staging/media/imx/imx-media.h
 create mode 100644 include/media/imx.h

diff --git a/Documentation/media/v4l-drivers/imx.rst 
b/Documentation/media/v4l-drivers/imx.rst
new file mode 100644
index 000..443e0d0
--- /dev/null
+++ b/Documentation/media/v4l-drivers/imx.rst
@@ -0,0 +1,560 @@
+i.MX Video Capture Driver
+=
+
+Introduction
+
+
+The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
+handles the flow of image frames to and from capture devices and
+display devices.
+
+For image capture, the IPU contains the following internal subunits:
+
+- Image DMA Controller (IDMAC)
+- Camera Serial Interface (CSI)
+- Image Converter (IC)
+- Sensor Multi-FIFO Controller (SMFC)
+- Image Rotator (IRT)
+- Video De-Interlacing or Combining Block (VDIC)
+
+The IDMAC is the DMA controller for transfer of image frames to and from
+memory. Various dedicated DMA channels exist for both video capture and
+display paths. During transfer, the IDMAC is also capable of vertical
+image flip, 8x8 block transfer (see IRT description), pixel component
+re-ordering (for example UYVY to YUYV) within the same colorspace, and
+even packed <--> planar conversion. It can also perform a simple
+de-interlacing by interleaving even and odd lines during transfer
+(without motion compensation which requires the VDIC).
+
+The CSI is the backend capture unit that interfaces directly with
+camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
+
+The IC handles color-space conversion, resizing (downscaling and
+upscaling), horizontal flip, and 90/270 degree rotation operations.
+
+There are three independent "tasks" within the IC that can carry out
+conversions concurrently: pre-process encoding, pre-process viewfinder,
+and post-processing. Within each task, conversions are split into three
+sections: downsizing section, main section (upsizing, flip, colorspace
+conversion, and graphics plane combining), and rotation section.
+
+The IPU time-shares the IC task operations. The time-slice granularity
+is one burst of eight pixels in the downsizing section, one image line
+in the main processing section, one image frame in the rotation section.
+
+The SMFC is composed of four independent FIFOs that each can transfer
+captured frames from sensors directly to memory concurrently via four
+IDMAC channels.
+
+The IRT carries out 90 and 270 degree image rotation operations. The
+rotation operation is carried out on 8x8 pixel blocks at a time. This
+operation is supported by the IDMAC which handles the 8x8 block transfer
+along with block reordering, in coordination with vertical flip.
+
+The VDIC handles the conversion of interlaced video to progressive, with
+support for different motion compensation modes (low, medium, and high
+motion). The deinterlaced output frames from the VDIC can be sent to the
+IC pre-process viewfinder task for further conversions. The VDIC also
+contains a Combiner that combines two image planes, with alpha blending
+and color keying.
+
+In addition to the IPU internal subunits, there are also two units
+outside the IPU that are also involved in video capture on i.MX:
+
+- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
+  interface. This is a Synopsys DesignWare core.
+- Two video multiplexers for selecting among multiple sensor inputs
+  to send to a 

[PATCH v5 23/39] media: Add i.MX media core driver

2017-03-09 Thread Steve Longerbeam
Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/v4l-drivers/imx.rst   | 560 
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/imx/Kconfig |   6 +
 drivers/staging/media/imx/Makefile|   5 +
 drivers/staging/media/imx/TODO|  17 +
 drivers/staging/media/imx/imx-media-dev.c | 522 +++
 drivers/staging/media/imx/imx-media-fim.c | 471 +
 drivers/staging/media/imx/imx-media-internal-sd.c | 349 ++
 drivers/staging/media/imx/imx-media-of.c  | 267 
 drivers/staging/media/imx/imx-media-utils.c   | 766 ++
 drivers/staging/media/imx/imx-media.h | 303 +
 include/media/imx.h   |  15 +
 include/uapi/linux/v4l2-controls.h|   4 +
 14 files changed, 3288 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/imx.rst
 create mode 100644 drivers/staging/media/imx/Kconfig
 create mode 100644 drivers/staging/media/imx/Makefile
 create mode 100644 drivers/staging/media/imx/TODO
 create mode 100644 drivers/staging/media/imx/imx-media-dev.c
 create mode 100644 drivers/staging/media/imx/imx-media-fim.c
 create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
 create mode 100644 drivers/staging/media/imx/imx-media-of.c
 create mode 100644 drivers/staging/media/imx/imx-media-utils.c
 create mode 100644 drivers/staging/media/imx/imx-media.h
 create mode 100644 include/media/imx.h

diff --git a/Documentation/media/v4l-drivers/imx.rst 
b/Documentation/media/v4l-drivers/imx.rst
new file mode 100644
index 000..443e0d0
--- /dev/null
+++ b/Documentation/media/v4l-drivers/imx.rst
@@ -0,0 +1,560 @@
+i.MX Video Capture Driver
+=
+
+Introduction
+
+
+The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
+handles the flow of image frames to and from capture devices and
+display devices.
+
+For image capture, the IPU contains the following internal subunits:
+
+- Image DMA Controller (IDMAC)
+- Camera Serial Interface (CSI)
+- Image Converter (IC)
+- Sensor Multi-FIFO Controller (SMFC)
+- Image Rotator (IRT)
+- Video De-Interlacing or Combining Block (VDIC)
+
+The IDMAC is the DMA controller for transfer of image frames to and from
+memory. Various dedicated DMA channels exist for both video capture and
+display paths. During transfer, the IDMAC is also capable of vertical
+image flip, 8x8 block transfer (see IRT description), pixel component
+re-ordering (for example UYVY to YUYV) within the same colorspace, and
+even packed <--> planar conversion. It can also perform a simple
+de-interlacing by interleaving even and odd lines during transfer
+(without motion compensation which requires the VDIC).
+
+The CSI is the backend capture unit that interfaces directly with
+camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
+
+The IC handles color-space conversion, resizing (downscaling and
+upscaling), horizontal flip, and 90/270 degree rotation operations.
+
+There are three independent "tasks" within the IC that can carry out
+conversions concurrently: pre-process encoding, pre-process viewfinder,
+and post-processing. Within each task, conversions are split into three
+sections: downsizing section, main section (upsizing, flip, colorspace
+conversion, and graphics plane combining), and rotation section.
+
+The IPU time-shares the IC task operations. The time-slice granularity
+is one burst of eight pixels in the downsizing section, one image line
+in the main processing section, one image frame in the rotation section.
+
+The SMFC is composed of four independent FIFOs that each can transfer
+captured frames from sensors directly to memory concurrently via four
+IDMAC channels.
+
+The IRT carries out 90 and 270 degree image rotation operations. The
+rotation operation is carried out on 8x8 pixel blocks at a time. This
+operation is supported by the IDMAC which handles the 8x8 block transfer
+along with block reordering, in coordination with vertical flip.
+
+The VDIC handles the conversion of interlaced video to progressive, with
+support for different motion compensation modes (low, medium, and high
+motion). The deinterlaced output frames from the VDIC can be sent to the
+IC pre-process viewfinder task for further conversions. The VDIC also
+contains a Combiner that combines two image planes, with alpha blending
+and color keying.
+
+In addition to the IPU internal subunits, there are also two units
+outside the IPU that are also involved in video capture on i.MX:
+
+- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
+  interface. This is a Synopsys DesignWare core.
+- Two video multiplexers for selecting among multiple sensor inputs
+  to send to a CSI.
+
+For more info, refer 

  1   2   3   4   5   6   7   8   9   10   >