[PATCH] stmmac: ipq806x: Return error values instead of pointers

[Stephen Boyd]

Typically we return error pointers when we want to use those
pointers in the non-error case, but this function is just
returning error pointers or NULL for success. Change the style to
plain int to follow normal kernel coding styles.

Cc: Joachim Eastwood 
Signed-off-by: Stephen Boyd 
---
 .../net/ethernet/stmicro/stmmac/dwmac-ipq806x.c| 24 ++
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
index 82de68b1a452..36d3355f2fb0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
@@ -198,19 +198,19 @@ static int ipq806x_gmac_set_speed(struct ipq806x_gmac 
*gmac, unsigned int speed)
return 0;
 }
 
-static void *ipq806x_gmac_of_parse(struct ipq806x_gmac *gmac)
+static int ipq806x_gmac_of_parse(struct ipq806x_gmac *gmac)
 {
struct device *dev = >pdev->dev;
 
gmac->phy_mode = of_get_phy_mode(dev->of_node);
if (gmac->phy_mode < 0) {
dev_err(dev, "missing phy mode property\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
if (of_property_read_u32(dev->of_node, "qcom,id", >id) < 0) {
dev_err(dev, "missing qcom id property\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
/* The GMACs are called 1 to 4 in the documentation, but to simplify the
@@ -219,13 +219,13 @@ static void *ipq806x_gmac_of_parse(struct ipq806x_gmac 
*gmac)
 */
if (gmac->id < 0 || gmac->id > 3) {
dev_err(dev, "invalid gmac id\n");
-   return ERR_PTR(-EINVAL);
+   return -EINVAL;
}
 
gmac->core_clk = devm_clk_get(dev, "stmmaceth");
if (IS_ERR(gmac->core_clk)) {
dev_err(dev, "missing stmmaceth clk property\n");
-   return gmac->core_clk;
+   return PTR_ERR(gmac->core_clk);
}
clk_set_rate(gmac->core_clk, 26600);
 
@@ -234,18 +234,16 @@ static void *ipq806x_gmac_of_parse(struct ipq806x_gmac 
*gmac)
   "qcom,nss-common");
if (IS_ERR(gmac->nss_common)) {
dev_err(dev, "missing nss-common node\n");
-   return gmac->nss_common;
+   return PTR_ERR(gmac->nss_common);
}
 
/* Setup the register map for the qsgmii csr registers */
gmac->qsgmii_csr = syscon_regmap_lookup_by_phandle(dev->of_node,
   "qcom,qsgmii-csr");
-   if (IS_ERR(gmac->qsgmii_csr)) {
+   if (IS_ERR(gmac->qsgmii_csr))
dev_err(dev, "missing qsgmii-csr node\n");
-   return gmac->qsgmii_csr;
-   }
 
-   return NULL;
+   return PTR_ERR_OR_ZERO(gmac->qsgmii_csr);
 }
 
 static void ipq806x_gmac_fix_mac_speed(void *priv, unsigned int speed)
@@ -262,7 +260,7 @@ static int ipq806x_gmac_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct ipq806x_gmac *gmac;
int val;
-   void *err;
+   int err;
 
val = stmmac_get_platform_resources(pdev, _res);
if (val)
@@ -279,9 +277,9 @@ static int ipq806x_gmac_probe(struct platform_device *pdev)
gmac->pdev = pdev;
 
err = ipq806x_gmac_of_parse(gmac);
-   if (IS_ERR(err)) {
+   if (err) {
dev_err(dev, "device tree parsing error\n");
-   return PTR_ERR(err);
+   return err;
}
 
regmap_write(gmac->qsgmii_csr, QSGMII_PCS_CAL_LCKDT_CTL,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: mediatek: Use current HW pointer for pointer callback

[Koro Chen]

Previously we recorded "last interrupt position" and used it in
pointer callback. This is not correct implementation, and it causes
underruns when user space monitors buffer level to decide when to
send next data chunk in low latency application.

Remove position recording in IRQ handler and also hw_ptr in
struct mtk_afe_memif used to record that, and let pointer callback
reports current HW pointer instead.

Signed-off-by: Koro Chen 
---
 sound/soc/mediatek/mtk-afe-common.h |1 -
 sound/soc/mediatek/mtk-afe-pcm.c|   22 +++---
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/sound/soc/mediatek/mtk-afe-common.h 
b/sound/soc/mediatek/mtk-afe-common.h
index cc4393c..9b1af1a 100644
--- a/sound/soc/mediatek/mtk-afe-common.h
+++ b/sound/soc/mediatek/mtk-afe-common.h
@@ -92,7 +92,6 @@ struct mtk_afe_memif_data {
 struct mtk_afe_memif {
unsigned int phys_buf_addr;
int buffer_size;
-   unsigned int hw_ptr;/* Previous IRQ's HW ptr */
struct snd_pcm_substream *substream;
const struct mtk_afe_memif_data *data;
const struct mtk_afe_irq_data *irqdata;
diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index 7f71343..5399a0e 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -175,8 +175,17 @@ static snd_pcm_uframes_t mtk_afe_pcm_pointer
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct mtk_afe *afe = snd_soc_platform_get_drvdata(rtd->platform);
struct mtk_afe_memif *memif = >memif[rtd->cpu_dai->id];
+   unsigned int hw_ptr;
+   int ret;
+
+   ret = regmap_read(afe->regmap, memif->data->reg_ofs_cur, _ptr);
+   if (ret || hw_ptr == 0) {
+   dev_err(afe->dev, "%s hw_ptr err\n", __func__);
+   hw_ptr = memif->phys_buf_addr;
+   }
 
-   return bytes_to_frames(substream->runtime, memif->hw_ptr);
+   return bytes_to_frames(substream->runtime,
+  hw_ptr - memif->phys_buf_addr);
 }
 
 static const struct snd_pcm_ops mtk_afe_pcm_ops = {
@@ -602,7 +611,6 @@ static int mtk_afe_dais_hw_params(struct snd_pcm_substream 
*substream,
 
memif->phys_buf_addr = substream->runtime->dma_addr;
memif->buffer_size = substream->runtime->dma_bytes;
-   memif->hw_ptr = 0;
 
/* start */
regmap_write(afe->regmap,
@@ -737,7 +745,6 @@ static int mtk_afe_dais_trigger(struct snd_pcm_substream 
*substream, int cmd,
/* and clear pending IRQ */
regmap_write(afe->regmap, AFE_IRQ_CLR,
 1 << memif->data->irq_clr_shift);
-   memif->hw_ptr = 0;
return 0;
default:
return -EINVAL;
@@ -1081,7 +1088,7 @@ static const struct regmap_config mtk_afe_regmap_config = 
{
 static irqreturn_t mtk_afe_irq_handler(int irq, void *dev_id)
 {
struct mtk_afe *afe = dev_id;
-   unsigned int reg_value, hw_ptr;
+   unsigned int reg_value;
int i, ret;
 
ret = regmap_read(afe->regmap, AFE_IRQ_STATUS, _value);
@@ -1097,13 +1104,6 @@ static irqreturn_t mtk_afe_irq_handler(int irq, void 
*dev_id)
if (!(reg_value & (1 << memif->data->irq_clr_shift)))
continue;
 
-   ret = regmap_read(afe->regmap, memif->data->reg_ofs_cur,
- _ptr);
-   if (ret || hw_ptr == 0) {
-   dev_err(afe->dev, "%s hw_ptr err\n", __func__);
-   hw_ptr = memif->phys_buf_addr;
-   }
-   memif->hw_ptr = hw_ptr - memif->phys_buf_addr;
snd_pcm_period_elapsed(memif->substream);
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/4] EDAC: add DDR4 flag

[Anaczkowski, Lukasz]

-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de] 
Sent: Wednesday, December 2, 2015 8:28 PM
To: Chrzaniuk, Hubert 
Cc: Anaczkowski, Lukasz ; 
mche...@osg.samsung.com; dougthomp...@xmission.com; linux-e...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Snow, Jim M 
Subject: Re: [PATCH 1/4] EDAC: add DDR4 flag

> On Wed, Dec 02, 2015 at 04:38:29PM +0100, Hubert Chrzaniuk wrote:
>> Signed-off-by: Jim Snow 
>> Signed-off-by: Lukasz Anaczkowski 
>> Signed-off-by: Hubert Chrzaniuk 
>
> How am I to understand this SoB chain?
>
> Jim wrote it, Lukasz did something to it and Hubert sends it?

Well, although it may sound strange, yeah this is exactly the case, since
EDAC for Knights Landing has been for a while in our private branch.

Is this sort of an issue or just curiosity?

Thanks,
Lukasz
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v2 1/1] atm: solos-pci: Replace simple_strtol by kstrtoint

[LABBE Corentin]

On Wed, Dec 02, 2015 at 05:02:19PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/2/2015 3:54 PM, LABBE Corentin wrote:
> 
> > The simple_strtol function is obsolete.
> > This patch replace it by kstrtoint.
> > This will simplify code, since some error case not handled by
> > simple_strtol are handled by kstrtoint.
> >
> > Signed-off-by: LABBE Corentin 
> > ---
> >   drivers/atm/solos-pci.c | 28 +++-
> >   1 file changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> > index 3d7fb65..f944d75 100644
> > --- a/drivers/atm/solos-pci.c
> > +++ b/drivers/atm/solos-pci.c
> > @@ -347,8 +347,8 @@ static char *next_string(struct sk_buff *skb)
> >*/
> >   static int process_status(struct solos_card *card, int port, struct 
> > sk_buff *skb)
> >   {
> > -   char *str, *end, *state_str, *snr, *attn;
> > -   int ver, rate_up, rate_down;
> > +   char *str, *state_str, *snr, *attn;
> > +   int ver, rate_up, rate_down, err;
> >
> > if (!card->atmdev[port])
> > return -ENODEV;
> > @@ -357,11 +357,11 @@ static int process_status(struct solos_card *card, 
> > int port, struct sk_buff *skb
> > if (!str)
> > return -EIO;
> >
> > -   ver = simple_strtol(str, NULL, 10);
> > -   if (ver < 1) {
> > +   err = kstrtoint(str, 10, );
> > +   if (ver < 1 || err) {
> 
> Is 'ver' initialized in case of error? If not, you have to check 'err' 
> first.

Hello

Whatever if ver is initialized, since the conditional is an or, the test will 
always be true with the err value.
Anyway I will send an updated version.

Regards

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Improve Atheros ethernet driver not to do order 4 GFP_ATOMIC allocation

[Pavel Machek]

On Wed 2015-12-02 22:43:31, Chris Snook wrote:
> On Tue, Dec 1, 2015 at 12:35 PM David Miller  wrote:
> 
> > From: Michal Hocko 
> > Date: Mon, 30 Nov 2015 14:21:29 +0100
> >
> > > On Sat 28-11-15 15:51:13, Pavel Machek wrote:
> > >>
> > >> atl1c driver is doing order-4 allocation with GFP_ATOMIC
> > >> priority. That often breaks  networking after resume. Switch to
> > >> GFP_KERNEL. Still not ideal, but should be significantly better.
> > >
> > > It is not clear why GFP_KERNEL can replace GFP_ATOMIC safely neither
> > > from the changelog nor from the patch context.
> >
> > Earlier in the function we do a GFP_KERNEL kmalloc so:
> >
> > ¯\_(ツ)_/¯
> >
> > It should be fine.
> >
> 
> AFAICT, the people who benefit from GFP_ATOMIC are the people running all
> their storage over NFS/iSCSI who are suspending their machines while
> they're so busy they don't have any clean order 4 pagecache to drop, and
> want the machine to panic rather than hang. The people who benefit
>from

iSCSI on machine that suspends... is that a joke or complicated way of
saying that noone benefits? And code uses... both GFP_ATOMIC and
GFP_KERNEL so that both sides are equally unhappy? :-).

Do you want to test the patch, update the subject line and send it to
Davem, or should I do it?

Do you see a way to split the allocation? Not even order 4 GFP_KERNEL
allocation is a nice thing to do...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Domain faults when CONFIG_CPU_SW_DOMAIN_PAN is enabled

[Peter Rosin]

Hi!

If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get the
following (or very similar) on boot.

Cheers,
Peter

Unhandled fault: page domain fault (0x81b) at 0x00086578
pgd = c281
[00086578] *pgd=22819831, *pte=224fe34f, *ppte=224fe83f
Internal error: : 81b [#1] ARM
Modules linked in:
CPU: 0 PID: 907 Comm: ntpd Not tainted 4.3.0+ #29
Hardware name: Atmel SAMA5
task: c398dac0 ti: c2804000 task.ti: c2804000
PC is at memcpy+0x50/0x330
LR is at 0x1
pc : []    lr : [<0001>]    psr: 80070013
sp : c2805ed4  ip : 0007  fp : 000d3808
r10:   r9 : 0080  r8 : 0001
r7 : 0010  r6 : 0010  r5 : 003f7374  r4 : 
r3 : 0002  r2 : ffe0  r1 : c2805f38  r0 : 00086578
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c53c7d  Table: 22810059  DAC: 0051
Process ntpd (pid: 907, stack limit = 0xc2804208)
Stack: (0xc2805ed4 to 0xc2806000)
5ec0:   c2804000 
5ee0: c2805f18 00086578 00086578 c01e76c4 c2819218 c2ff3b74 000d4344 00086578
5f00:  0051 007c c0010224 c2804000 c004c988 0002 
5f20: 003f7374 0010 0010 0001 0007 0001 01f4 565ff060
5f40: 000183ef 2710      
5f60:        
5f80:       000d3968 0005e38f
5fa0: 000d4344 c0010060 000d3968 0005e38f 00086578   0001
5fc0: 000d3968 0005e38f 000d4344 007c 000d3814 0001 000d4338 000d3808
5fe0: 00081e7c bec558b4 00026d3d b6d09126 0030 00086578 009e3675 2a090bb6
[] (memcpy) from [] (__copy_to_user_memcpy+0x138/0x17c)
[] (__copy_to_user_memcpy) from [] (SyS_adjtimex+0xd4/0xf0)
[] (SyS_adjtimex) from [] (ret_fast_syscall+0x0/0x3c)
Code: f5d1f05c f5d1f07c e8b151f8 e2522020 (e8a051f8)
---[ end trace 04981945a3df2e5e ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: qcom: common: check for failure

[Stephen Boyd]

On 12/01, Sudip Mukherjee wrote:
> We were not checking the return from devm_add_action() which can fail.
> 
> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/clk/qcom/common.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index c112eba..3541a9a 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -213,7 +213,10 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>   if (ret)
>   return ret;
>  
> - devm_add_action(dev, qcom_cc_del_clk_provider, pdev->dev.of_node);
> + ret = devm_add_action(dev, qcom_cc_del_clk_provider,
> +   pdev->dev.of_node);
> + if (ret)
> + return ret;

So now we don't remove the clk provider on allocation failure?
Confused.

>  
>   reset = >reset;
>   reset->rcdev.of_node = dev->of_node;
> @@ -236,8 +239,12 @@ int qcom_cc_really_probe(struct platform_device *pdev,
>   return ret;
>   }
>  
> - devm_add_action(dev, qcom_cc_gdsc_unregister, dev);
> -
> + ret = devm_add_action(dev, qcom_cc_gdsc_unregister, dev);
> + if (ret) {
> + if (desc->gdscs && desc->num_gdscs)
> + gdsc_unregister(dev);
> + return ret;
> + }
>  
>   return 0;
>  }

You seem to have missed the reset devm action. Why?

Also, I wonder if we could have devm_add_action() or some other
new devm_add_action() wrapper that tried to add the action, and
if it failed it ran the action right there and returned the
-ENOMEM? So then we can just have:

ret = devm_add_action_or_do_it(dev, qcom_cc_gdsc_unregister, dev)
if (ret)
return ret;

and we're assured that on the failure path we'll have already
called qcom_cc_gdsc_unregister.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the block tree

[Christoph Hellwig]

On Wed, Dec 02, 2015 at 02:27:40PM -0700, Jens Axboe wrote:
> On 12/02/2015 02:14 PM, Keith Busch wrote:
>> On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
>>> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
>>
>> I forgot about this since I've merged this in my repo to fix:
>>
>> https://lkml.org/lkml/2015/10/26/546
>>
>> That ok, or should we handle this differently?
>
> I think that should make it compile, but the behavior will be a bit odd. If 
> you pass in meta and integrity isn't enabled, you'll get an ENOMEM error. 
> That seems a bit nonsensical.
>
> We could make bio_integrity_alloc() return an error pointer. That way we 
> could retain the ifdefs in the bip code, and not let it spread to drivers.

This looks reasonable to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] clk: sunxi: pll2: Fix clock running too fast

[Stephen Boyd]

On 12/01, Maxime Ripard wrote:
> Contrary to what the datasheet says, the pre divider doesn't seem to be
> incremented by one in the PLL2, but just uses the value from the register,
> with 0 being a bypass.
> 
> This fixes the audio playing too fast.
> 
> Since we now have the same pre-divider flags, and the only difference with
> the A10 is the post-divider offset, also remove the structure to just pass
> the offset as an argument.
> 
> Signed-off-by: Maxime Ripard 
> ---

Applied to clk-fixes + I added the Fixes tag.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/7] mm/compaction: redesign compaction: part1

[Joonsoo Kim]

Major changes from v2:
o Split patchset into two parts, one is for replacing compaction
deferring with compaction limit and the other is for changing
scanner activity
o Add some fixes and cleanup for current defer logic
o Fix opposite direction problem in "skip useless pfn when..." patch
o Reuse current defer logic for compaction limit
o Provide proper argument when calling __reset_isolation_suitable()
o Prevent async compaction while compaction limit is activated

Previous cover-letter isn't appropriate for this part1 patchset so
I just append link about it.

https://lkml.org/lkml/2015/8/23/182

New description:
Compaction deferring effectively reduces compaction overhead if
compaction success isn't expected. But, it is implemented that
skipping a number of compaction requests until compaction is re-enabled.
Due to this implementation, unfortunate compaction requestor will get
whole compaction overhead unlike others have zero overhead. And, after
deferring start to work, even if compaction success possibility is
restored, we should skip to compaction in some number of times.

This patch try to solve above problem by using compaction limit.
Instead of imposing compaction overhead to one unfortunate requestor,
compaction limit distributes overhead to all compaction requestors.
All requestors have a chance to migrate some amount of pages and
after limit is exhausted compaction will be stopped. This will fairly
distributes overhead to all compaction requestors. And, because we don't
defer compaction request, someone will succeed to compact as soon as
possible if compaction success possiblility is restored.

I tested this patch on my compaction benchmark and found that high-order
allocation latency is evenly distributed and there is no latency spike
in the situation where compaction success isn't possible.

Following is the result of each high-order allocation latency (ns).
Base vs Limit

9807 failure 8259807 failure 10839
9808 failure 8209808 failure 9762
9809 failure 8279809 failure 8585
9810 failure 3751   9810 failure 14052
9811 failure 8819811 failure 10781
9812 failure 8279812 failure 9906
9813 failure 24474309813 failure 8925
9814 failure 8632   9814 failure 9185
9815 failure 1172   9815 failure 9076
9816 failure 1045   9816 failure 10860
9817 failure 1044   9817 failure 10571
9818 failure 1043   9818 failure 8789
9819 failure 9799819 failure 9086
9820 failure 4338   9820 failure 43681
9821 failure 1001   9821 failure 9361
9822 failure 8759822 failure 15175
9823 failure 8229823 failure 9394
9824 failure 8279824 failure 334341
9825 failure 8299825 failure 15404
9826 failure 8239826 failure 10419
9827 failure 8249827 failure 11375
9828 failure 8279828 failure 9416
9829 failure 8229829 failure 9303
9830 failure 3646   9830 failure 18514
9831 failure 8699831 failure 11064
9832 failure 8209832 failure 9626
9833 failure 8329833 failure 8794
9834 failure 8209834 failure 10576
9835 failure 24509559835 failure 12260
9836 failure 9428   9836 failure 9049
9837 failure 1067   9837 failure 10346
9838 failure 9689838 failure 8793
9839 failure 9849839 failure 8932
9840 failure 4262   9840 failure 18436
9841 failure 9649841 failure 11429
9842 failure 9379842 failure 9433
9843 failure 8289843 failure 8838
9844 failure 8279844 failure 8948
9845 failure 8229845 failure 13017
9846 failure 8279846 failure 10795

As you can see, Base has a latency spike periodically, but,
in Limit, latency is distributed evenly.

This patchset is based on linux-next-20151106 +
"restore COMPACT_CLUSTER_MAX to 32" + "__compact_pgdat() code cleanuup"
which are sent by me today.

Thanks.

Joonsoo Kim (7):
  mm/compaction: skip useless pfn when updating cached pfn
  mm/compaction: remove unused defer_compaction() in compaction.h
  mm/compaction: initialize compact_order_failed to MAX_ORDER
  mm/compaction: update defer counter when allocation is expected to
succeed
  mm/compaction: respect compaction order when updating defer counter
  mm/compaction: introduce migration scan limit
  mm/compaction: replace compaction deferring with compaction limit

 include/linux/compaction.h|   3 -
 include/linux/mmzone.h|   6 +-
 include/trace/events/compaction.h |   7 +-
 mm/compaction.c   | 188 --
 mm/internal.h |   1 +
 mm/page_alloc.c   |   4 +-
 6 files changed, 125 insertions(+), 84 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/7] mm/compaction: initialize compact_order_failed to MAX_ORDER

[Joonsoo Kim]

If compact_order_failed is initialized to 0 and order-9
compaction is continually failed, defer counter will be updated
to activate deferring. Although other defer counters will be properly
updated, compact_order_failed will not be updated because failed order
cannot be lower than compact_order_failed, 0. In this case,
low order compaction such as 2, 3 could be deferred due to
this wrongly initialized compact_order_failed value. This patch
removes this possibility by initializing it to MAX_ORDER.

Signed-off-by: Joonsoo Kim 
---
 mm/page_alloc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d0499ff..7002c66 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5273,6 +5273,9 @@ static void __paginginit free_area_init_core(struct 
pglist_data *pgdat)
zone_seqlock_init(zone);
zone->zone_pgdat = pgdat;
zone_pcp_init(zone);
+#ifdef CONFIG_COMPACTION
+   zone->compact_order_failed = MAX_ORDER;
+#endif
 
/* For bootup, initialized properly in watermark setup */
mod_zone_page_state(zone, NR_ALLOC_BATCH, zone->managed_pages);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3] perf tools: Introduce perf_thread for backtrace

[平松雅巳 / HIRAMATU，MASAMI]

From: Namhyung Kim [mailto:namhy...@kernel.org]
>
>On Thu, Dec 03, 2015 at 12:15:12AM +, 平松雅巳 / HIRAMATU，MASAMI wrote:
>> >From: Namhyung Kim [mailto:namhy...@gmail.com] On Behalf Of Namhyung Kim
>> >
>> >Backtrace is a crucial info for debugging.  And upcoming refcnt
>> >tracking facility also wants to use it.
>>
>> Note that the refcnt backtrace symbol resolution will work at
>> exit. This means that it can not depend on the feature in perf
>> tools itself. (and of course, since the refcnt tries to find unused
>> objects in perf tools at exit, if we use perf_thread, it will
>> detect the objects related to the perf_thread are leaked)
>
>Hmm.. right.
>
>I think we can leave the perf_thread outside of refcnt infrastructure.
>IOW it should be created before refcnt debugging is activated and
>released after refcnt is done.  What do you think?

Would you mean we don't debug the objects related to a perf_thread?
It will mean that you don't debug anything, since perf_thread involves
most of refcnt using objects, like dso, map, map_groups etc. And some
bugs are actually found at where those objects are handled.

I would not like to care about the output quality of the backtrace_symbols.
I only need the top 2-3 addresses of the backtrace buffer, because I have
(eu-)addr2line command to find the actual source code lines from those
addresses :). If you need, I can also provide an address decoder awk/shell
script for that.

Instead, I prefer to avoid complexity on the "debugging feature"(because
it can introduce new bugs,) and make it more robust (e.g. if we failed to
get symbol, just shows the raw address)

BTW, the robustness is a key point for debugging. Please consider the case
that you hit an error on the objects in the perf_thread, it could cause
double fault(segv again) on the same object. That is what I actually don't
want.

Thank you,


>
>Thanks,
>Namhyung
>
>
>>
>> >
>> >So instead of relying on glibc's backtrace_symbols[_fd] which misses
>> >some (static) functions , use our own symbol searching mechanism.  To
>> >do that, add perf_thread global variable to keep its maps and symbols.
>> >
>> >The backtrace output from TUI is changed like below.  (I made a key
>> >action to generate a segfault):
>> >
>> >Before:
>> >  perf: Segmentation fault
>> >   backtrace 
>> >  perf[0x544a8b]
>> >  /usr/lib/libc.so.6(+0x33680)[0x7fc46420b680]
>> >  perf[0x54041b]
>> >  perf(perf_evlist__tui_browse_hists+0x91)[0x5432e1]
>> >  perf(cmd_report+0x1d20)[0x43cb10]
>> >  perf[0x487073]
>> >  perf(main+0x62f)[0x42cb1f]
>> >  /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fc4641f8610]
>> >  perf(_start+0x29)[0x42cc39]
>> >
>> >After:
>> >  perf: Segmentation fault
>> >   backtrace 
>> >  perf_evsel__hists_browse(+0x43b) in perf [0x54066b]
>> >  perf_evlist__tui_browse_hists(+0x91) in perf [0x543531]
>> >  cmd_report(+0x1d20) in perf [0x43cb50]
>> >  run_builtin(+0x53) in perf [0x4870b3]
>> >  main(+0x634) in perf [0x42cb54]
>> >  __libc_start_main(+0xf0) in libc-2.22.so [0x7fea3577c610]
>> >  _start(+0x29) in perf [0x42cc79]
>> >
>> >Cc: Frederic Weisbecker 
>> >Cc: Masami Hiramatsu 
>> >Signed-off-by: Namhyung Kim 
>> >---
>> >v3) check return value of create_perf_thread()
>> >
>> >v2) fallback to glibc's backtrace_symbols_fd() if failed
>> >
>> > tools/perf/perf.c | 10 +++-
>> > tools/perf/ui/tui/setup.c | 31 +--
>> > tools/perf/util/util.c| 63 
>> > +++
>> > tools/perf/util/util.h|  5 
>> > 4 files changed, 106 insertions(+), 3 deletions(-)
>> >
>> >diff --git a/tools/perf/perf.c b/tools/perf/perf.c
>> >index 4bee53c3f796..f27dc5fa9534 100644
>> >--- a/tools/perf/perf.c
>> >+++ b/tools/perf/perf.c
>> >@@ -604,6 +604,11 @@ int main(int argc, const char **argv)
>> > */
>> >pthread__block_sigwinch();
>> >
>> >+   if (create_perf_thread() < 0) {
>> >+   fprintf(stderr, "Failed to reserve information for 
>> >backtrace\n");
>> >+   goto out;
>> >+   }
>> >+
>> >while (1) {
>> >static int done_help;
>> >int was_alias = run_argv(, );
>> >@@ -615,7 +620,7 @@ int main(int argc, const char **argv)
>> >fprintf(stderr, "Expansion of alias '%s' failed; "
>> >"'%s' is not a perf-command\n",
>> >cmd, argv[0]);
>> >-   goto out;
>> >+   goto out_destroy;
>> >}
>> >if (!done_help) {
>> >cmd = argv[0] = help_unknown_cmd(cmd);
>> >@@ -626,6 +631,9 @@ int main(int argc, const char **argv)
>> >
>> >fprintf(stderr, "Failed to run command '%s': %s\n",
>> >cmd, strerror_r(errno, sbuf, sizeof(sbuf)));
>> >+
>> >+out_destroy:
>> >+   destroy_perf_thread();
>> > out:
>> >return 1;
>> > }
>> >diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
>> >index 7dfeba0a91f3..ba0ff1c4e6b7 100644
>> >--- 

[PATCH v3 4/7] mm/compaction: update defer counter when allocation is expected to succeed

[Joonsoo Kim]

It's rather strange that compact_considered and compact_defer_shift aren't
updated but compact_order_failed is updated when allocation is expected
to succeed. Regardless actual allocation success, deferring for current
order will be disabled so it doesn't result in much difference to
compaction behaviour.

Moreover, in the past, there is a gap between expectation for allocation
succeess in compaction and actual success in page allocator. But, now,
this gap would be diminished due to providing classzone_idx and alloc_flags
to watermark check in compaction and changed watermark check criteria
for high-order allocation. Therfore, it's not a big problem to update
defer counter when allocation is expected to succeed. This change
will help to simplify defer logic.

Signed-off-by: Joonsoo Kim 
---
 include/linux/compaction.h |  2 --
 mm/compaction.c| 27 ---
 mm/page_alloc.c|  1 -
 3 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 359b07a..4761611 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -47,8 +47,6 @@ extern unsigned long compaction_suitable(struct zone *zone, 
int order,
int alloc_flags, int classzone_idx);
 
 extern bool compaction_deferred(struct zone *zone, int order);
-extern void compaction_defer_reset(struct zone *zone, int order,
-   bool alloc_success);
 extern bool compaction_restarting(struct zone *zone, int order);
 
 #else
diff --git a/mm/compaction.c b/mm/compaction.c
index f144494..67b8d90 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -158,18 +158,12 @@ bool compaction_deferred(struct zone *zone, int order)
return true;
 }
 
-/*
- * Update defer tracking counters after successful compaction of given order,
- * which means an allocation either succeeded (alloc_success == true) or is
- * expected to succeed.
- */
-void compaction_defer_reset(struct zone *zone, int order,
-   bool alloc_success)
+/* Update defer tracking counters after successful compaction of given order */
+static void compaction_defer_reset(struct zone *zone, int order)
 {
-   if (alloc_success) {
-   zone->compact_considered = 0;
-   zone->compact_defer_shift = 0;
-   }
+   zone->compact_considered = 0;
+   zone->compact_defer_shift = 0;
+
if (order >= zone->compact_order_failed)
zone->compact_order_failed = order + 1;
 
@@ -1568,13 +1562,8 @@ unsigned long try_to_compact_pages(gfp_t gfp_mask, 
unsigned int order,
/* If a normal allocation would succeed, stop compacting */
if (zone_watermark_ok(zone, order, low_wmark_pages(zone),
ac->classzone_idx, alloc_flags)) {
-   /*
-* We think the allocation will succeed in this zone,
-* but it is not certain, hence the false. The caller
-* will repeat this with true if allocation indeed
-* succeeds in this zone.
-*/
-   compaction_defer_reset(zone, order, false);
+   compaction_defer_reset(zone, order);
+
/*
 * It is possible that async compaction aborted due to
 * need_resched() and the watermarks were ok thanks to
@@ -1669,7 +1658,7 @@ static void __compact_pgdat(pg_data_t *pgdat, struct 
compact_control *cc)
 
if (zone_watermark_ok(zone, cc->order,
low_wmark_pages(zone), 0, 0))
-   compaction_defer_reset(zone, cc->order, false);
+   compaction_defer_reset(zone, cc->order);
}
 }
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7002c66..f3605fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2815,7 +2815,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int 
order,
struct zone *zone = page_zone(page);
 
zone->compact_blockskip_flush = false;
-   compaction_defer_reset(zone, order, true);
count_vm_event(COMPACTSUCCESS);
return page;
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 6/7] mm/compaction: introduce migration scan limit

[Joonsoo Kim]

This is preparation step to replace compaction deferring with compaction
limit. Whole reason why we need to replace it will be mentioned in
the following patch.

In this patch, migration_scan_limit is assigned and accounted, but, not
checked to finish. So, there is no functional change.

Currently, amount of migration_scan_limit is chosen to imitate compaction
deferring logic. We can tune it easily if overhead looks insane, but,
it would be further work.
Also, amount of migration_scan_limit is adapted by compact_defer_shift.
More fails increase compact_defer_shift and this will limit compaction
more.

There are two interesting changes. One is that cached pfn is always
updated while limit is activated. Otherwise, we would scan same range
over and over. Second one is that async compaction is skipped while
limit is activated, for algorithm correctness. Until now, even if
failure case, sync compaction continue to work when both scanner is met
so COMPACT_COMPLETE usually happens in sync compaction. But, limit is
applied, sync compaction is finished if limit is exhausted so
COMPACT_COMPLETE usually happens in async compaction. Because we don't
consider async COMPACT_COMPLETE as actual fail while we reset cached
scanner pfn, defer mechanism doesn't work well. And, async compaction
would not be easy to succeed in this case so skipping async compaction
doesn't result in much difference.

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 88 +
 mm/internal.h   |  1 +
 2 files changed, 78 insertions(+), 11 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 1a75a6e..b23f6d9 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -116,6 +116,67 @@ static struct page *pageblock_pfn_to_page(unsigned long 
start_pfn,
 
 #ifdef CONFIG_COMPACTION
 
+/*
+ * order == -1 is expected when compacting via
+ * /proc/sys/vm/compact_memory
+ */
+static inline bool is_via_compact_memory(int order)
+{
+   return order == -1;
+}
+
+#define COMPACT_MIN_SCAN_LIMIT (pageblock_nr_pages)
+
+static bool excess_migration_scan_limit(struct compact_control *cc)
+{
+   /* Disable scan limit for now */
+   return false;
+}
+
+static void set_migration_scan_limit(struct compact_control *cc)
+{
+   struct zone *zone = cc->zone;
+   int order = cc->order;
+   unsigned long limit = zone->managed_pages;
+
+   cc->migration_scan_limit = LONG_MAX;
+   if (is_via_compact_memory(order))
+   return;
+
+   if (order < zone->compact_order_failed)
+   return;
+
+   if (!zone->compact_defer_shift)
+   return;
+
+   /*
+* Do not allow async compaction during limit work. In this case,
+* async compaction would not be easy to succeed and we need to
+* ensure that COMPACT_COMPLETE occurs by sync compaction for
+* algorithm correctness and prevention of async compaction will
+* lead it.
+*/
+   if (cc->mode == MIGRATE_ASYNC) {
+   cc->migration_scan_limit = -1;
+   return;
+   }
+
+   /* Migration scanner usually scans less than 1/4 pages */
+   limit >>= 2;
+
+   /*
+* Deferred compaction restart compaction every 64 compaction
+* attempts and it rescans whole zone range. To imitate it,
+* we set limit to 1/64 of scannable range.
+*/
+   limit >>= 6;
+
+   /* Degradation scan limit according to defer shift */
+   limit >>= zone->compact_defer_shift;
+
+   cc->migration_scan_limit = max(limit, COMPACT_MIN_SCAN_LIMIT);
+}
+
 /* Do not skip compaction more than 64 times */
 #define COMPACT_MAX_DEFER_SHIFT 6
 
@@ -263,10 +324,15 @@ static void update_pageblock_skip(struct compact_control 
*cc,
if (!page)
return;
 
-   if (nr_isolated)
+   /*
+* Always update cached_pfn if compaction has scan_limit,
+* otherwise we would scan same range over and over.
+*/
+   if (cc->migration_scan_limit == LONG_MAX && nr_isolated)
return;
 
-   set_pageblock_skip(page);
+   if (!nr_isolated)
+   set_pageblock_skip(page);
 
/* Update where async and sync compaction should restart */
if (migrate_scanner) {
@@ -822,6 +888,8 @@ isolate_success:
if (locked)
spin_unlock_irqrestore(>lru_lock, flags);
 
+   cc->migration_scan_limit -= nr_scanned;
+
trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn,
nr_scanned, nr_isolated);
 
@@ -1186,15 +1254,6 @@ static isolate_migrate_t isolate_migratepages(struct 
zone *zone,
return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
 }
 
-/*
- * order == -1 is expected when compacting via
- * /proc/sys/vm/compact_memory
- */
-static inline bool is_via_compact_memory(int order)
-{
-   return order == -1;
-}
-
 static int __compact_finished(struct zone 

[PATCH v3 7/7] mm/compaction: replace compaction deferring with compaction limit

[Joonsoo Kim]

Compaction deferring effectively reduces compaction overhead if
compaction success isn't expected. But, it is implemented that
skipping a number of compaction requests until compaction is re-enabled.
Due to this implementation, unfortunate compaction requestor will get
whole compaction overhead unlike others have zero overhead. And, after
deferring start to work, even if compaction success possibility is
restored, we should skip to compaction in some number of times.

This patch try to solve above problem by using compaction limit.
Instead of imposing compaction overhead to one unfortunate requestor,
compaction limit distributes overhead to all compaction requestors.
All requestors have a chance to migrate some amount of pages and
after limit is exhausted compaction will be stopped. This will fairly
distributes overhead to all compaction requestors. And, because we don't
defer compaction request, someone will succeed to compact as soon as
possible if compaction success possiblility is restored.

Following is whole workflow enabled by this change.

- if sync compaction fails, compact_order_failed is set to current order
- if it fails again, compact_defer_shift is adjusted
- with positive compact_defer_shift, migration_scan_limit is assigned and
compaction limit is activated
- if compaction limit is activated, compaction would be stopped when
migration_scan_limit is exhausted
- when success, compact_defer_shift and compact_order_failed is reset and
compaction limit is deactivated
- compact_defer_shift can be grown up to COMPACT_MAX_DEFER_SHIFT

Most of changes are mechanical ones to remove compact_considered which
is not needed now. Note that, after restart, compact_defer_shift is
subtracted by 1 to avoid invoking __reset_isolation_suitable()
repeatedly.

I tested this patch on my compaction benchmark and found that high-order
allocation latency is evenly distributed and there is no latency spike
in the situation where compaction success isn't possible.

Signed-off-by: Joonsoo Kim 
---
 include/linux/mmzone.h|  6 ++---
 include/trace/events/compaction.h |  7 ++
 mm/compaction.c   | 47 +--
 3 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..ebb6400 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -511,11 +511,9 @@ struct zone {
 
 #ifdef CONFIG_COMPACTION
/*
-* On compaction failure, 1idx = zone_idx(zone);
__entry->order = order;
-   __entry->considered = zone->compact_considered;
__entry->defer_shift = zone->compact_defer_shift;
__entry->order_failed = zone->compact_order_failed;
),
 
-   TP_printk("node=%d zone=%-8s order=%d order_failed=%d consider=%u 
limit=%lu",
+   TP_printk("node=%d zone=%-8s order=%d order_failed=%d defer=%u",
__entry->nid,
__print_symbolic(__entry->idx, ZONE_TYPE),
__entry->order,
__entry->order_failed,
-   __entry->considered,
-   1UL << __entry->defer_shift)
+   __entry->defer_shift)
 );
 
 DEFINE_EVENT(mm_compaction_defer_template, mm_compaction_deferred,
diff --git a/mm/compaction.c b/mm/compaction.c
index b23f6d9..f3f9dc0 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -129,8 +129,7 @@ static inline bool is_via_compact_memory(int order)
 
 static bool excess_migration_scan_limit(struct compact_control *cc)
 {
-   /* Disable scan limit for now */
-   return false;
+   return cc->migration_scan_limit < 0 ? true : false;
 }
 
 static void set_migration_scan_limit(struct compact_control *cc)
@@ -143,10 +142,7 @@ static void set_migration_scan_limit(struct 
compact_control *cc)
if (is_via_compact_memory(order))
return;
 
-   if (order < zone->compact_order_failed)
-   return;
-
-   if (!zone->compact_defer_shift)
+   if (!compaction_deferred(zone, order))
return;
 
/*
@@ -188,13 +184,10 @@ static void set_migration_scan_limit(struct 
compact_control *cc)
 static void defer_compaction(struct zone *zone, int order)
 {
if (order < zone->compact_order_failed) {
-   zone->compact_considered = 0;
zone->compact_defer_shift = 0;
zone->compact_order_failed = order;
-   } else {
-   zone->compact_considered = 0;
+   } else
zone->compact_defer_shift++;
-   }
 
if (zone->compact_defer_shift > COMPACT_MAX_DEFER_SHIFT)
zone->compact_defer_shift = COMPACT_MAX_DEFER_SHIFT;
@@ -202,19 +195,13 @@ static void defer_compaction(struct zone *zone, int order)
trace_mm_compaction_defer_compaction(zone, order);
 }
 
-/* Returns true if compaction should be skipped this time */
+/* Returns true if 

[PATCH v3 2/7] mm/compaction: remove unused defer_compaction() in compaction.h

[Joonsoo Kim]

It's not used externally. Remove it in compaction.h.

Signed-off-by: Joonsoo Kim 
---
 include/linux/compaction.h | 1 -
 mm/compaction.c| 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 4cd4ddf..359b07a 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -46,7 +46,6 @@ extern void reset_isolation_suitable(pg_data_t *pgdat);
 extern unsigned long compaction_suitable(struct zone *zone, int order,
int alloc_flags, int classzone_idx);
 
-extern void defer_compaction(struct zone *zone, int order);
 extern bool compaction_deferred(struct zone *zone, int order);
 extern void compaction_defer_reset(struct zone *zone, int order,
bool alloc_success);
diff --git a/mm/compaction.c b/mm/compaction.c
index 564047c..f144494 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -124,7 +124,7 @@ static struct page *pageblock_pfn_to_page(unsigned long 
start_pfn,
  * allocation success. 1 << compact_defer_limit compactions are skipped up
  * to a limit of 1 << COMPACT_MAX_DEFER_SHIFT
  */
-void defer_compaction(struct zone *zone, int order)
+static void defer_compaction(struct zone *zone, int order)
 {
zone->compact_considered = 0;
zone->compact_defer_shift++;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/7] mm/compaction: respect compaction order when updating defer counter

[Joonsoo Kim]

It doesn't make sense that we reset defer counter
in compaction_defer_reset() when compaction request under the order of
compact_order_failed succeed. Fix it.

And, it does make sense that giving enough chance for updated failed
order compaction before deferring. Change it.

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 67b8d90..1a75a6e 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -126,11 +126,14 @@ static struct page *pageblock_pfn_to_page(unsigned long 
start_pfn,
  */
 static void defer_compaction(struct zone *zone, int order)
 {
-   zone->compact_considered = 0;
-   zone->compact_defer_shift++;
-
-   if (order < zone->compact_order_failed)
+   if (order < zone->compact_order_failed) {
+   zone->compact_considered = 0;
+   zone->compact_defer_shift = 0;
zone->compact_order_failed = order;
+   } else {
+   zone->compact_considered = 0;
+   zone->compact_defer_shift++;
+   }
 
if (zone->compact_defer_shift > COMPACT_MAX_DEFER_SHIFT)
zone->compact_defer_shift = COMPACT_MAX_DEFER_SHIFT;
@@ -161,11 +164,11 @@ bool compaction_deferred(struct zone *zone, int order)
 /* Update defer tracking counters after successful compaction of given order */
 static void compaction_defer_reset(struct zone *zone, int order)
 {
-   zone->compact_considered = 0;
-   zone->compact_defer_shift = 0;
-
-   if (order >= zone->compact_order_failed)
+   if (order >= zone->compact_order_failed) {
+   zone->compact_considered = 0;
+   zone->compact_defer_shift = 0;
zone->compact_order_failed = order + 1;
+   }
 
trace_mm_compaction_defer_reset(zone, order);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/7] mm/compaction: skip useless pfn when updating cached pfn

[Joonsoo Kim]

Cached pfn is used to determine the start position of scanner
at next compaction run. Current cached pfn points the skipped pageblock
so we uselessly checks whether pageblock is valid for compaction and
skip-bit is set or not. If we set scanner's cached pfn to next pfn of
skipped pageblock, we don't need to do this check.

This patch moved update_pageblock_skip() to
isolate_(freepages|migratepages). Updating pageblock skip information
isn't relevant to CMA so they are more appropriate place
to update this information.

Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 01b1e5e..564047c 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -256,10 +256,9 @@ void reset_isolation_suitable(pg_data_t *pgdat)
  */
 static void update_pageblock_skip(struct compact_control *cc,
struct page *page, unsigned long nr_isolated,
-   bool migrate_scanner)
+   unsigned long pfn, bool migrate_scanner)
 {
struct zone *zone = cc->zone;
-   unsigned long pfn;
 
if (cc->ignore_skip_hint)
return;
@@ -272,8 +271,6 @@ static void update_pageblock_skip(struct compact_control 
*cc,
 
set_pageblock_skip(page);
 
-   pfn = page_to_pfn(page);
-
/* Update where async and sync compaction should restart */
if (migrate_scanner) {
if (pfn > zone->compact_cached_migrate_pfn[0])
@@ -295,7 +292,7 @@ static inline bool isolation_suitable(struct 
compact_control *cc,
 
 static void update_pageblock_skip(struct compact_control *cc,
struct page *page, unsigned long nr_isolated,
-   bool migrate_scanner)
+   unsigned long pfn, bool migrate_scanner)
 {
 }
 #endif /* CONFIG_COMPACTION */
@@ -527,10 +524,6 @@ isolate_fail:
if (locked)
spin_unlock_irqrestore(>zone->lock, flags);
 
-   /* Update the pageblock-skip if the whole pageblock was scanned */
-   if (blockpfn == end_pfn)
-   update_pageblock_skip(cc, valid_page, total_isolated, false);
-
count_compact_events(COMPACTFREE_SCANNED, nr_scanned);
if (total_isolated)
count_compact_events(COMPACTISOLATED, total_isolated);
@@ -832,13 +825,6 @@ isolate_success:
if (locked)
spin_unlock_irqrestore(>lru_lock, flags);
 
-   /*
-* Update the pageblock-skip information and cached scanner pfn,
-* if the whole pageblock was scanned without isolating any page.
-*/
-   if (low_pfn == end_pfn)
-   update_pageblock_skip(cc, valid_page, nr_isolated, true);
-
trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn,
nr_scanned, nr_isolated);
 
@@ -947,6 +933,7 @@ static void isolate_freepages(struct compact_control *cc)
unsigned long block_end_pfn;/* end of current pageblock */
unsigned long low_pfn;   /* lowest pfn scanner is able to scan */
struct list_head *freelist = >freepages;
+   unsigned long nr_isolated;
 
/*
 * Initialise the free scanner. The starting point is where we last
@@ -998,10 +985,18 @@ static void isolate_freepages(struct compact_control *cc)
continue;
 
/* Found a block suitable for isolating free pages from. */
-   isolate_freepages_block(cc, _start_pfn,
+   nr_isolated = isolate_freepages_block(cc, _start_pfn,
block_end_pfn, freelist, false);
 
/*
+* Update the pageblock-skip if the whole pageblock
+* was scanned
+*/
+   if (isolate_start_pfn == block_end_pfn)
+   update_pageblock_skip(cc, page, nr_isolated,
+   block_start_pfn - pageblock_nr_pages, false);
+
+   /*
 * If we isolated enough freepages, or aborted due to async
 * compaction being contended, terminate the loop.
 * Remember where the free scanner should restart next time,
@@ -1172,6 +1167,14 @@ static isolate_migrate_t isolate_migratepages(struct 
zone *zone,
cc->last_migrated_pfn = isolate_start_pfn;
 
/*
+* Update the pageblock-skip if the whole pageblock
+* was scanned without isolating any page.
+*/
+   if (low_pfn == end_pfn)
+   update_pageblock_skip(cc, page, cc->nr_migratepages,
+   end_pfn, true);
+
+   /*
 * Either we isolated something and proceed with migration. Or
 * we failed and compact_zone should decide if we should
 

[PATCH v5] clk: sunxi: Add CLK_OF_DECLARE support for sun8i-a23-apb0-clk driver

[Chen-Yu Tsai]

The APBS clock on sun9i is the same as the APB0 clock on sun8i. With
sun9i we are supporting the PRCM clocks by using CLK_OF_DECLARE,
instead of through a PRCM mfd device and subdevices for each clock
and reset control. As such we need a CLK_OF_DECLARE version of
the sun8i-a23-apb0-clk driver.

Also, build it for sun9i/A80, and not just for configurations with
MFD_SUN6I_PRCM enabled.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v4:

  - Keep building clk-sun8i-apb0 for SUN6I_MFD_PRCM.

  - Add an error message and comment for when of_io_request_and_map()
fails. of_io_request_and_map() merges a bunch of errors into -EINVAL,
so this might not be the best approach. But I think having an error
message when we know something is wrong (-EBUSY, -ENOMEM) is better.

---
 drivers/clk/sunxi/Makefile |  1 +
 drivers/clk/sunxi/clk-sun8i-apb0.c | 80 --
 2 files changed, 69 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 103efab05ca8..ccf21ba3b6b0 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -15,6 +15,7 @@ obj-y += clk-sun9i-core.o
 obj-y += clk-sun9i-mmc.o
 obj-y += clk-usb.o
 
+obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
 obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
 
 obj-$(CONFIG_MFD_SUN6I_PRCM) += \
diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c 
b/drivers/clk/sunxi/clk-sun8i-apb0.c
index 7ae5d2c2cde1..7ba61103a6f5 100644
--- a/drivers/clk/sunxi/clk-sun8i-apb0.c
+++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
@@ -17,13 +17,77 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+static struct clk *sun8i_a23_apb0_register(struct device_node *node,
+  void __iomem *reg)
+{
+   const char *clk_name = node->name;
+   const char *clk_parent;
+   struct clk *clk;
+   int ret;
+
+   clk_parent = of_clk_get_parent_name(node, 0);
+   if (!clk_parent)
+   return ERR_PTR(-EINVAL);
+
+   of_property_read_string(node, "clock-output-names", _name);
+
+   /* The A23 APB0 clock is a standard 2 bit wide divider clock */
+   clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
+  0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
+   if (IS_ERR(clk))
+   return clk;
+
+   ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (ret)
+   goto err_unregister;
+
+   return clk;
+
+err_unregister:
+   clk_unregister_divider(clk);
+
+   return ERR_PTR(ret);
+}
+
+static void sun8i_a23_apb0_setup(struct device_node *node)
+{
+   void __iomem *reg;
+   struct resource res;
+   struct clk *clk;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+   if (IS_ERR(reg)) {
+   /*
+* This happens with clk nodes instantiated through mfd,
+* as those do not have their resources assigned in the
+* device tree. Do not print an error in this case.
+*/
+   if (PTR_ERR(reg) != -EINVAL)
+   pr_err("Could not get registers for a23-apb0-clk\n");
+
+   return;
+   }
+
+   clk = sun8i_a23_apb0_register(node, reg);
+   if (IS_ERR(clk))
+   goto err_unmap;
+
+   return;
+
+err_unmap:
+   iounmap(reg);
+   of_address_to_resource(node, 0, );
+   release_mem_region(res.start, resource_size());
+}
+CLK_OF_DECLARE(sun8i_a23_apb0, "allwinner,sun8i-a23-apb0-clk",
+  sun8i_a23_apb0_setup);
+
 static int sun8i_a23_apb0_clk_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
-   const char *clk_name = np->name;
-   const char *clk_parent;
struct resource *r;
void __iomem *reg;
struct clk *clk;
@@ -33,19 +97,11 @@ static int sun8i_a23_apb0_clk_probe(struct platform_device 
*pdev)
if (IS_ERR(reg))
return PTR_ERR(reg);
 
-   clk_parent = of_clk_get_parent_name(np, 0);
-   if (!clk_parent)
-   return -EINVAL;
-
-   of_property_read_string(np, "clock-output-names", _name);
-
-   /* The A23 APB0 clock is a standard 2 bit wide divider clock */
-   clk = clk_register_divider(>dev, clk_name, clk_parent, 0, reg,
-  0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
+   clk = sun8i_a23_apb0_register(np, reg);
if (IS_ERR(clk))
return PTR_ERR(clk);
 
-   return of_clk_add_provider(np, of_clk_src_simple_get, clk);
+   return 0;
 }
 
 static const struct of_device_id sun8i_a23_apb0_clk_dt_ids[] = {
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] mm/hugetlb resv map memory leak for placeholder entries

[Hillf Danton]

> 
> Dmitry Vyukov reported the following memory leak
> 
> unreferenced object 0x88002eaafd88 (size 32):
>   comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s)
>   hex dump (first 32 bytes):
> 28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff  (.Nc(.Nc
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [< inline >] kmalloc include/linux/slab.h:458
> [] region_chg+0x2d4/0x6b0 mm/hugetlb.c:398
> [] __vma_reservation_common+0x2c3/0x390 
> mm/hugetlb.c:1791
> [< inline >] vma_needs_reservation mm/hugetlb.c:1813
> [] alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845
> [< inline >] hugetlb_no_page mm/hugetlb.c:3543
> [] hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717
> [] follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880
> [] __get_user_pages+0x542/0xf30 mm/gup.c:497
> [] populate_vma_page_range+0xde/0x110 mm/gup.c:919
> [] __mm_populate+0x1c7/0x310 mm/gup.c:969
> [] do_mlock+0x291/0x360 mm/mlock.c:637
> [< inline >] SYSC_mlock2 mm/mlock.c:658
> [] SyS_mlock2+0x4b/0x70 mm/mlock.c:648
> 
> Dmitry identified a potential memory leak in the routine region_chg,
> where a region descriptor is not free'ed on an error path.
> 
> However, the root cause for the above memory leak resides in region_del.
> In this specific case, a "placeholder" entry is created in region_chg.  The
> associated page allocation fails, and the placeholder entry is left in the
> reserve map.  This is "by design" as the entry should be deleted when the
> map is released.  The bug is in the region_del routine which is used to
> delete entries within a specific range (and when the map is released).
> region_del did not handle the case where a placeholder entry exactly matched
> the start of the range range to be deleted.  In this case, the entry would
> not be deleted and leaked.  The fix is to take these special placeholder
> entries into account in region_del.
> 
> The region_chg error path leak is also fixed.
> 
> V2: The original version of the patch did not correctly handle placeholder
> entries before the range to be deleted.  The new check is more specific
> and only matches placeholders at the start of range.
> 
> Fixes: feba16e25a57 ("add region_del() to delete a specific range of entries")
> Cc: sta...@vger.kernel.org [4.3]
> Signed-off-by: Mike Kravetz 
> Reported-by: Dmitry Vyukov 
> ---

Acked-by: Hillf Danton 

>  mm/hugetlb.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 1101ccd94..c895ab9 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -372,8 +372,10 @@ retry_locked:
>   spin_unlock(>lock);
> 
>   trg = kmalloc(sizeof(*trg), GFP_KERNEL);
> - if (!trg)
> + if (!trg) {
> + kfree(nrg);
>   return -ENOMEM;
> + }
> 
>   spin_lock(>lock);
>   list_add(>link, >region_cache);
> @@ -483,8 +485,16 @@ static long region_del(struct resv_map *resv, long f, 
> long t)
>  retry:
>   spin_lock(>lock);
>   list_for_each_entry_safe(rg, trg, head, link) {
> - if (rg->to <= f)
> + /*
> +  * Skip regions before the range to be deleted.  file_region
> +  * ranges are normally of the form [from, to).  However, there
> +  * may be a "placeholder" entry in the map which is of the form
> +  * (from, to) with from == to.  Check for placeholder entries
> +  * at the beginning of the range to be deleted.
> +  */
> + if (rg->to <= f && (rg->to != rg->from || rg->to != f))
>   continue;
> +
>   if (rg->from >= t)
>   break;
> 
> --
> 2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Tian, Kevin]

> From: Tian, Kevin
> Sent: Friday, November 20, 2015 4:36 PM
> 
> >
> > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > > > can feed it into the vnc server.  The vfio framebuffer region is meant
> > > > to support this use case.
> > >
> > > what's the format requirement on that framebuffer? If you are familiar
> > > with Intel Graphics, there's a so-called tiling feature applied on frame
> > > buffer so it can't be used as a raw input to vnc server. w/o opengl you
> > > need do some conversion on CPU first.
> >
> > Yes, that conversion needs to happen, qemu can't deal with tiled
> > graphics.  Anything which pixman can handle will work.  Prefered would
> > be PIXMAN_x8r8g8b8 (aka DRM_FORMAT_XRGB on little endian host) which
> > is the format used by the vnc server (and other places in qemu)
> > internally.

Now the format is reported based on guest setting. Some agent needs to
do format conversion in user space.

> >
> > qemu can also use the opengl texture for the guest fb, then fetch the
> > data with glReadPixels().  Which will probably do exactly the same
> > conversion.  But it'll add a opengl dependency to the non-opengl
> > rendering path in qemu, would be nice if we can avoid that.
> >
> > While being at it:  When importing a dma-buf with a tiled framebuffer
> > into opengl (via eglCreateImageKHR + EGL_LINUX_DMA_BUF_EXT) I suspect we
> > have to pass in the tile size as attribute to make it work.  Is that
> > correct?
> >
> 
> I'd guess so, but need double confirm later when reaching that level of 
> detail.
> some homework on dma-buf is required first. :-)
> 

btw some questions here:

for non-gl and gl rendering in Qemu, are they based on dma-buf already?

once we can export guest framebuffer in dma-buf, is there additional work
required or just straightforward to integrate with SPICE?

Thanks
Kevin
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Non-ascii mantainers

[Michal Suchanek]

On 1 December 2015 at 21:13, Andreas Mohr  wrote:
> Hi,
>
>> I don't really care if the maintainers are encoded or whatever.
>> However, neither get_maintainers nor git format-patch encodes them and
>> the listserver rejects them when not encoded.
>
> "neither ... nor" - IMHO transcoding should always be done at exactly *one* 
> layer
> transition (namely prior to entering the layer which might happen to be
> using non-encoded same-char values as used by payload data as control chars,
> or which might happen to have a "reduced" encoding only requirement [think 
> 7bit vs. 8bit],
> and only there, and of course also correctly [transcodes full set of
> control chars, and properly]). ;)
>
> So, since git-format-patch (according to git-format-patch(1)) itself
> declares that it does "Prepare patches for e-mail submission",
> it would seem that format-patch would definitely need to provide
> readily submittable content i.e.
> support submitting (i.e., generating) such content in *fully compatible* 
> format
> (maybe it would not need to generate this as MIME encoding always
> - since there might be different encoding technologies to be chosen -
> but at least it should offer an encoding cmdline option,
> with this option then definitely defaulting to the mainstream choice, 
> probably MIME).
> IOW, I would consider this to be a git-format-patch "missing crucial i18n 
> support" bug
> (a bug for this should probably be filed).
>
> (and, due to my reasoning above, transcoding would *not* be the job of 
> get_maintainers)
>

The transcoding would be normally the job of a MUA which is git
format-patch here. If it were really required, that is.

I am not sure what exactly is the position of the SMTP standard here
on 8bit headers. However, as with all RFCs it's suggested that you are
strict in what you send and lenient in what you accept. Here git
format-patch can be held responsible for lack of interoperability with
7-bit only SMTP servers and the LKML mail server for enforcing 7-bit
only in 2015 when most mail servers are 8-bit transparent.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] mm/compaction: __compact_pgdat() code cleanuup

[Vlastimil Babka]

On 3.12.2015 5:10, Joonsoo Kim wrote:
> This patch uses is_via_compact_memory() to distinguish compaction
> from sysfs or sysctl. And, this patch also reduces indentation
> on compaction_defer_reset() by filtering these cases first
> before checking watermark.
> 
> There is no functional change.
> 
> Acked-by: Yaowei Bai 
> Acked-by: David Rientjes 

Acked-by: Vlastimil Babka 

> Signed-off-by: Joonsoo Kim 
> ---
>  mm/compaction.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index de3e1e7..01b1e5e 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1658,14 +1658,15 @@ static void __compact_pgdat(pg_data_t *pgdat, struct 
> compact_control *cc)
>   !compaction_deferred(zone, cc->order))
>   compact_zone(zone, cc);
>  
> - if (cc->order > 0) {
> - if (zone_watermark_ok(zone, cc->order,
> - low_wmark_pages(zone), 0, 0))
> - compaction_defer_reset(zone, cc->order, false);
> - }
> -
>   VM_BUG_ON(!list_empty(>freepages));
>   VM_BUG_ON(!list_empty(>migratepages));
> +
> + if (is_via_compact_memory(cc->order))
> + continue;
> +
> + if (zone_watermark_ok(zone, cc->order,
> + low_wmark_pages(zone), 0, 0))
> + compaction_defer_reset(zone, cc->order, false);
>   }
>  }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/7] PCI: Add fwnode_handle to pci_sysdata

[Jiang Liu]

On 2015/11/3 5:33, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> This patch adds an fwnode_handle to struct pci_sysdata, which is
> used by the next patch in the series when trying to locate an
> IRQ domain associated with a root PCI bus.
> 
> Signed-off-by: Jake Oshins 
> ---
>  arch/x86/include/asm/pci.h | 13 +
>  include/asm-generic/pci.h  |  4 
>  2 files changed, 17 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 4625943..fb74453 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -20,6 +20,9 @@ struct pci_sysdata {
>  #ifdef CONFIG_X86_64
>   void*iommu; /* IOMMU private data */
>  #endif
> +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> + void*fwnode;/* IRQ domain for MSI assignment */
> +#endif
>  };
>  
>  extern int pci_routeirq;
> @@ -41,6 +44,16 @@ static inline int pci_proc_domain(struct pci_bus *bus)
>  }
>  #endif
>  
> +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> +static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
> +{
> + struct pci_sysdata *sd = bus->sysdata;
> + return sd->fwnode;
> +}
> +
> +#define pci_root_bus_fwnode  _pci_root_bus_fwnode
> +#endif
> +
>  /* Can be used to override the logic in pci_scan_bus for skipping
> already-configured bus numbers - to be used for buggy BIOSes
> or architectures with incomplete PCI setup by the loader */
> diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
> index f24bc51..3fde985 100644
> --- a/include/asm-generic/pci.h
> +++ b/include/asm-generic/pci.h
> @@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev 
> *dev, int channel)
>  #define PCI_DMA_BUS_IS_PHYS  (1)
>  #endif
>  
> +#ifndef pci_root_bus_fwnode
> +#define pci_root_bus_fwnode(bus) ((void)(bus),NULL)
> +#endif
Hi Jakeo,
For x86, all PCI devices share the same MSI controller. But I'm
not sure whether it may have per-bus/per-device MSI controllers on other
archs. If there may be multiple MSI controllers serving PCI devices
under the same PCI root, it would be better to use some thing like
pci_get_msi_fwnode(bus) or similar.
Thanks,
Gerry


> +
>  #endif /* _ASM_GENERIC_PCI_H */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xfstest failure with xfs, dax and v4.4-rc3

[Dave Chinner]

On Wed, Dec 02, 2015 at 10:12:29AM -0500, Jeff Moyer wrote:
> Dave Chinner  writes:
> 
> > On Tue, Dec 01, 2015 at 03:43:46PM -0700, Ross Zwisler wrote:
> >> I'm seeing a new intermittent xfstests failure with v4.4-rc3 using XFS and
> >> DAX.  The test that is failing is generic/083, and it fails about 50% of 
> >> the
> >> time in my setup.  Here's the output:
> >> 
> >> FSTYP -- xfs (debug)
> >> PLATFORM  -- Linux/x86_64 lorwyn 4.4.0-rc3
> >> MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem0p2
> >> MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem0p2
> >> /mnt/xfstests_scratch
> >> 
> >> generic/083 2s ... 2s
>^^^
> >> _check_xfs_filesystem: filesystem on /dev/pmem0p2 is inconsistent (r) (see
> >> /root/xfstests/results//generic/083.full)
> >> Ran: generic/083
> >> Failures: generic/083
> >> Failed 1 of 1 tests
> >
> > $ grep 083  tests/xfs/group
> > 083 dangerous_fuzzers
> > $
> 
> That's great, but Ross reported an issues with *generic*/083.  ;-)
> 
> /me hands Dave more coffee.

Ah, some days I need more coffee than others :/

As it is, that test does not fail on my DAX testing on RAM disks.
ISTR it failing up until recently, though. Yeah:

Last login: Tue Nov 17 08:45:55 2015 from 192.168.1.103
$ cd ~/src/xfstests-dev; sudo mkfs.xfs -f /dev/ram0 ; sudo xfs_admin -U 
generate /dev/ram0 ; sudo MOUNT_OPTIONS="-o dax" ./check -g auto
SECTION   -- xfs
FSTYP -- xfs (debug)
PLATFORM  -- Linux/x86_64 test4 4.3.0-dgc+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch

generic/083 2s ... 1s
_check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (c) (see 
/home/dave/src/xfstests-dev/results//xfs/generic/083.full)
_check_xfs_filesystem: filesystem on /dev/ram1 is inconsistent (r) (see 
/home/dave/src/xfstests-dev/results//xfs/generic/083.full)


But as I ran earlier today when testing the ENOSPC fix:

PLATFORM  -- Linux/x86_64 test4 4.4.0-rc2-dgc+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/ram1
MOUNT_OPTIONS -- -o dax /dev/ram1 /mnt/scratch

generic/083 1s ... 2s


So I'm seeing that the current 4.4-rc2 + my local dev tree patches
appear to have fixed whatever was causing generic/083 to fail
here...

What version of xfsprogs are you using, Ross?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] clk: let of_clk_get_parent_name() fail for invalid clock-indices

[Stephen Boyd]

On 12/03, Masahiro Yamada wrote:
> Currently, of_clk_get_parent_name() returns a wrong parent clock name
> when "clock-indices" property exists and the target index is not
> found in the property.  In this case, NULL should be returned.
> 
> For example,
> 
> oscillator {
> compatible = "myclocktype";
> #clock-cells = <1>;
> clock-indices = <1>, <3>;
> clock-output-names = "clka", "clkb";
> };
> 
> consumer {
> compatible = "myclockconsumer";
> clocks = < 0>, < 1>;
> };
> 
> Currently, of_clk_get_parent_name(consumer_np, 0) returns "clka"
> (and of_clk_get_parent_name(consumer_np, 1) also returns "clka",
> this is correct).   Because the "clock-indices" in the clock parent
> does not contain <0>, of_clk_get_parent_name(consumer_np, 0) should
> return NULL.
> 
> Signed-off-by: Masahiro Yamada 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC

[Masahiro Yamada]

The UART3 is assigned with IRQ 29 for old SoCs, IRQ 177 for new ones,
and PH1-Pro4 is on the boundary.

  PH1-sLD3: UART3 is unavailable
  PH1-LD4, PH1-sLD8: only IRQ 29 is supported
  PH1-Pro4: both IRQ 29 and 177 are supported
  PH1-Pro5, ProXstream2, PH1-LD6b: only IRQ 177 is supported

This SoC can choose either IRQ 29 or IRQ 177, but the former is shared
with another hardware (low speed serial0).  The latter is dedicated
for this hardware and more recommended.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 254642f..bbf3727 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -151,7 +151,7 @@
reg = <0x54006b00 0x40>;
pinctrl-names = "default";
pinctrl-0 = <_uart3>;
-   interrupts = <0 29 4>;
+   interrupts = <0 177 4>;
clocks = <_clk>;
fifo-size = <64>;
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi

[Masahiro Yamada]

UniPhier SoCs (except PH1-sLD3) have several nodes in common.
Factor out them into uniphier-common32.dtsi.  This improves the code
maintainability.

PH1-sLD3 is so old that it has more or less different register maps
than the others.  So, it cannot be included in this refactoring.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-common32.dtsi| 135 +
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++--
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +-
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +-
 6 files changed, 605 insertions(+), 892 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi 
b/arch/arm/boot/dts/uniphier-common32.dtsi
new file mode 100644
index 000..ea9301a
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -0,0 +1,135 @@
+/*
+ * Device Tree Source commonly used by UniPhier ARM SoCs
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   soc: soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   interrupt-parent = <>;
+
+   extbus: extbus {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
+
+   serial0: serial@54006800 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006800 0x40>;
+   interrupts = <0 33 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart0>;
+   clocks = <_clk>;
+   };
+
+   serial1: serial@54006900 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006900 0x40>;
+   interrupts = <0 35 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart1>;
+   clocks = <_clk>;
+   };
+
+   serial2: serial@54006a00 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006a00 0x40>;
+   interrupts = <0 37 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2>;
+   clocks = <_clk>;
+   };
+
+   serial3: serial@54006b00 {
+   compatible = "socionext,uniphier-uart";
+   status = "disabled";
+ 

[PATCH 0/2] ARM: dts: uniphier: clean up DTSIs by factoring the common parts out

[Masahiro Yamada]

Masahiro Yamada (2):
  ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC
  ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi

 arch/arm/boot/dts/uniphier-common32.dtsi| 135 +
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 +
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++--
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +-
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 +
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +-
 6 files changed, 605 insertions(+), 892 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
> On 03/12/15 10:39, Brian Norris wrote:
> > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> >> We do a couple of things in this series which result in
> >> cleaner device tree implementation, faster perfomance and
> >> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> >> for use in the system.
> >>
> >> - Establish a custom interface between NAND and GPMC driver. This is
> >> needed because all of the NAND registers sit in the GPMC register space.
> >> Some bits like NAND IRQ are even shared with GPMC.
> >>
> >> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> >> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> >> This causes performance increase when using prefetch-irq mode.
> >> 30% increase in read, 17% increase in write in prefetch-irq mode.
> >>
> >> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> >> driver can be used on non-OMAP platforms. e.g. Keystone.
> >>
> >> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> >> 2 to 4 of these and most of them would be unused otherwise. It also
> >> allows a cleaner implementation of NAND Ready pin status for the NAND 
> >> driver.
> >>
> >> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> >>
> >> This series is available at
> >> g...@github.com:rogerq/linux.git
> >> in branch
> >> for-v4.4/gpmc-v3
> >>
> >> cheers,
> >> -roger
> >>
> >> Changelog:
> >> v3:
> >> -Fixed and tested NAND using legacy boot on omap3-beagle.
> >> -Support rising and falling edge interrupts on WAITpins.
> >> -Update DT node of all gpmc users.
> > 
> > The MTD stuff looks mostly good to me know. I've made all my comments
> > for now, but I'm not sure how you're going to end up rebasing/splitting
> > and what you're going to do with the irqchip removal, so I'll refrain
> > from ack's for now. Hopefully I can either ack or merge v4.
> 
> I'll retain the irqchip model for now and send a v4 with all comments
> addressed and better subsystem wise patch split.
> 
> > 
> > I brought it up on one other patch, but it's not really clear to me what
> > the split is on board file vs. device tree handling, since you seem to
> > have a combination of both (i.e., platform data that passes along device
> > nodes). What's the plan on that?
> 
> Platform data no longer passes device nodes. We're either true device tree
> or plain legacy. The deprecated fields are no longer used once the series is
> applied.

Well, they're still sorta used (you assign info->of_node =
pdata->of_node, for instance). As dicussed in the other thread, I think
we can avoid the deprecation part and just kill the fields though, and
that would make things clearer.

> > And of course, there's the question of how exactly to merge this, given
> > the:
> > (1) conflicts already existing in the MTD dev tree
> 
> I'll rebase the series on top of MTD dev tree.

OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd:
nand: drop unnecessary partition parser data"). Maybe when queueing up a
branch, that'd be the best starting point for Tony, so he doesn't need
to have all of MTD's stuff in his tree too? I can set up a signed tag or
something, if that would be helpful.

But for sending patches, the latest l2-mtd.git is fine too.

> > (2) this touches several trees, often in the same patch and
> 
> I'll try my best to split the patches but not sure if this could be 100%
> clean split without functional breakage.
> 
> > (3) even if the patches were split out a little better into MTD and
> > non-MTD stuff, I think there would still be dependencies such that
> > we'd need at least 1 (probably 2) cross merges to get it all
> > straight
> 
> That is correct.
> Is it OK if functionality breaks if for example only MTD changes are 
> considered?

I think I may have misunderstood the branch proposal. If Tony queues up:

  l2-mtd.git (or just up to commit a61ae81a1907)
  +
  your patches

and I pull that back into l2-mtd.git as well, then we don't need to
worry about patches that touch multiple "trees". Just do whatever makes
things clearest, including disregarding some of my comments along the
line of (3).

Sorry for any confusion.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usb: xhci-mtk: fix bpkts value of LS/HS periodic eps not behind TT

[Chunfeng Yun]

when a LS or FS device doesn't connect though a HS hub,
the @bPkts field of its periodic endpoint context should
be set to 1.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk-sch.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index c30de7c..73f763c 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -275,8 +275,9 @@ static bool need_bw_sch(struct usb_host_endpoint *ep,
return false;
 
/*
-* for LS & FS periodic endpoints which its device don't attach
-* to TT are also ignored, root-hub will schedule them directly
+* for LS & FS periodic endpoints which its device is not behind
+* a TT are also ignored, root-hub will schedule them directly,
+* but need set @bpkts field of endpoint context to 1.
 */
if (is_fs_or_ls(speed) && !has_tt)
return false;
@@ -339,8 +340,17 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd, struct 
usb_device *udev,
GET_MAX_PACKET(usb_endpoint_maxp(>desc)),
usb_endpoint_dir_in(>desc), ep);
 
-   if (!need_bw_sch(ep, udev->speed, slot_ctx->tt_info & TT_SLOT))
+   if (!need_bw_sch(ep, udev->speed, slot_ctx->tt_info & TT_SLOT)) {
+   /*
+* set @bpkts to 1 if it is LS or FS periodic endpoint, and its
+* device does not connected through an external HS hub
+*/
+   if (usb_endpoint_xfer_int(>desc)
+   || usb_endpoint_xfer_isoc(>desc))
+   ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(1));
+
return 0;
+   }
 
bw_index = get_bw_index(xhci, udev, ep);
sch_bw = _array[bw_index];
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V8 0/5] dma: add Qualcomm Technologies HIDMA driver

[Sinan Kaya]

The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.

1. HIDMA Management driver
2. HIDMA Channel driver

Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.

The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.

Changes from V7: (https://lkml.org/lkml/2015/11/22/221)
* none

Changes from V7: (https://lkml.org/lkml/2015/11/22/222)
* remove done goto labels
* remove extra space in device tree documentation
* correct spelling mistake
* prefix constants with HIDMA

Changes from V7: (https://lkml.org/lkml/2015/11/22/223)
* Split debugs from the patchset.
* Remove potential sleeps in PM functions.
* Seperate the lower level into its own patch.
* Remove redundant DMA_CTRL_ACK assignment.
* tx_status changes to handle completed transactions right before the
  pause.
* terminate the running transactions in channel free.

Sinan Kaya (5):
  dma: qcom_bam_dma: move to qcom directory
  dma: add Qualcomm Technologies HIDMA management driver
  dma: add Qualcomm Technologies HIDMA channel driver
  dma: qcom_hidma: implement lower level hardware interface
  dma: qcom_hidma: add debugfs hooks

 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 ++
 drivers/dma/Kconfig|  11 +-
 drivers/dma/Makefile   |   2 +-
 drivers/dma/qcom/Kconfig   |  29 +
 drivers/dma/qcom/Makefile  |   4 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |   4 +-
 drivers/dma/qcom/hidma.c   | 716 
 drivers/dma/qcom/hidma.h   | 161 
 drivers/dma/qcom/hidma_dbg.c   | 219 +
 drivers/dma/qcom/hidma_ll.c| 927 +
 drivers/dma/qcom/hidma_mgmt.c  | 318 +++
 drivers/dma/qcom/hidma_mgmt.h  |  39 +
 drivers/dma/qcom/hidma_mgmt_sys.c  | 292 +++
 15 files changed, 2886 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
 create mode 100644 drivers/dma/qcom/Kconfig
 create mode 100644 drivers/dma/qcom/Makefile
 rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
 create mode 100644 drivers/dma/qcom/hidma.c
 create mode 100644 drivers/dma/qcom/hidma.h
 create mode 100644 drivers/dma/qcom/hidma_dbg.c
 create mode 100644 drivers/dma/qcom/hidma_ll.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usb: xhci: fix config fail of FS hub behind a HS hub with MTT

[Chunfeng Yun]

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6cbcd1e..27c8cf8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4785,8 +4785,16 @@ int xhci_update_hub_device(struct usb_hcd *hcd, struct 
usb_device *hdev,
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
slot_ctx = xhci_get_slot_ctx(xhci, config_cmd->in_ctx);
slot_ctx->dev_info |= cpu_to_le32(DEV_HUB);
+   /*
+* refer to section 6.2.2: MTT should be 0 for full speed hub,
+* but it may be already set to 1 when setup an xHCI virtual
+* device, so clear it anyway.
+*/
if (tt->multi)
slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
+   else if (hdev->speed == USB_SPEED_FULL)
+   slot_ctx->dev_info &= cpu_to_le32(~DEV_MTT);
+
if (xhci->hci_version > 0x95) {
xhci_dbg(xhci, "xHCI version %x needs hub "
"TT think time and number of ports\n",
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V8 2/5] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

The Qualcomm Technologies HIDMA device has been designed to support
virtualization technology. The driver has been divided into two to follow
the hardware design.

1. HIDMA Management driver
2. HIDMA Channel driver

Each HIDMA HW consists of multiple channels. These channels share some set
of common parameters. These parameters are initialized by the management
driver during power up. Same management driver is used for monitoring the
execution of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and prioritization.

The management driver is executed in hypervisor context and is the main
management entity for all channels provided by the device.

Signed-off-by: Sinan Kaya 
Reviewed-by: Andy Shevchenko 
---
 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 
 drivers/dma/qcom/Kconfig   |  11 +
 drivers/dma/qcom/Makefile  |   1 +
 drivers/dma/qcom/hidma_mgmt.c  | 318 +
 drivers/dma/qcom/hidma_mgmt.h  |  39 +++
 drivers/dma/qcom/hidma_mgmt_sys.c  | 292 +++
 7 files changed, 819 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
 create mode 100644 drivers/dma/qcom/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt 
b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
new file mode 100644
index 000..4fc6876
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -0,0 +1,97 @@
+What:  /sys/devices/platform/hidma-mgmt*/chan*/priority
+   /sys/devices/platform/QCOM8060:*/chan*/priority
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains either 0 or 1 and indicates if the DMA channel is a
+   low priority (0) or high priority (1) channel.
+
+What:  /sys/devices/platform/hidma-mgmt*/chan*/weight
+   /sys/devices/platform/QCOM8060:*/chan*/weight
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains 0..15 and indicates the weight of the channel among
+   equal priority channels during round robin scheduling.
+
+What:  /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
+   /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the platform specific cycle value to wait after a
+   reset command is issued. If the value is chosen too short,
+   then the HW will issue a reset failure interrupt. The value
+   is platform specific and should not be changed without
+   consultance.
+
+What:  /sys/devices/platform/hidma-mgmt*/dma_channels
+   /sys/devices/platform/QCOM8060:*/dma_channels
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the number of dma channels supported by one instance
+   of HIDMA hardware. The value may change from chip to chip.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_major
+   /sys/devices/platform/QCOM8060:*/hw_version_major
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number major for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_minor
+   /sys/devices/platform/QCOM8060:*/hw_version_minor
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number minor for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_rd_xactions
+   /sys/devices/platform/QCOM8060:*/max_rd_xactions
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains a value between 0 and 31. Maximum number of
+   read transactions that can be issued back to back.
+   Choosing a higher number gives better performance but
+   can also cause performance reduction to other peripherals
+   sharing the same bus.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_read_request
+   /sys/devices/platform/QCOM8060:*/max_read_request
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Size of each read request. The value needs to be a power
+   of two and can be between 128 and 1024.
+
+What:  

[PATCH V8 5/5] dma: qcom_hidma: add debugfs hooks

[Sinan Kaya]

Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.

A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile|   2 +-
 drivers/dma/qcom/hidma.c |   3 +
 drivers/dma/qcom/hidma.h |   2 +
 drivers/dma/qcom/hidma_dbg.c | 219 +++
 4 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/qcom/hidma_dbg.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index d2c6bda..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
 obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 1237a26..ee3aacd 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -650,6 +650,7 @@ static int hidma_probe(struct platform_device *pdev)
 
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+   hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -658,6 +659,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
 
 uninit:
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
 dmafree:
if (dmadev)
@@ -675,6 +677,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, >lldev);
+   hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
 
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b8a7990..88897c7 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -156,4 +156,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
 irqreturn_t hidma_ll_inthandler(int irq, void *arg);
 void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
 #endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..3698257
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+   struct hidma_lldev *lldev = llhndl;
+   struct hidma_tre *tre;
+   u32 length;
+   dma_addr_t src_start;
+   dma_addr_t dest_start;
+   u32 *tre_local;
+
+   if (tre_ch >= lldev->nr_tres) {
+   dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+   return;
+   }
+   tre = >trepool[tre_ch];
+   seq_printf(s, "--Channel %d -\n", tre_ch);
+   seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+   seq_printf(s, "queued = 0x%x\n", tre->queued);
+   seq_printf(s, "err_info = 0x%x\n",
+  lldev->tx_status_list[tre->chidx].err_info);
+   seq_printf(s, "err_code = 0x%x\n",
+  lldev->tx_status_list[tre->chidx].err_code);
+   seq_printf(s, "status = 0x%x\n", tre->status);
+   seq_printf(s, "chidx = 0x%x\n", tre->chidx);
+   seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+   seq_printf(s, "dev_name=%s\n", tre->dev_name);
+   seq_printf(s, "callback=%p\n", tre->callback);
+   seq_printf(s, "data=%p\n", tre->data);
+   seq_printf(s, "tre_index = 0x%x\n", tre->tre_index);
+
+   tre_local = >tre_local[0];
+   src_start = tre_local[TRE_SRC_LOW_IDX];
+   src_start = ((u64) (tre_local[TRE_SRC_HI_IDX]) << 32) + src_start;
+   dest_start = tre_local[TRE_DEST_LOW_IDX];
+   dest_start += ((u64) 

[PATCH V8 1/5] dma: qcom_bam_dma: move to qcom directory

[Sinan Kaya]

Creating a QCOM directory for all QCOM DMA source files.

Signed-off-by: Sinan Kaya 
Reviewed-by: Andy Gtoss 
---
 drivers/dma/Kconfig| 11 ++-
 drivers/dma/Makefile   |  2 +-
 drivers/dma/qcom/Kconfig   |  8 
 drivers/dma/qcom/Makefile  |  1 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |  4 ++--
 5 files changed, 14 insertions(+), 12 deletions(-)
 create mode 100644 drivers/dma/qcom/Kconfig
 create mode 100644 drivers/dma/qcom/Makefile
 rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
  16 to 32 channels for peripheral to memory or memory to memory
  transfers.
 
-config QCOM_BAM_DMA
-   tristate "QCOM BAM DMA support"
-   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
-   select DMA_ENGINE
-   select DMA_VIRTUAL_CHANNELS
-   ---help---
- Enable support for the QCOM BAM DMA controller.  This controller
- provides DMA capabilities for a variety of on-chip devices.
-
 config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
+source "drivers/dma/qcom/Kconfig"
+
 source "drivers/dma/dw/Kconfig"
 
 source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
 obj-$(CONFIG_PL330_DMA) += pl330.o
 obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
 obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
 
+obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+   tristate "QCOM BAM DMA support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the QCOM BAM DMA controller.  This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
 #include 
 #include 
 
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
 
 struct bam_desc_hw {
u32 addr;   /* Buffer physical address */
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V8 4/5] dma: qcom_hidma: implement lower level hardware interface

[Sinan Kaya]

This patch implements the hardware hooks for the HIDMA channel driver.

The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start

OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.

Completions are delivered via callbacks via tasklet.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/Makefile   |   2 +
 drivers/dma/qcom/hidma.c|   2 +-
 drivers/dma/qcom/hidma_ll.c | 927 
 3 files changed, 930 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/qcom/hidma_ll.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..d2c6bda 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 0515145..1237a26 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -415,7 +415,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
/* move myself to free_list */
list_move(>node, >free);
}
-
+   rc = hidma_ll_resume(dmadev->lldev);
 out:
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..b4c8f77
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hidma.h"
+
+#define EVRE_SIZE  16  /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET   0x8
+#define TRCA_RING_HIGH_OFFSET  0xC
+#define TRCA_RING_LEN_OFFSET   0x10
+#define TRCA_READ_PTR_OFFSET   0x18
+#define TRCA_WRITE_PTR_OFFSET  0x20
+#define TRCA_DOORBELL_OFFSET   0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET   0x8
+#define EVCA_RING_HIGH_OFFSET  0xC
+#define EVCA_RING_LEN_OFFSET   0x10
+#define EVCA_READ_PTR_OFFSET   0x18
+#define EVCA_WRITE_PTR_OFFSET  0x20
+#define EVCA_DOORBELL_OFFSET   0x400
+
+#define EVCA_IRQ_STAT_OFFSET   0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX   0
+#define EVRE_LEN_IDX   1
+#define EVRE_DEST_LOW_IDX  2
+#define EVRE_DEST_HI_IDX   3
+
+#define EVRE_ERRINFO_BIT_POS   24
+#define EVRE_CODE_BIT_POS  28
+
+#define EVRE_ERRINFO_MASK  GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK  GENMASK(7, 0)
+#define CH_STATE_BIT_POS   0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS  0
+#define IRQ_EV_CH_WR_RESP_BIT_POS  1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS   10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS   11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS  14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+   BIT(IRQ_EV_CH_WR_RESP_BIT_POS)  | \
+   BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+   BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS)   | \
+   BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS)   | \
+   BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS))
+
+enum ch_command {
+   CH_DISABLE = 0,
+   CH_ENABLE = 1,
+   CH_SUSPEND = 2,
+   CH_RESET = 9,
+};
+
+enum ch_state {
+   CH_DISABLED = 0,
+   CH_ENABLED = 1,
+   CH_RUNNING = 2,
+   CH_SUSPENDED = 3,
+   

[PATCH V8 3/5] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.

Signed-off-by: Sinan Kaya 
---
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 drivers/dma/qcom/Kconfig   |  10 +
 drivers/dma/qcom/hidma.c   | 713 +
 drivers/dma/qcom/hidma.h   | 159 +
 4 files changed, 900 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 create mode 100644 drivers/dma/qcom/hidma.c
 create mode 100644 drivers/dma/qcom/hidma.h

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+   hidma_24: dma-controller@0x5c05 {
+   compatible = "qcom,hidma-1.0";
+   reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+   interrupts = <0 389 0>;
+   desc-count = <10>;
+   event-channel = <4>;
+   };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
  start managing the channels. In a virtualized environment,
  the guest OS would run QCOM_HIDMA channel driver and the
  hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+   tristate "Qualcomm Technologies HIDMA Channel support"
+   select DMA_ENGINE
+   help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.).  It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..0515145
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,713 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik . Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen .
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009;  for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * 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.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
+ * during kernel boot.
+ */
+#define HIDMA_AUTOSUSPEND_TIMEOUT  2000
+#define HIDMA_ERR_INFO_SW

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 03/12/15 10:39, Brian Norris wrote:
> Hi,
> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> We do a couple of things in this series which result in
>> cleaner device tree implementation, faster perfomance and
>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>> for use in the system.
>>
>> - Establish a custom interface between NAND and GPMC driver. This is
>> needed because all of the NAND registers sit in the GPMC register space.
>> Some bits like NAND IRQ are even shared with GPMC.
>>
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>
>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>
>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>> 2 to 4 of these and most of them would be unused otherwise. It also
>> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
>>
>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>
>> This series is available at
>> g...@github.com:rogerq/linux.git
>> in branch
>> for-v4.4/gpmc-v3
>>
>> cheers,
>> -roger
>>
>> Changelog:
>> v3:
>> -Fixed and tested NAND using legacy boot on omap3-beagle.
>> -Support rising and falling edge interrupts on WAITpins.
>> -Update DT node of all gpmc users.
> 
> The MTD stuff looks mostly good to me know. I've made all my comments
> for now, but I'm not sure how you're going to end up rebasing/splitting
> and what you're going to do with the irqchip removal, so I'll refrain
> from ack's for now. Hopefully I can either ack or merge v4.

I'll retain the irqchip model for now and send a v4 with all comments
addressed and better subsystem wise patch split.

> 
> I brought it up on one other patch, but it's not really clear to me what
> the split is on board file vs. device tree handling, since you seem to
> have a combination of both (i.e., platform data that passes along device
> nodes). What's the plan on that?

Platform data no longer passes device nodes. We're either true device tree
or plain legacy. The deprecated fields are no longer used once the series is
applied.

> 
> And of course, there's the question of how exactly to merge this, given
> the:
> (1) conflicts already existing in the MTD dev tree

I'll rebase the series on top of MTD dev tree.

> (2) this touches several trees, often in the same patch and

I'll try my best to split the patches but not sure if this could be 100%
clean split without functional breakage.

> (3) even if the patches were split out a little better into MTD and
> non-MTD stuff, I think there would still be dependencies such that
> we'd need at least 1 (probably 2) cross merges to get it all
> straight

That is correct.
Is it OK if functionality breaks if for example only MTD changes are considered?

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

On Thu, Dec 03, 2015 at 11:27:13AM +0530, Roger Quadros wrote:
> On 03/12/15 09:59, Brian Norris wrote:
> > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> >>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
> >>  drivers/memory/omap-gpmc.c   | 143 
> >> +++
> >>  drivers/mtd/nand/omap2.c | 136 
> >> +
> >>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
> >>  4 files changed, 155 insertions(+), 132 deletions(-)
> > 
> > Also, this is going to be hard to manage across trees, as you touch
> > three drivers all at once. Is it not possible to split any of this apart
> > better?
> 
> Will need some more effort and I can do it. Butm if we're going to start
> an with immutable branch with everything in, is it worth the effort?

I don't think I noticed the "everything in it" part. I was assuming
you'd have non-MTD changes in the immutable branch, and MTD stuff on
top. But that is indeed more difficult. I'm fine with everything going
in one branch, and pulling that all into MTD.

Then the hangup is that you'll need to have some of l2-mtd.git in that
branch as a prerequisite, if you're going to rebase. Or else I have to
fix it up when merging back into l2-mtd.git...

...

> >> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> >> b/include/linux/platform_data/mtd-nand-omap2.h
> >> index a067f58..ff27e5a 100644
> >> --- a/include/linux/platform_data/mtd-nand-omap2.h
> >> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> >> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
> >>int devsize;
> >>enum omap_ecc   ecc_opt;
> >>  
> >> -  /* for passing the partitions */
> >> -  struct device_node  *of_node;
> >>struct device_node  *elm_of_node;
> >>  
> >>/* deprecated */
> >>struct gpmc_nand_regs   reg;
> >> +  struct device_node  *of_node;
> > 
> > I'm a little confused here. Do you have a mixed platform data / device
> > tree setup here? That's odd. (It also seems if that was really
> > necessary, you could have the board file set pdev->dev.of_node before
> > registering it, then you don't need this field.) But really, if you're
> > partly using device tree, can't you just convert completely? Or is this
> > a two-phase process, and you're planning to convert omap2 to full device
> > tree?
> 
> The existing device tree implementation for omap2-nand was like this:
> omap-gpmc.c driver was creating a platform device for the nand device and
> passing the device node via platform data.
> 
> After this series we no longer do this and that's why of_node is marked
> deprecated in platform data. I might as well could just get rid of it
> but wasn't sure of how we're going to integrate the changes into the
> subsystem trees so just marked it deprecated.

Whoops, sorry I didn't read the "deprecated" header there this time. I
thought the movement was odd. *facepalm*

But yes, especially if we're putting everything in one branch, it'd be
more clear to simply kill off things instead of marking things
deprecated. It's especially confusing, since you're actually still using
the field.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/12] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock

[Krzysztof Kozlowski]

On 03.12.2015 06:19, Ben Gamari wrote:
> From: Thomas Abraham 
> 
> With the addition of the new Samsung specific cpu-clock type, the
> arm clock can be represented as a cpu-clock type. Add the CPU clock
> configuration data and instantiate the CPU clock type for Exynos5420.
> 
> Changes by Bartlomiej:
> - split Exynos5420 support from the original patches
> - moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c
> 
> Changes by Ben Gamari:
> - Rebased

If only rebasing then you should retain the Lukasz's review tag. He
doesn't have to review it again, right? :)

> 
> Cc: Tomasz Figa 
> Cc: Mike Turquette 
> Cc: Javier Martinez Canillas 
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Ben Gamari 
> ---
>  drivers/clk/samsung/clk-exynos5420.c   | 58 
> --
>  include/dt-bindings/clock/exynos5420.h |  2 ++
>  2 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 389af3c..2288052 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -18,6 +18,7 @@
>  #include 
>  
>  #include "clk.h"
> +#include "clk-cpu.h"
>  
>  #define APLL_LOCK0x0
>  #define APLL_CON00x100
> @@ -616,9 +617,11 @@ static struct samsung_mux_clock exynos5x_mux_clks[] 
> __initdata = {
>   MUX(0, "mout_mspll_kfc", mout_mspll_cpu_p, SRC_TOP7, 8, 2),
>   MUX(0, "mout_mspll_cpu", mout_mspll_cpu_p, SRC_TOP7, 12, 2),
>  
> - MUX(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
> + MUX_F(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
> +   CLK_SET_RATE_PARENT, 0),
>   MUX(0, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1),
> - MUX(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1),
> + MUX_F(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1,
> +   CLK_SET_RATE_PARENT, 0),
>   MUX(0, "mout_kfc", mout_kfc_p, SRC_KFC, 16, 1),
>  
>   MUX(0, "mout_aclk200", mout_group1_p, SRC_TOP0, 8, 2),
> @@ -1246,6 +1249,50 @@ static struct samsung_pll_clock exynos5x_plls[nr_plls] 
> __initdata = {
>   KPLL_CON0, NULL),
>  };
>  
> +#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud)\
> + apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
> +  ((cpud) << 4)))
> +
> +static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[] __initconst 
> = {
> + { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
> + { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
> + { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
> + { 100, E5420_EGL_DIV0(3, 6, 6, 2), },
> + {  90, E5420_EGL_DIV0(3, 6, 6, 2), },
> + {  80, E5420_EGL_DIV0(3, 5, 5, 2), },
> + {  70, E5420_EGL_DIV0(3, 5, 5, 2), },
> + {  60, E5420_EGL_DIV0(3, 4, 4, 2), },
> + {  50, E5420_EGL_DIV0(3, 3, 3, 2), },
> + {  40, E5420_EGL_DIV0(3, 3, 3, 2), },
> + {  30, E5420_EGL_DIV0(3, 3, 3, 2), },
> + {  20, E5420_EGL_DIV0(3, 3, 3, 2), },
> + {  0 },

The vendor code (Galaxy S5 with Exynos5422) sets pclk_dbg divider to 7.
In the same time APLL divider is only 1.

For the ACLK divider (of KFC below) the vendor sets 3, not 2.

The values also don't match the Exynos5420 from Note 3.

The Exynos5800 apparently has values more similar to 5422.

The question is: for which exact model this is? We can of course choose
the safest values here but probably these would be with the highest
dividers?

Best regards,
Krzyztof


> +};
> +
> +#define E5420_KFC_DIV(kpll, pclk, aclk)  
> \
> + kpll) << 24) | ((pclk) << 20) | ((aclk) << 4)))
> +
> +static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[] __initconst 
> = {
> + { 130, E5420_KFC_DIV(3, 5, 2), },
> + { 120, E5420_KFC_DIV(3, 5, 2), },
> + { 110, E5420_KFC_DIV(3, 5, 2), },
> + { 100, E5420_KFC_DIV(3, 5, 2), },
> + {  90, E5420_KFC_DIV(3, 5, 2), },
> + {  80, E5420_KFC_DIV(3, 5, 2), },
> + {  70, E5420_KFC_DIV(3, 4, 2), },
> + {  60, E5420_KFC_DIV(3, 4, 2), },
> + {  50, E5420_KFC_DIV(3, 4, 2), },
> + {  40, E5420_KFC_DIV(3, 3, 2), },
> + {  30, E5420_KFC_DIV(3, 3, 2), },
> + {  20, E5420_KFC_DIV(3, 3, 2), },
> + {  0 },
> +};
> +
>  static const struct of_device_id ext_clk_match[] __initconst = {
>   { .compatible = "samsung,exynos5420-oscclk", .data = (void *)0, },
>   { },
> @@ -1310,6 +1357,13 @@ static void __init exynos5x_clk_init(struct 
> device_node *np,
>   ARRAY_SIZE(exynos5800_gate_clks));
>   }
>  
> + exynos_register_cpu_clock(ctx, 

Re: [PATCH v3 0/8] phy: rockchip-usb: correct pll handling and usb-uart

[Kishon Vijay Abraham I]

Hi,

On Wednesday 02 December 2015 09:02 PM, Heiko Stübner wrote:
> Hi Kishon,
> 
> Am Donnerstag, 19. November 2015, 22:22:21 schrieb Heiko Stuebner:
>> changes in v3:
>> - rebase on top of Julias of_node_put fix
>> - address comments from Kishon Vijay Abraham
>>   - position of the devm_action in the first patch
>>   - separate compatible-addition into separate patch
>>   - don't rephrase comment when moving stuff around
>> - address Doug's comment and keep clk-tree change and assigned-clocks
>>   setting together
>> - add Doug's review-tag to patches 5,6,7
>> changes in v2:
>> - add Doug's review-tag to patches 1 and 3
>> - address comment and add the missing transistional rk_phy->base
>>   assignment in patch2
> 
> do you have any further comments for this series?

Nope. However I'd like to have ACK from the clock maintainer (Mike turquette?)
for "phy: rockchip-usb: expose the phy-internal PLLs".

Thanks
Kishon
> 
> 
> Thanks
> Heiko
> 
>> Patch 1 might be nice to go in as fix together with Julia's patch?
>>
>> Patches 2-7 fix a long-standing issue with the clock-tree of Rockchip SoCs
>> namely our ignorance of the usbphy-internal pll that creates the needed
>> 480MHz but is also a supply-clock back to the core clock-controller in
>> Rockchip SoCs.
>>
>> Till now that was worked around using a virtual clock in the cru itself,
>> but that is of course ignorant of other parts then disabling the phy
>> behind the cru's back, thus breaking potential users of these clocks.
>>
>>
>> Patch 8, while not associated with the new pll handling, also builds
>> on the groundwork introduced there and adds support for the function
>> repurposing one of the phys as passthrough for uart-data. This enables
>> attaching a ttl converter to the D+ and D- pins of an usb cable to
>> receive uart data this way, when it is not really possible to attach
>> a regular serial console to a board.
>>
>> One point of critique in my first iteration [0] of this was, that
>> due to when the reconfiguration happens we may miss parts of the logs
>> when earlycon is enabled. So far early_initcall gets used as the
>> unflattened devicetree is necessary to set this up. Doing this for
>> example in the early_param directly would require parsing the flattened
>> devicetree to get needed nodes and properties.
>>
>> I still maintain that if you're working on anything before smp-bringup
>> you should use a real dev-board instead or try to solder uart cables
>> on hopefully available test-points :-) .
>>
>>
>> In any case, if patch 8 causes to much headache, it could be dropped
>> to not hinder the earlier 7 patches.
>>
>> [0] http://comments.gmane.org/gmane.linux.ports.arm.rockchip/715
>>
>> Heiko Stuebner (8):
>>   phy: rockchip-usb: fix clock get-put mismatch
>>   phy: rockchip-usb: introduce a common data-struct for the device
>>   phy: rockchip-usb: move per-phy init into a separate function
>>   phy: rockchip-usb: add compatible values for rk3066a and rk3188
>>   phy: rockchip-usb: expose the phy-internal PLLs
>>   ARM: dts: rockchip: add clock-cells for usb phy nodes
>>   clk: rockchip: fix usbphy-related clocks
>>   phy: rockchip-usb: add handler for usb-uart functionality
>>
>>  .../devicetree/bindings/phy/rockchip-usb-phy.txt   |   6 +-
>>  Documentation/kernel-parameters.txt|   6 +
>>  arch/arm/boot/dts/rk3066a.dtsi |   2 +
>>  arch/arm/boot/dts/rk3188.dtsi  |   2 +
>>  arch/arm/boot/dts/rk3288-veyron.dtsi   |   2 +-
>>  arch/arm/boot/dts/rk3288.dtsi  |   3 +
>>  drivers/clk/rockchip/clk-rk3188.c  |  11 +-
>>  drivers/clk/rockchip/clk-rk3288.c  |  16 +-
>>  drivers/phy/phy-rockchip-usb.c | 458
>> ++--- 9 files changed, 417 insertions(+), 89 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422

[Viresh Kumar]

Hi Ben,

On 02-12-15, 22:19, Ben Gamari wrote:
> 
> This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422
> SOCs. In particular, it adds support for operating-points-v2 bindings to the
> arm-big-little cpufreq driver and updates the above-mentioned SOCs' 
> devicetrees
> to take advantage of this support. There are also a couple of patches 
> improving
> the clarify of the arm-big-little implementation. It is built on a set posted
> by Bartlomiej Zolnierkiewicz in April 2015.
> 
> The most signficant change from the original series is porting to the
> operating-points-v2 devicetree bindings. The series has been tested by me on
> and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit.

Thanks for working with opp-v2 bindings, really appreciate it.

But, before I start reviewing this series, I have few comments.
- We weren't able to use cpufreq-dt driver for big LITTLE platforms
  earlier, as it never had multi cluster support and we wanted
  clock-sharing information via DT.
- That is all fixed now.
- I want Samsung's big LITTLE platforms to use cpufreq-dt and drop
  arm_big_little driver completely.
- The only case for which it (arm_big_little) driver might be useful
  is the IKS solution. Which I don't believe you are going to use in
  future :)

My plan for the arm-big-little driver:
- Migrate all platforms to use cpufreq-dt instead for non-IKS
  solution
- Make arm-big-little driver arm-big-little-iks only driver.

@Sudeep: What would it take you to use cpufreq-dt for ARM's platforms
?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Jarkko Sakkinen]

On Wed, Dec 02, 2015 at 12:11:55PM -0700, Jason Gunthorpe wrote:
> On Wed, Dec 02, 2015 at 11:27:27AM -0700, Jason Gunthorpe wrote:
> 
> > I'm guessing that if the driver probe order is tpm_crb,tpm_tis then
> > things work because tpm_crb will claim the device first? Otherwise
> > tpm_tis claims these things unconditionally? If the probe order is
> > reversed things become broken?
> 
> Okay, I didn't find the is_fifo before, so that make sense
> 
> But this:
> 
> > What is the address tpm_tis should be using? I see two things, it
> > either uses the x86 default address or it expects the ACPI to have a
> > MEM resource. AFAIK ACPI should never rely on hard wired addresses, so
> > I removed that code in this series. Perhaps tpm_tis should be using
> > control_area_pa ? Will ACPI ever present a struct resource? (if yes,
> > why isn't tpm_crb using one?)
> 
> Is then still a problem. On Martin's system the MSFT0101 device does
> not have a struct resource attached to it. Does any system, or is this
> just dead code?
> 
> Should the control_area_pa be used?

I guess it'd be more realiable. In my NUC the current fix works and the
people who tested it. If you supply me a fix that changes it to use that
I can test it and this will give also coverage to the people who tested
my original fix.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Brian,

On 03/12/15 09:59, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
>> Move NAND specific device tree parsing to NAND driver.
>>
>> The NAND controller node must have a compatible id, register space
>> resource and interrupt resource.
>>
>> Signed-off-by: Roger Quadros 
> 
> This one's going to need rebased, as there are some conflicting of_node
> changes in l2-mtd.git.

Al right. I'll rebase on top of l2-mtd.git
> 
>> ---
>> v4: Warn if using older incompatible DT i.e. compatible property not present
>> in nand node.
>>
>>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>>  drivers/memory/omap-gpmc.c   | 143 
>> +++
>>  drivers/mtd/nand/omap2.c | 136 +
>>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>>  4 files changed, 155 insertions(+), 132 deletions(-)
> 
> Also, this is going to be hard to manage across trees, as you touch
> three drivers all at once. Is it not possible to split any of this apart
> better?

Will need some more effort and I can do it. Butm if we're going to start
an with immutable branch with everything in, is it worth the effort?
> 
>>
>> diff --git a/arch/arm/mach-omap2/gpmc-nand.c 
>> b/arch/arm/mach-omap2/gpmc-nand.c
>> index ffe646a..e07ca27 100644
>> --- a/arch/arm/mach-omap2/gpmc-nand.c
>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
>> *gpmc_nand_data,
>>  gpmc_nand_res[1].start = gpmc_get_irq();
>>  
>>  memset(, 0, sizeof(struct gpmc_settings));
>> -if (gpmc_nand_data->of_node)
>> -gpmc_read_settings_dt(gpmc_nand_data->of_node, );
>> -else
>> -gpmc_set_legacy(gpmc_nand_data, );
>> +gpmc_set_legacy(gpmc_nand_data, );
>>  
>>  s.device_nand = true;
>>  
>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>> index e75226d..318c187 100644
>> --- a/drivers/memory/omap-gpmc.c
>> +++ b/drivers/memory/omap-gpmc.c
>> @@ -29,7 +29,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  



>>  
>> -ppdata.of_node = pdata->of_node;
>> -mtd_device_parse_register(mtd, NULL, , pdata->parts,
>> -  pdata->nr_parts);
>> +if (dev->of_node) {
>> +ppdata.of_node = dev->of_node;
> 
> The latest l2-mtd.git changed how the partitions' of_node is passed. Now
> this is handled by nand_set_flash_node().

OK.
> 
>> +mtd_device_parse_register(mtd, NULL, , NULL, 0);
>> +
>> +} else {
>> +mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
>> +}
>>  
>>  platform_set_drvdata(pdev, mtd);
>>  
>> @@ -2083,11 +2173,17 @@ static int omap_nand_remove(struct platform_device 
>> *pdev)
>>  return 0;
>>  }
>>  
>> +static const struct of_device_id omap_nand_ids[] = {
>> +{ .compatible = "ti,omap2-nand", },
>> +{},
>> +};
>> +
>>  static struct platform_driver omap_nand_driver = {
>>  .probe  = omap_nand_probe,
>>  .remove = omap_nand_remove,
>>  .driver = {
>>  .name   = DRIVER_NAME,
>> +.of_match_table = of_match_ptr(omap_nand_ids),
>>  },
>>  };
>>  
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index a067f58..ff27e5a 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
>>  int devsize;
>>  enum omap_ecc   ecc_opt;
>>  
>> -/* for passing the partitions */
>> -struct device_node  *of_node;
>>  struct device_node  *elm_of_node;
>>  
>>  /* deprecated */
>>  struct gpmc_nand_regs   reg;
>> +struct device_node  *of_node;
> 
> I'm a little confused here. Do you have a mixed platform data / device
> tree setup here? That's odd. (It also seems if that was really
> necessary, you could have the board file set pdev->dev.of_node before
> registering it, then you don't need this field.) But really, if you're
> partly using device tree, can't you just convert completely? Or is this
> a two-phase process, and you're planning to convert omap2 to full device
> tree?

The existing device tree implementation for omap2-nand was like this:
omap-gpmc.c driver was creating a platform device for the nand device and
passing the device node via platform data.

After this series we no longer do this and that's why of_node is marked
deprecated in platform data. I might as well could just get rid of it
but wasn't sure of how we're going to integrate the changes into the
subsystem trees so just marked it deprecated.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Jarkko Sakkinen]

On Wed, Dec 02, 2015 at 11:27:27AM -0700, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2015 at 11:33:51PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Dec 01, 2015 at 11:58:26AM -0700, Jason Gunthorpe wrote:
> 
> > I went through the patches and didn't see anything that would shock me
> > enough not to apply the patches in the current if they also work when
> > tested *but* are these release critical for Linux v4.4?
> 
> Jarkko,
> 
> Can you explain how
> 
> commit 399235dc6e95400a1322ae92073bc572f0c8
> Author: Jarkko Sakkinen 
> Date:   Tue Sep 29 00:32:19 2015 +0300
> 
> tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
> 
> Is supposed to work? I get the jist of the idea, but I'm not seeing
> how it can work reliably..

The idea is that circulate the problem that pnp driver infra can pass at
most 7 character device IDs and MSFT0101 (used for TPM2 devices) has 8
characters. They have disjoint sets of device IDs so both cannot ever
attach. I don't know who was idiot enough to invent 8 character device
ID for TPM2 devices but that's the reality.

It's not a perfect fix but I couldn't figure out anything more clever
at that time. And nobody else was paying attention to the issue so
I had to do something and people who reported bug tested the patch and
were happy so I'm confident I did the right thing in the situation.

> The idea is to pass off TPM2_START_FIFO to tpm_tis?
> 
> I'm guessing that if the driver probe order is tpm_crb,tpm_tis then
> things work because tpm_crb will claim the device first? Otherwise
> tpm_tis claims these things unconditionally? If the probe order is
> reversed things become broken?
> 
> What is the address tpm_tis should be using? I see two things, it
> either uses the x86 default address or it expects the ACPI to have a
> MEM resource. AFAIK ACPI should never rely on hard wired addresses, so
> I removed that code in this series. Perhaps tpm_tis should be using
> control_area_pa ? Will ACPI ever present a struct resource? (if yes,
> why isn't tpm_crb using one?)

Doesn't also PNP driver do this assumption when the backend is ACPI?

> There is also something wrong with the endianness in the acpi
> stuff. I don't see endianness conversions in other acpi places, so I
> wonder if the ones in tpm_crb are correct. If they are correct then
> the struct needs le/be notations and there are some missing
> conversions.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485

[Matwey V. Kornilov]

2015-12-03 2:20 GMT+03:00 Peter Hurley :
> On 11/18/2015 02:49 PM, Matwey V. Kornilov wrote:
>> 2015-11-18 22:39 GMT+03:00 Matwey V. Kornilov :
>>> 2015-11-18 21:33 GMT+03:00 Peter Hurley :
 On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote:
> 2015-11-16 22:18 GMT+03:00 Peter Hurley :
>> On 11/14/2015 10:25 AM, One Thousand Gnomes wrote:
> [...]
>>> It's also not "easy to drop". If it ever goes in we are stuck with a
>>> pointless impossible to correctly set flag for all eternity.
>>>
>>> Please explain the correct setting for this flag when a device driver
>>> uses hardware or software or a mix according to what the silicon is
>>> capable of and what values are requested ? How will an application use 
>>> the
>>> flag meaningfully. Please explain what will happen if someone discovers 
>>> a
>>> silicon bug and in a future 4.x release turns an implementation from
>>> hardware to software - will they have to lie about the flag to avoid
>>> breaking their application code - that strikes me as a bad thing.
>>
>> The existing driver behavior is already significantly variant and needs
>> to be converged, which shouldn't be too difficult. Here's a quick 
>> summary:
>>
>> mcfuart ignores delay values, delays unsupported
>> imx clamps delay values to 0, delays unsupported
>> atmel   only delay_rts_after_send used; delay_rts_before_send 
>> does nothing
>> 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs
>> omap-serial*software emulation (but tx empty polling not reqd)
>> lpc18xx-uartclamps delay_rts_before_send to 0, unsupported
>> clamps delay_rts_after_send to max h/w value
>> max310x returns -ERANGE if either delay value > h/w support (15 
>> msecs)
>> sc16is7xx*  returns -EINVAL if delay_rts_after_send is set
>> crisv10*clamps delay_rts_before_send to 1000 msecs
>> ignores delays_rts_after_send (after dma is delayed by 2 
>> * chars)
>> * implements delay(s) in software
>>
>> The omap-serial emulation should not have been merged in its current 
>> form.
>>
>> IMO the proper driver behavior should be clamp to h/w limit so an 
>> application
>> can determine the maximum delay supported. If a delay is unsupported, it 
>> should
>> be clamped to 0. The application should check the RS485 settings 
>> returned by
>> TIOCSRS485 to determine how the driver set them.
>> [ Documentation/serial/serial-rs485.txt should suggest/model this action 
>> ]
>
> But the similar could be true for minimal supported delay. If user
> requires delay which is less than lower bound, the delay is raised to
> the lower bound. If user requires delay which is greater than upper
> bound, the delay is set to the upper bound. Then software
> implementation could use (tx fifo size / baudrate) as lower bound for
> delay_after_send.

 From the application point-of-view (really the only relevant semantics),
 delay_dts_after_send refers to the number of milliseconds to delay the
 toggle of RTS after the last bit has been _transmitted_.
>
> Is there consensus then about what the semantics of unsupported RS485 delay
> values are? I (or someone else) can trivially add the documentation and
> fixes to the existing in-tree drivers.
>
>
 A couple of possibilities for improving the emulation are:
 1) Optionally using an HR timer for sub-jiffy turnaround.
 2) Only supporting 8250-based hardware that can be set to interrupt when
both tx fifo and transmitter shift register are empty.
>>>
>>> This is to support the RS485 API with already exists in omap_serrial,
>>> but not in 8250_omap. And OMAP does not support tx line interrupt in
>>> UART mode. So the latter is not an option.
>>
>> Oh, I am sorry, it does support. There is "Supplementary Control
>> Register" described in 19.5.1.39
>
> For the moment then, can we add a UART_CAP_SW485 (not exposed to userspace)
> that enables this algorithm only for h/w that supports a both-empty interrupt
> mode. The probe or driver (ala 8250_omap) would opt-in and configure the h/w 
> much
> like the omap-serial driver does now (with the SCR register).
>
> Does that seem like an acceptable compromise?
>
> Regards,
> Peter Hurley
>
> PS - I still need to review this series for how the timer logic works esp. wrt
> teardown.
>

Dear Peter,

I am working on v4, where I completely redesigned implementation. And
now I think that it is considerably better than v3.
It looks like the following:
https://github.com/matwey/linux/commits/8520_rs485_v4
But it is not ready yet, there is a bug somewhere.

In the v4, each subdriver decides separately if it needs rs485
emulation support. Then it enables it like the following:

[PATCH 0/2] regmap: mmio: clean up the code

[Xiubo Li]

Xiubo Li (2):
  regmap: mmio: remove the useless code
  regmap: mmio: Add regmap_mmio_get_min_stride

 drivers/base/regmap/regmap-mmio.c | 50 +++
 1 file changed, 30 insertions(+), 20 deletions(-)

-- 
1.8.3.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] regmap: mmio: remove the useless code

[Xiubo Li]

Signed-off-by: Xiubo Li 
---
 drivers/base/regmap/regmap-mmio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-mmio.c 
b/drivers/base/regmap/regmap-mmio.c
index 426a57e..38d0dc0 100644
--- a/drivers/base/regmap/regmap-mmio.c
+++ b/drivers/base/regmap/regmap-mmio.c
@@ -247,7 +247,6 @@ static struct regmap_mmio_context 
*regmap_mmio_gen_context(struct device *dev,
min_stride = 8;
break;
 #endif
-   break;
default:
return ERR_PTR(-EINVAL);
}
-- 
1.8.3.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] regmap: mmio: Add regmap_mmio_get_min_stride

[Xiubo Li]

Splite the minimal stride parsing into one signal function.

Signed-off-by: Xiubo Li 
---
 drivers/base/regmap/regmap-mmio.c | 49 ---
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/base/regmap/regmap-mmio.c 
b/drivers/base/regmap/regmap-mmio.c
index 38d0dc0..eea5156 100644
--- a/drivers/base/regmap/regmap-mmio.c
+++ b/drivers/base/regmap/regmap-mmio.c
@@ -61,6 +61,33 @@ static int regmap_mmio_regbits_check(size_t reg_bits)
}
 }
 
+static int regmap_mmio_get_min_stride(size_t val_bits)
+{
+   int min_stride;
+
+   switch (val_bits) {
+   case 8:
+   /* The core treats 0 as 1 */
+   min_stride = 0;
+   return 0;
+   case 16:
+   min_stride = 2;
+   break;
+   case 32:
+   min_stride = 4;
+   break;
+#ifdef CONFIG_64BIT
+   case 64:
+   min_stride = 8;
+   break;
+#endif
+   default:
+   return -EINVAL;
+   }
+
+   return min_stride;
+}
+
 static inline void regmap_mmio_count_check(size_t count, u32 offset)
 {
BUG_ON(count <= offset);
@@ -231,25 +258,9 @@ static struct regmap_mmio_context 
*regmap_mmio_gen_context(struct device *dev,
if (config->pad_bits)
return ERR_PTR(-EINVAL);
 
-   switch (config->val_bits) {
-   case 8:
-   /* The core treats 0 as 1 */
-   min_stride = 0;
-   break;
-   case 16:
-   min_stride = 2;
-   break;
-   case 32:
-   min_stride = 4;
-   break;
-#ifdef CONFIG_64BIT
-   case 64:
-   min_stride = 8;
-   break;
-#endif
-   default:
-   return ERR_PTR(-EINVAL);
-   }
+   min_stride = regmap_mmio_get_min_stride(config->val_bits);
+   if (min_stride < 0)
+   return ERR_PTR(min_stride);
 
if (config->reg_stride < min_stride)
return ERR_PTR(-EINVAL);
-- 
1.8.3.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

[Eric Dumazet]

On Wed, 2015-12-02 at 23:38 -0500, David Miller wrote:
> From: Eric Dumazet 
> Date: Sun, 29 Nov 2015 19:37:57 -0800
> 
> > From: Eric Dumazet 
> > 
> > This patch addresses multiple problems :
> > 
> > UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions
> > while socket is not locked : Other threads can change np->opt
> > concurrently. Dmitry posted a syzkaller
> > (http://github.com/google/syzkaller) program desmonstrating
> > use-after-free.
> > 
> > Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock()
> > and dccp_v6_request_recv_sock() also need to use RCU protection
> > to dereference np->opt once (before calling ipv6_dup_options())
> > 
> > This patch adds full RCU protection to np->opt
> > 
> > Reported-by: Dmitry Vyukov 
> > Signed-off-by: Eric Dumazet 
> 
> Applied and queued up for -stable.

Thanks David.

I will send a followup patch, as I missed the sctp part, now triggering
following sparse warnings.

  CHECK   net/sctp/ipv6.c
net/sctp/ipv6.c:223:41: warning: incorrect type in argument 4 (different 
address spaces)
net/sctp/ipv6.c:223:41:expected struct ipv6_txoptions *opt
net/sctp/ipv6.c:223:41:got struct ipv6_txoptions [noderef] *opt
net/sctp/ipv6.c:265:41: warning: incorrect type in argument 2 (different 
address spaces)
net/sctp/ipv6.c:265:41:expected struct ipv6_txoptions const *opt
net/sctp/ipv6.c:265:41:got struct ipv6_txoptions [noderef] *opt
net/sctp/ipv6.c:324:49: warning: incorrect type in argument 2 (different 
address spaces)
net/sctp/ipv6.c:324:49:expected struct ipv6_txoptions const *opt
net/sctp/ipv6.c:324:49:got struct ipv6_txoptions [noderef] *opt



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] Add online file check feature

[Greg KH]

On Wed, Dec 02, 2015 at 07:05:27PM -0700, Gang He wrote:
> Hello Pavel,
> 
> 
> 
> >>> 
> > On Wed 2015-10-28 14:25:57, Gang He wrote:
> >> When there are errors in the ocfs2 filesystem,
> >> they are usually accompanied by the inode number which caused the error.
> >> This inode number would be the input to fixing the file.
> >> One of these options could be considered:
> >> A file in the sys filesytem which would accept inode numbers.
> >> This could be used to communication back what has to be fixed or is fixed.
> >> You could write:
> >> $# echo "CHECK " > /sys/fs/ocfs2/devname/filecheck
> >> or
> >> $# echo "FIX " > /sys/fs/ocfs2/devname/filecheck
> >> 
> > 
> > Are you sure this is reasonable interface? I mean sysfs is
> > supposed to be one value per file. And I don't think its suitable for
> > running commands.
> Usually, the corrupted file (inode) should be rarely encountered for OCFS2 
> file system, then
> lots of commands are executed via this interface with high performance is not 
> expected by us.
> Second, after online file check is added, we also plan to add a mount option 
> "error=fix", that means
> the file system can fix these errors automatically without a manual command 
> triggering.

It's not a "performance" issue, it's a "sysfs files only have one value"
type thing.  Have two files, "inode_fix" and "inode_check" and then just
write the inode into them, no need to have a "verb " type parser.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: uniphier: add clock drivers for UniPhier SoCs

[Masahiro Yamada]

This is the initial commit for the UniPhier clock drivers, including
support for PH1-sLD3, PH1-LD4, PH1-Pro4, PH1-sLD8, PH1-Pro5, and
ProXstream2/PH1-LD6b.

To improve the code maintainability, the driver consists of common
functions (clk-uniphier-core.c) and clock data arrays needed to
support each SoC.

Signed-off-by: Masahiro Yamada 
---

 MAINTAINERS  |   1 +
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   1 +
 drivers/clk/uniphier/Kconfig |  35 ++
 drivers/clk/uniphier/Makefile|  10 ++
 drivers/clk/uniphier/clk-ph1-ld4.c   | 117 ++
 drivers/clk/uniphier/clk-ph1-pro4.c  | 117 ++
 drivers/clk/uniphier/clk-ph1-pro5.c  | 107 
 drivers/clk/uniphier/clk-ph1-sld3.c  | 117 ++
 drivers/clk/uniphier/clk-ph1-sld8.c  | 107 
 drivers/clk/uniphier/clk-proxstream2.c   |  88 +
 drivers/clk/uniphier/clk-uniphier-core.c | 150 ++
 drivers/clk/uniphier/clk-uniphier-mio.c  | 206 +++
 drivers/clk/uniphier/clk-uniphier-peri.c | 175 ++
 drivers/clk/uniphier/clk-uniphier.h  |  68 ++
 15 files changed, 1300 insertions(+)
 create mode 100644 drivers/clk/uniphier/Kconfig
 create mode 100644 drivers/clk/uniphier/Makefile
 create mode 100644 drivers/clk/uniphier/clk-ph1-ld4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro4.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-pro5.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld3.c
 create mode 100644 drivers/clk/uniphier/clk-ph1-sld8.c
 create mode 100644 drivers/clk/uniphier/clk-proxstream2.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-core.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-mio.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier-peri.c
 create mode 100644 drivers/clk/uniphier/clk-uniphier.h

diff --git a/MAINTAINERS b/MAINTAINERS
index cba790b..1c6edc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
 F: arch/arm/include/asm/hardware/cache-uniphier.h
 F: arch/arm/mach-uniphier/
 F: arch/arm/mm/cache-uniphier.c
+F: drivers/clk/uniphier/
 F: drivers/i2c/busses/i2c-uniphier*
 F: drivers/pinctrl/uniphier/
 F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02..7580323 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -191,6 +191,7 @@ config COMMON_CLK_CDCE706
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
 source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/uniphier/Kconfig"
 
 endmenu
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..ab9d1bd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_ARCH_STI)+= st/
 obj-$(CONFIG_ARCH_SUNXI)   += sunxi/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-$(CONFIG_ARCH_OMAP2PLUS)   += ti/
+obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_ARCH_U8500)   += ux500/
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_X86)  += x86/
diff --git a/drivers/clk/uniphier/Kconfig b/drivers/clk/uniphier/Kconfig
new file mode 100644
index 000..7606f27
--- /dev/null
+++ b/drivers/clk/uniphier/Kconfig
@@ -0,0 +1,35 @@
+menuconfig CLK_UNIPHIER
+   bool "Clock drivers for UniPhier SoCs"
+   depends on ARCH_UNIPHIER
+   depends on OF
+   default y
+   help
+ Supports clock drivers for UniPhier SoCs.
+
+if CLK_UNIPHIER
+
+config CLK_UNIPHIER_PH1_SLD3
+   bool "Clock driver for UniPhier PH1-sLD3 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_LD4
+   bool "Clock driver for UniPhier PH1-LD4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO4
+   bool "Clock driver for UniPhier PH1-Pro4 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_SLD8
+   bool "Clock driver for UniPhier PH1-sLD8 SoC"
+   default y
+
+config CLK_UNIPHIER_PH1_PRO5
+   bool "Clock driver for UniPhier PH1-Pro5 SoC"
+   default y
+
+config CLK_UNIPHIER_PROXSTREAM2
+   bool "Clock driver for UniPhier ProXstream2/PH1-LD6b SoC"
+   default y
+
+endif
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
new file mode 100644
index 000..3be1a17
--- /dev/null
+++ b/drivers/clk/uniphier/Makefile
@@ -0,0 +1,10 @@
+obj-y += clk-uniphier-core.o
+obj-y += clk-uniphier-peri.o
+obj-y += clk-uniphier-mio.o
+
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD3)+= clk-ph1-sld3.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_LD4) += clk-ph1-ld4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_PRO4)+= clk-ph1-pro4.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_SLD8)+= clk-ph1-sld8.o
+obj-$(CONFIG_CLK_UNIPHIER_PH1_PRO5)+= clk-ph1-pro5.o

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi,

On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> Hi,
> 
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
> 
> - Establish a custom interface between NAND and GPMC driver. This is
> needed because all of the NAND registers sit in the GPMC register space.
> Some bits like NAND IRQ are even shared with GPMC.
> 
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> driver can be used on non-OMAP platforms. e.g. Keystone.
> 
> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> 2 to 4 of these and most of them would be unused otherwise. It also
> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
> 
> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> 
> This series is available at
> g...@github.com:rogerq/linux.git
> in branch
> for-v4.4/gpmc-v3
> 
> cheers,
> -roger
> 
> Changelog:
> v3:
> -Fixed and tested NAND using legacy boot on omap3-beagle.
> -Support rising and falling edge interrupts on WAITpins.
> -Update DT node of all gpmc users.

The MTD stuff looks mostly good to me know. I've made all my comments
for now, but I'm not sure how you're going to end up rebasing/splitting
and what you're going to do with the irqchip removal, so I'll refrain
from ack's for now. Hopefully I can either ack or merge v4.

I brought it up on one other patch, but it's not really clear to me what
the split is on board file vs. device tree handling, since you seem to
have a combination of both (i.e., platform data that passes along device
nodes). What's the plan on that?

And of course, there's the question of how exactly to merge this, given
the:
(1) conflicts already existing in the MTD dev tree
(2) this touches several trees, often in the same patch and
(3) even if the patches were split out a little better into MTD and
non-MTD stuff, I think there would still be dependencies such that
we'd need at least 1 (probably 2) cross merges to get it all
straight

I'd be happy to hear your thoughts.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv7 2/2] mailbox: Adding driver for Xilinx LogiCORE IP mailbox.

[Jassi Brar]

On 2 December 2015 at 22:56, Moritz Fischer  wrote:
> Hi Jassi,
>
> thanks for your feedback.
>
> On Mon, Aug 10, 2015 at 1:05 AM, Jassi Brar  wrote:
>> On Wed, Jul 15, 2015 at 6:30 AM, Moritz Fischer
>>  wrote:
>>
>>> +
>>> +static void xilinx_mbox_rx_data(struct mbox_chan *chan)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +   u32 data;
>>> +
>>> +   if (xilinx_mbox_pending(mbox)) {
>>> +   data = readl_relaxed(mbox->mbox_base + MAILBOX_REG_RDDATA);
>>> +   mbox_chan_received_data(chan, (void *)data);
>>>
>> If RDDATA is a FIFO, then above seems wrong - you are assuming
>> messages are always going to be exactly 32-bits for every protocol.
>> Ideally you should empty the fifo fully, at least when RX has an
>> interrupt.
>
> From my understanding it's hard to tell how much actually is in the fifo,
> you can tell if it's full for send direction, or empty for read direction.
>
Simply read the whole FIFO and leave it to the client driver to parse
that data according to the protocol it drives.

> Maybe the STI / RTI can be setup in a smart way to work with multiple message
> sizes.
>>
>>> +
>>> +static int xilinx_mbox_irq_send_data(struct mbox_chan *chan, void *data)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +   u32 *udata = data;
>>> +
>>> +   if (xilinx_mbox_full(mbox))
>>> +   return -EBUSY;
>>>
>> This check is redundant. last_tx_done already makes sure this is always true.
>
> Good to know. I'll fix it.
>>
>>> +   /* enable interrupt before send */
>>> +   xilinx_mbox_tx_intmask(mbox, true);
>>> +
>>> +   writel_relaxed(*udata, mbox->mbox_base + MAILBOX_REG_WRDATA);
>>> +
>> From status EMPTY and FULL, it seems WRDATA is a FIFO. So here also
>> you should expect messages to be <= fifo depth. And not assume exactly
>> 32bit messages always.
>
> How do I determine the message size?
>
Always expect any write request is exactly the size of FIFO depth.

> Doesn't
> drivers/mailbox/bcm2835-mailbox.c or
>
Well I did point it out
http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-June/001902.html
 ... but developer assumes there will _never_ be need to pass a
message bigger than 32-bits. Sadly overlooking the possibility that
some protocol might have simple, say, 64-bits wide commands and
responses that could avoid using any Shared-Memory at all.

> mailbox-altera.c make the same assumption?
>
There are 2 registers, for CMD and PRT each, that make up 1 message.
It doesn't seem like a fifo.

>>
>>> +
>>> +static bool xilinx_mbox_last_tx_done(struct mbox_chan *chan)
>>> +{
>>> +   struct xilinx_mbox *mbox = mbox_chan_to_xilinx_mbox(chan);
>>> +
>>> +   /* return false if mailbox is full */
>>> +   return !xilinx_mbox_full(mbox);
>>>
>> Instead of FULL, I think it should check for stricter EMPTY status ...
>> mbox api submits only 1 message at a time.
>
> The EMPTY status applies to the receive direction only, I could check
> the STI status
> bit though I suppose.
>
I don't know the h/w but you get my idea. So whatever is in the next revision.

> [...]
>>> +
>>> +   mbox->irq = platform_get_irq(pdev, 0);
>>> +   /* if irq is present, we can use it, otherwise, poll */
>>> +   if (mbox->irq > 0) {
>>> +   mbox->controller.txdone_irq = true;
>>> +   mbox->controller.ops = _mbox_irq_ops;
>>> +   } else {
>>> +   dev_info(>dev, "IRQ not found, fallback to 
>>> polling.\n");
>>> +   mbox->controller.txdone_poll = true;
>>> +   mbox->controller.txpoll_period = MBOX_POLLING_MS;
>>> +   mbox->controller.ops = _mbox_poll_ops;
>>> +
>>> +   setup_timer(>rxpoll_timer, xilinx_mbox_poll_rx,
>>> +   (unsigned long)>chan);
>>>
>> I believe there is indeed some platform that doesn't have RX-Interrupt?
>>  If no, please remove this.
>>  If yes, you may want to get some hint from platform about the size of
>> messages and do mbox_chan_received_data() only upon reading those many
>> bytes.
>
> I'd be fine to drop the polling use case for the moment, on my
> platform I can wire up the IRQ.
> We can always add it back in in a follow up use case.
>

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers

[Brian Norris]

On Fri, Sep 18, 2015 at 05:53:26PM +0300, Roger Quadros wrote:
> Deprecate nand register passing via platform data and use
> gpmc_omap_get_nand_ops() instead.
> 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/mach-omap2/gpmc-nand.c  | 2 --
>  drivers/mtd/nand/omap2.c | 9 -
>  include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
>  3 files changed, 11 insertions(+), 4 deletions(-)

This one also seems a bit oddly-split, if you're trying to allow
bringing these into different trees. The nand/omap2.c changes seem like
they can be done completely on their own (after the previous patches),
and the arch/arm/mach-omap2/gpmc-nand.c and
include/linux/platform_data/mtd-nand-omap2.h changes can come in their
own patch afterward.

That does still make things a little complicated for applying to
different trees, though, as we have some arch/arm -> drivers/mtd ->
arch/arm dependencies.

If it helps, I can try to provide Tony with a stable v4.4-rc1-based
piece of the MTD tree, and just take everything through there (with
acks). (FWIW, everything in l2-mtd.git can be considered stable,
git-wise. I've been keeping a clean history. But it'd be best to
coordinate what points to cross-merge.)

Then if we do that, we'd have to keep a close eye to make sure I don't
take any more conflicting changes to drivers/mtd/nand/omap2.c, or else
do another cross-merge...

Any better suggestions?

Brian

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index 72918c4..04e6998 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   if (err < 0)
>   goto out_free_cs;
>  
> - gpmc_update_nand_reg(_nand_data->reg, gpmc_nand_data->cs);
> -
>   if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
>   pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
>   err = -EINVAL;
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 60fa899..f214fe2 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #define  DRIVER_NAME "omap2-nand"
> @@ -169,7 +170,9 @@ struct omap_nand_info {
>   } iomode;
>   u_char  *buf;
>   int buf_len;
> + /* Interface to GPMC */
>   struct gpmc_nand_regs   reg;
> + struct gpmc_nand_ops*ops;
>   /* generated at runtime depending on ECC algorithm and layout selected 
> */
>   struct nand_ecclayout   oobinfo;
>   /* fields specific for BCHx_HW ECC scheme */
> @@ -1677,9 +1680,13 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, info);
>  
> + info->ops = gpmc_omap_get_nand_ops(>reg, info->gpmc_cs);
> + if (!info->ops) {
> + dev_err(>dev, "Failed to get GPMC->NAND interface\n");
> + return -ENODEV;
> + }
>   info->pdev  = pdev;
>   info->gpmc_cs   = pdata->cs;
> - info->reg   = pdata->reg;
>   info->of_node   = pdata->of_node;
>   info->ecc_opt   = pdata->ecc_opt;
>   mtd = >mtd;
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> b/include/linux/platform_data/mtd-nand-omap2.h
> index 090bbab..a067f58 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -75,10 +75,12 @@ struct omap_nand_platform_data {
>   enum nand_ioxfer_type;
>   int devsize;
>   enum omap_ecc   ecc_opt;
> - struct gpmc_nand_regs   reg;
>  
>   /* for passing the partitions */
>   struct device_node  *of_node;
>   struct device_node  *elm_of_node;
> +
> + /* deprecated */
> + struct gpmc_nand_regs   reg;
>  };
>  #endif
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] sfc: use ALIGN macro for aligning frame sizes

[David Miller]

From: Jarod Wilson 
Date: Mon, 30 Nov 2015 17:12:21 -0500

> Don't open-code it.
> 
> CC: Solarflare linux maintainers 
> CC: Shradha Shah 
> CC: net...@vger.kernel.org
> Signed-off-by: Jarod Wilson 

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI: Add phylib support code for mdio

[kbuild test robot]

Hi yankejian,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.4-rc3 next-20151202]

url:
https://github.com/0day-ci/linux/commits/yankejian/ACPI-Add-phylib-support-code-for-mdio/20151203-115039
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: i386-randconfig-i0-201548 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `acpi_mdiobus_register_phy':
>> acpi_mdio.c:(.text+0x2de27): undefined reference to `get_phy_device'
>> acpi_mdio.c:(.text+0x2de84): undefined reference to `phy_device_register'
>> acpi_mdio.c:(.text+0x2de8f): undefined reference to `phy_device_free'
   drivers/built-in.o: In function `acpi_phy_find_device':
>> (.text+0x2dee4): undefined reference to `mdio_bus_type'
   drivers/built-in.o: In function `acpi_phy_attach':
>> (.text+0x2df25): undefined reference to `phy_attach_direct'
   drivers/built-in.o: In function `acpi_phy_connect':
>> (.text+0x2df71): undefined reference to `phy_connect_direct'
   drivers/built-in.o: In function `acpi_mdiobus_register':
>> (.text+0x2e01a): undefined reference to `__mdiobus_register'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] net: smc911x: convert pxa dma to dmaengine

[David Miller]

From: Robert Jarzmik 
Date: Mon, 30 Nov 2015 22:40:28 +0100

> Convert the dma transfers to be dmaengine based, now pxa has a dmaengine
> slave driver. This makes this driver a bit more PXA agnostic.
> 
> The driver was only compile tested. The risk is quite small as no
> current PXA platform I'm aware of is using smc911x driver.
> 
> Signed-off-by: Robert Jarzmik 

I've marked this 'deferred' in patchwork until someone tests
these changes and says they should be good on all platforms
this chip is used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

[David Miller]

From: ebied...@xmission.com (Eric W. Biederman)
Date: Mon, 30 Nov 2015 15:38:15 -0600

> + if (dev_net(br->dev) == _net)

Please respin this using net_eq() as Hannes pointed out.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mfd: mc13xxx-core: use of_property_read_bool()

[Saurabh Sengar]

I couldn't see this patch applied in linux-next branch still.

Regards,
Saurabh

On 24 November 2015 at 21:59, Lee Jones  wrote:
> On Mon, 16 Nov 2015, Saurabh Sengar wrote:
>
>> for checking if a property is present or not,
>> use of_property_read_bool instead of of_get_property()
>>
>> Signed-off-by: Saurabh Sengar 
>> ---
>>  drivers/mfd/mc13xxx-core.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> I'm fine with the change, but in future please use the commit format
> expected of the subsystem.  In this case, you are missing upper-case
> characters at the start of the subject line AND the start of the
> commit log.  In fact, it is devoid of sufficient punctuation in
> general.
>
> I have applied this and fixed up the issues; this time!
>
>> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
>> index 3f9f4c8..d7f54e4 100644
>> --- a/drivers/mfd/mc13xxx-core.c
>> +++ b/drivers/mfd/mc13xxx-core.c
>> @@ -383,16 +383,16 @@ static int mc13xxx_probe_flags_dt(struct mc13xxx 
>> *mc13xxx)
>>   if (!np)
>>   return -ENODEV;
>>
>> - if (of_get_property(np, "fsl,mc13xxx-uses-adc", NULL))
>> + if (of_property_read_bool(np, "fsl,mc13xxx-uses-adc"))
>>   mc13xxx->flags |= MC13XXX_USE_ADC;
>>
>> - if (of_get_property(np, "fsl,mc13xxx-uses-codec", NULL))
>> + if (of_property_read_bool(np, "fsl,mc13xxx-uses-codec"))
>>   mc13xxx->flags |= MC13XXX_USE_CODEC;
>>
>> - if (of_get_property(np, "fsl,mc13xxx-uses-rtc", NULL))
>> + if (of_property_read_bool(np, "fsl,mc13xxx-uses-rtc"))
>>   mc13xxx->flags |= MC13XXX_USE_RTC;
>>
>> - if (of_get_property(np, "fsl,mc13xxx-uses-touch", NULL))
>> + if (of_property_read_bool(np, "fsl,mc13xxx-uses-touch"))
>>   mc13xxx->flags |= MC13XXX_USE_TOUCHSCREEN;
>>
>>   return 0;
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Brian Norris]

(to be clear, this branch of discussion isn't directly regarding the TI
changes; we can handle any generic handling afterward, as long as we get
the DT binding right now)

On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> On Mon, 26 Oct 2015 13:49:00 -0700
> Brian Norris  wrote:
> > On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   info->reg = pdata->reg;
> > >   info->of_node = pdata->of_node;
> > >   info->ecc_opt = pdata->ecc_opt;
> > > - info->dev_ready = pdata->dev_ready;
> > > + if (pdata->dev_ready)
> > > + dev_info(>dev, "pdata->dev_ready is 
> > > deprecated\n");
> > > +
> > >   info->xfer_type = pdata->xfer_type;
> > >   info->devsize = pdata->devsize;
> > >   info->elm_of_node = pdata->elm_of_node;
> > > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> > > *pdev)
> > >   nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > >   nand_chip->cmd_ctrl  = omap_hwcontrol;
> > >  
> > > + info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > > + GPIOD_IN);
> > 
> > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > minimum, we need an updated DT binding doc for this, since I see you're
> > adding this via device tree in a later patch (I don't see any DT binding
> > patch for this; but I could just be overlooking it). It'd also be great
> > if this support was moved to nand_dt_init() so other platforms can
> > benefit, but I won't require that.
> 
> Actually I started to work on a generic solution parsing the DT and
> creating CS, WP and RB gpios when they are provided, but I think it's a
> bit more complicated than just moving the rb-gpios parsing into
> nand_dt_init().
> First you'll need something to store your gpio_desc pointers, which
> means you'll have to allocate a table of gpio_desc pointers (or a table
> of struct embedding a gpio_desc pointer).

I'm not sure what you mean by table. It seems like we would just have a
few gpio_desc pointers in struct nand_chip, no?

> The other blocking point is that when nand_scan_ident() is called, the
> caller is supposed to have filled the ->dev_ready() or ->waitfunc()
> fields, and to choose how to implement it he may need to know
> which kind of RB handler should be used (this is the case in the sunxi
> driver, where the user can either use a GPIO or native R/B pin directly
> connected to the controller).

Right, I was thinking about this one.

> All this makes me think that maybe nand_dt_init() should be called
> separately or in a different helper (nand_init() ?) taking care of the
> basic nand_chip initializations/allocations without interacting with
> the NAND itself.

Yeah, I feel like there have been other good reasons for something like
this before, and we just have worked around them so far. Maybe something
more like the alloc/add split in many other subsystems? e.g.,
platform_device_{alloc,add}, spi_{alloc,add}_device. Now we might want
nand_alloc()?

On a slight tangent, it seems silly that nand_scan_tail() doesn't
register the MTD, but nand_release() unregisters it. That shouldn't be.

> Another solution would be to add an ->init() function to nand_chip
> and call it after the generic initialization has been done (but before
> NAND chip detection). This way the NAND controller driver could adapt
> some fields and parse controller specific properties.

That could work too, I guess.

> What do you think?

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI: Add phylib support code for mdio

[kbuild test robot]

Hi yankejian,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.4-rc3 next-20151202]

url:
https://github.com/0day-ci/linux/commits/yankejian/ACPI-Add-phylib-support-code-for-mdio/20151203-115039
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: i386-randconfig-s1-201548 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> make[3]: *** No rule to make target 'drivers/acpi/mcfg.o', needed by 
>> 'drivers/acpi/built-in.o'.
   make[3]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 2/3] sched/cpupri: Cleanup of duplicate memory initialization

[Xunlei Pang]

There is already a memset clear operation for '*cp', so we can use
alloc_cpumask_var() with __GFP_ZERO instead of zalloc_cpumask_var()
to avoid duplicate clear for systems without CONFIG_CPUMASK_OFFSTACK
set.

Also omit "atomic_set(>count, 0);".

Signed-off-by: Xunlei Pang 
---
 kernel/sched/cpupri.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/cpupri.c b/kernel/sched/cpupri.c
index 981fcd7..b8f73a7 100644
--- a/kernel/sched/cpupri.c
+++ b/kernel/sched/cpupri.c
@@ -214,8 +214,7 @@ int cpupri_init(struct cpupri *cp)
for (i = 0; i < CPUPRI_NR_PRIORITIES; i++) {
struct cpupri_vec *vec = >pri_to_cpu[i];
 
-   atomic_set(>count, 0);
-   if (!zalloc_cpumask_var(>mask, GFP_KERNEL))
+   if (!alloc_cpumask_var(>mask, GFP_KERNEL | __GFP_ZERO))
goto cleanup;
}
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] sched/cpudeadline: Cleanup of duplicate memory initialization

[Xunlei Pang]

There is already a memset clear operation for '*cp', so we can use
alloc_cpumask_var() with __GFP_ZERO instead of zalloc_cpumask_var()
to avoid duplicate clear for systems without CONFIG_CPUMASK_OFFSTACK
set.

Also omit "cp->size = 0;".

Signed-off-by: Xunlei Pang 
---
 kernel/sched/cpudeadline.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 5a75b08..ca780ec 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -211,7 +211,6 @@ int cpudl_init(struct cpudl *cp)
 
memset(cp, 0, sizeof(*cp));
raw_spin_lock_init(>lock);
-   cp->size = 0;
 
cp->elements = kcalloc(nr_cpu_ids,
   sizeof(struct cpudl_item),
@@ -219,7 +218,7 @@ int cpudl_init(struct cpudl *cp)
if (!cp->elements)
return -ENOMEM;
 
-   if (!zalloc_cpumask_var(>free_cpus, GFP_KERNEL)) {
+   if (!alloc_cpumask_var(>free_cpus, GFP_KERNEL | __GFP_ZERO)) {
kfree(cp->elements);
return -ENOMEM;
}
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] sched/core: Clear the root_domain cpumasks in init_rootdomain()

[Xunlei Pang]

root_domain::rto_mask allocated through alloc_cpumask_var()
contains garbage data with CONFIG_CPUMASK_OFFSTACK set, this
may cause problems. For instance, When doing pull_rt_task(),
it may do useless iterations if rto_mask retains some extra
garbage bits. Worse still, this can violate the isolated domain
rule for clustered scheduling using cpuset, because the tasks
(with all the cpus allowed) which belongs to one root domain
can be pulled away into another root domain.

The patch cleans the garbage by passing alloc_cpumask_var()
with an extra __GFP_ZERO for root_domain::rto_mask allocation,
thereby addressing the issues.

Do the same thing for root_domain's other cpumask memembers:
dlo_mask, span, and online.

Signed-off-by: Xunlei Pang 
---
v1->v2:
Use alloc_cpumask_var() with __GFP_ZERO instead of zalloc_cpumask_var()
to avoid duplicate clean for systems without CONFIG_CPUMASK_OFFSTACK set.

 kernel/sched/core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5b420d2..c11e11e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5858,13 +5858,13 @@ static int init_rootdomain(struct root_domain *rd)
 {
memset(rd, 0, sizeof(*rd));
 
-   if (!alloc_cpumask_var(>span, GFP_KERNEL))
+   if (!alloc_cpumask_var(>span, GFP_KERNEL | __GFP_ZERO))
goto out;
-   if (!alloc_cpumask_var(>online, GFP_KERNEL))
+   if (!alloc_cpumask_var(>online, GFP_KERNEL | __GFP_ZERO))
goto free_span;
-   if (!alloc_cpumask_var(>dlo_mask, GFP_KERNEL))
+   if (!alloc_cpumask_var(>dlo_mask, GFP_KERNEL | __GFP_ZERO))
goto free_online;
-   if (!alloc_cpumask_var(>rto_mask, GFP_KERNEL))
+   if (!alloc_cpumask_var(>rto_mask, GFP_KERNEL | __GFP_ZERO))
goto free_dlo_mask;
 
init_dl_bw(>dl_bw);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support

[Anand Moon]

Hi Ben Gamari,

On 3 December 2015 at 02:49, Ben Gamari  wrote:
> From: Bartlomiej Zolnierkiewicz 
>
> Add cluster regulator support as a preparation to adding
> generic arm_big_little_dt cpufreq_dt driver support for
> ODROID-XU3 board.  This allows arm_big_little[_dt] driver
> to set not only the frequency but also the voltage (which
> is obtained from operating point's voltage value) for CPU
> clusters.
>
> Cc: Kukjin Kim 
> Cc: Doug Anderson 
> Cc: Javier Martinez Canillas 
> Cc: Andreas Faerber 
> Cc: Sachin Kamat 
> Cc: Thomas Abraham 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Ben Gamari 
> ---
>  .../bindings/cpufreq/arm_big_little_dt.txt |   4 +
>  drivers/cpufreq/arm_big_little.c   | 155 
> ++---
>  2 files changed, 142 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt 
> b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> index 0715695..8ca4a12 100644
> --- a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> @@ -18,6 +18,10 @@ Required properties:
>  Optional properties:
>  - clock-latency: Specify the possible maximum transition latency for clock,
>in unit of nanoseconds.
> +- cpu-cluster.0-supply: Provides the regulator node supplying voltage to CPU
> +  cluster 0.
> +- cpu-cluster.1-supply: Provides the regulator node supplying voltage to CPU
> +  cluster 1.
>
>  Examples:
>
> diff --git a/drivers/cpufreq/arm_big_little.c 
> b/drivers/cpufreq/arm_big_little.c
> index c5d256c..855599b 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "arm_big_little.h"
>
> @@ -57,6 +58,9 @@ static bool bL_switching_enabled;
>
>  static struct cpufreq_arm_bL_ops *arm_bL_ops;
>  static struct clk *clk[MAX_CLUSTERS];
> +static struct regulator *reg[MAX_CLUSTERS];
> +static struct device *cpu_devs[MAX_CLUSTERS];
> +static int transition_latencies[MAX_CLUSTERS];
>  static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
>  static atomic_t cluster_usage[MAX_CLUSTERS + 1];
>
> @@ -125,6 +129,75 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
> }
>  }
>
> +static int
> +bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> +{
> +   unsigned long volt = 0, volt_old = 0;
> +   long freq_Hz;
> +   u32 old_rate;
> +   int ret;
> +
> +   freq_Hz = new_rate * 1000;
> +   old_rate = clk_get_rate(clk[cluster]) / 1000;
> +
> +   if (!IS_ERR(reg[cluster])) {
> +   struct dev_pm_opp *opp;
> +   unsigned long opp_freq;
> +
> +   rcu_read_lock();
> +   opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster], _Hz);
> +   if (IS_ERR(opp)) {
> +   rcu_read_unlock();
> +   pr_err("%s: cpu %d, cluster: %d, failed to find OPP 
> for %ld\n",
> +   __func__, cpu, cluster, freq_Hz);
> +   return PTR_ERR(opp);
> +   }
> +   volt = dev_pm_opp_get_voltage(opp);
> +   opp_freq = dev_pm_opp_get_freq(opp);
> +   rcu_read_unlock();
> +   volt_old = regulator_get_voltage(reg[cluster]);
> +   pr_debug("%s: cpu %d, cluster: %d, Found OPP: %ld kHz, %ld 
> uV\n",
> +   __func__, cpu, cluster, opp_freq / 1000, volt);
> +   }
> +
> +   pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld 
> mV\n",
> +   __func__, cpu, cluster,
> +   old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
> +   new_rate / 1000, volt ? volt / 1000 : -1);
> +
> +   /* scaling up? scale voltage before frequency */
> +   if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
> +   ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> +   if (ret) {
> +   pr_err("%s: cpu: %d, cluster: %d, failed to scale 
> voltage up: %d\n",
> +   __func__, cpu, cluster, ret);
> +   return ret;
> +   }
> +   }
> +
> +   ret = clk_set_rate(clk[cluster], new_rate * 1000);
> +   if (WARN_ON(ret)) {
> +   pr_err("%s: clk_set_rate failed: %d, cluster: %d\n",
> +   __func__, cluster, ret);
> +   if (!IS_ERR(reg[cluster]) && volt_old > 0)
> +   regulator_set_voltage_tol(reg[cluster], volt_old, 0);
> +   return ret;
> +   }
> +
> +   /* scaling down? scale voltage after frequency */
> +   if (!IS_ERR(reg[cluster]) && new_rate < old_rate) {
> +   ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> +   if (ret) {
> +   pr_err("%s: cpu: 

Re: [PATCH] sctp: use GFP_USER for user-controlled kmalloc

[David Miller]

From: Marcelo Ricardo Leitner 
Date: Mon, 30 Nov 2015 14:32:54 -0200

> Dmitry Vyukov reported that the user could trigger a kernel warning by
> using a large len value for getsockopt SCTP_GET_LOCAL_ADDRS, as that
> value directly affects the value used as a kmalloc() parameter.
> 
> This patch thus switches the allocation flags from all user-controllable
> kmalloc size to GFP_USER to put some more restrictions on it and also
> disables the warn, as they are not necessary.
> 
> Signed-off-by: Marcelo Ricardo Leitner 
> Acked-by: Daniel Borkmann 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

[David Miller]

From: Eric Dumazet 
Date: Sun, 29 Nov 2015 19:37:57 -0800

> From: Eric Dumazet 
> 
> This patch addresses multiple problems :
> 
> UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions
> while socket is not locked : Other threads can change np->opt
> concurrently. Dmitry posted a syzkaller
> (http://github.com/google/syzkaller) program desmonstrating
> use-after-free.
> 
> Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock()
> and dccp_v6_request_recv_sock() also need to use RCU protection
> to dereference np->opt once (before calling ipv6_dup_options())
> 
> This patch adds full RCU protection to np->opt
> 
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Eric Dumazet 

Applied and queued up for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net] bpf: fix allocation warnings in bpf maps and integer overflow

[David Miller]

From: Alexei Starovoitov 
Date: Sun, 29 Nov 2015 16:59:35 -0800

> From: Alexei Starovoitov 
> 
> For large map->value_size the user space can trigger memory allocation 
> warnings like:
 ...
> To avoid never succeeding kmalloc with order >= MAX_ORDER check that
> elem->value_size and computed elem_size are within limits for both hash and
> array type maps.
> Also add __GFP_NOWARN to kmalloc(value_size | elem_size) to avoid OOM 
> warnings.
> Note kmalloc(key_size) is highly unlikely to trigger OOM, since key_size <= 
> 512,
> so keep those kmalloc-s as-is.
> 
> Large value_size can cause integer overflows in elem_size and map.pages
> formulas, so check for that as well.
> 
> Fixes: aaac3ba95e4c ("bpf: charge user for creation of BPF maps and programs")
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Alexei Starovoitov 

Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline

[Mike Galbraith]

On Wed, 2015-12-02 at 13:41 -0500, Waiman Long wrote:

> By doing so, the perf profile became:
> 
>9.44%   0.00%  java   [kernel.vmlinux]  [k] smp_apic_timer_interrupt
>8.74%   0.01%  java   [kernel.vmlinux]  [k] hrtimer_interrupt
>7.83%   0.03%  java   [kernel.vmlinux]  [k] tick_sched_timer
>7.74%   0.00%  java   [kernel.vmlinux]  [k] update_process_times
>7.27%   0.03%  java   [kernel.vmlinux]  [k] scheduler_tick
>5.94%   1.74%  java   [kernel.vmlinux]  [k] task_tick_fair
>4.15%   3.92%  java   [kernel.vmlinux]  [k] update_cfs_shares
> 
> The %cpu time is still pretty high, but it is better than before.

Is that with the box booted skew_tick=1?

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

[Brian Norris]

Hi Roger,

On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
> 
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
> 
> Signed-off-by: Roger Quadros 

This one's going to need rebased, as there are some conflicting of_node
changes in l2-mtd.git.

> ---
> v4: Warn if using older incompatible DT i.e. compatible property not present
> in nand node.
> 
>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>  drivers/memory/omap-gpmc.c   | 143 
> +++
>  drivers/mtd/nand/omap2.c | 136 +
>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>  4 files changed, 155 insertions(+), 132 deletions(-)

Also, this is going to be hard to manage across trees, as you touch
three drivers all at once. Is it not possible to split any of this apart
better?

> 
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index ffe646a..e07ca27 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
> *gpmc_nand_data,
>   gpmc_nand_res[1].start = gpmc_get_irq();
>  
>   memset(, 0, sizeof(struct gpmc_settings));
> - if (gpmc_nand_data->of_node)
> - gpmc_read_settings_dt(gpmc_nand_data->of_node, );
> - else
> - gpmc_set_legacy(gpmc_nand_data, );
> + gpmc_set_legacy(gpmc_nand_data, );
>  
>   s.device_nand = true;
>  
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index e75226d..318c187 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -29,7 +29,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -1716,105 +1715,6 @@ static void __maybe_unused 
> gpmc_read_timings_dt(struct device_node *np,
>   of_property_read_bool(np, "gpmc,time-para-granularity");
>  }
>  
> -#if IS_ENABLED(CONFIG_MTD_NAND)
> -
> -static const char * const nand_xfer_types[] = {
> - [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
> - [NAND_OMAP_POLLED]  = "polled",
> - [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
> - [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
> -};
> -
> -static int gpmc_probe_nand_child(struct platform_device *pdev,
> -  struct device_node *child)
> -{
> - u32 val;
> - const char *s;
> - struct gpmc_timings gpmc_t;
> - struct omap_nand_platform_data *gpmc_nand_data;
> -
> - if (of_property_read_u32(child, "reg", ) < 0) {
> - dev_err(>dev, "%s has no 'reg' property\n",
> - child->full_name);
> - return -ENODEV;
> - }
> -
> - gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
> -   GFP_KERNEL);
> - if (!gpmc_nand_data)
> - return -ENOMEM;
> -
> - gpmc_nand_data->cs = val;
> - gpmc_nand_data->of_node = child;
> -
> - /* Detect availability of ELM module */
> - gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
> - if (gpmc_nand_data->elm_of_node == NULL)
> - gpmc_nand_data->elm_of_node =
> - of_parse_phandle(child, "elm_id", 0);
> -
> - /* select ecc-scheme for NAND */
> - if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
> - pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
> - return -ENODEV;
> - }
> -
> - if (!strcmp(s, "sw"))
> - gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
> - else if (!strcmp(s, "ham1") ||
> -  !strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_HAM1_CODE_HW;
> - else if (!strcmp(s, "bch4"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch8"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW;
> - else
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
> - else if (!strcmp(s, "bch16"))
> - if (gpmc_nand_data->elm_of_node)
> - gpmc_nand_data->ecc_opt =
> - OMAP_ECC_BCH16_CODE_HW;
> - else
> - pr_err("%s: BCH16 requires ELM support\n", __func__);
> - else
> - pr_err("%s: ti,nand-ecc-opt invalid 

RE: [PATCH 0/2] Two fix for dwc2 gadget driver

[Du, Changbin]

> On 11/29/2015 9:29 PM, changbin...@intel.com wrote:
> > From: "Du, Changbin" 
> >
> > With the first patch, enable a enabled ep will return -EBUSY.
> > The second patch forbid queuing on disabled ep to avoid panic.
> 
> 
> The usb_ep->enabled flag was added in 4.4.
> 
> It looks like these same checks are also added at the API level in the
> usb_ep_enable() and usb_ep_disable().
> 
> In case this is bypassed we should probably add them in the gadget
> anyways but using the existing flag.
> 
> Regards,
> John
> 
Hmm, just learnt the flag on gadget API layer. And I just see usb_ep_enable 
return success if it is already enabled.
But I think it should return an error to inform the caller. Because the ep 
configuration may probably be changed.
In this case, usb_ep_enable will do different behavior.

Hmm, the usb_ep_queue doesn't check the enabled flag. Should be added. Let me 
have a try.

Best Regards,
Changbin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

[Joonsoo Kim]

On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
> On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:
> > On Mon, 23 Nov 2015 17:28:05 +0900
> > Joonsoo Kim  wrote:
> > 
> > > On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> > > > On Fri, 20 Nov 2015 15:33:25 +0900
> > > > Joonsoo Kim  wrote:
> > > > 
> > > >   
> > > > > Steven, is it possible to add tracepoint to inlined fucntion such as
> > > > > get_page() in include/linux/mm.h?  
> > > > 
> > > > I highly recommend against it. The tracepoint code adds a bit of bloat,
> > > > and if you inline it, you add that bloat to every use case. Also, it  
> > > 
> > > Is it worse than adding function call to my own stub function into
> > > inlined function such as get_page(). I implemented it as following.
> > > 
> > > get_page()
> > > {
> > > atomic_inc()
> > > stub_get_page()
> > > }
> > > 
> > > stub_get_page() in foo.c
> > > {
> > > trace_page_ref_get_page()
> > > }
> > 
> > Now you just slowed down the fast path. But what you could do is:
> > 
> > get_page()
> > {
> > atomic_inc();
> > if (trace_page_ref_get_page_enabled())
> > stub_get_page();
> > }
> > 
> > Now that "trace_page_ref_get_page_enabled()" will turn into:
> > 
> > if (static_key_false(&__tracepoint_page_ref_get_page.key)) {
> > 
> > which is a jump label (nop when disabled, a jmp when enabled). That's
> > less bloat but doesn't solve the include problem. You still need to add
> > the include of that will cause havoc with other tracepoints.
> 
> Yes, It also has a include dependency problem so I can't use
> trace_page_ref_get_page_enabled() in mm.h. BTW, I tested following
> implementation and it works fine.
> 
> extern struct tracepoint __tracepoint_page_ref_get_page;
> 
> get_page()
> {
> atomic_inc()
> if (static_key_false(&__tracepoint_page_ref_get_page.key))
> stub_get_page()
> }
> 
> This would not slow down fast path although it can't prevent bloat.
> I know that it isn't good code practice, but, this page reference
> handling functions have complex include dependency so I'm not sure
> I can solve it completely. For this special case, can I use
> this raw data structure?
> 

Steven, any comment?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 4/6] cpufreq: governor: initialize/destroy timer_mutex with 'shared'

[Viresh Kumar]

timer_mutex is required to be initialized only while memory for 'shared'
is allocated and in a similar way it is required to be destroyed only
when memory for 'shared' is freed.

There is no need to do the same every time we start/stop the governor.
Move code to initialize/destroy timer_mutex to the relevant places.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_governor.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index cdcb56a49b28..999e1f6addf9 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -287,6 +287,7 @@ static int alloc_common_dbs_info(struct cpufreq_policy 
*policy,
for_each_cpu(j, policy->related_cpus)
cdata->get_cpu_cdbs(j)->shared = shared;
 
+   mutex_init(>timer_mutex);
return 0;
 }
 
@@ -297,6 +298,8 @@ static void free_common_dbs_info(struct cpufreq_policy 
*policy,
struct cpu_common_dbs_info *shared = cdbs->shared;
int j;
 
+   mutex_destroy(>timer_mutex);
+
for_each_cpu(j, policy->cpus)
cdata->get_cpu_cdbs(j)->shared = NULL;
 
@@ -433,7 +436,6 @@ static int cpufreq_governor_start(struct cpufreq_policy 
*policy,
 
shared->policy = policy;
shared->time_stamp = ktime_get();
-   mutex_init(>timer_mutex);
 
for_each_cpu(j, policy->cpus) {
struct cpu_dbs_info *j_cdbs = cdata->get_cpu_cdbs(j);
@@ -493,8 +495,6 @@ static int cpufreq_governor_stop(struct cpufreq_policy 
*policy,
mutex_unlock(>timer_mutex);
 
gov_cancel_work(dbs_data, policy);
-
-   mutex_destroy(>timer_mutex);
return 0;
 }
 
-- 
2.6.2.198.g614a2ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/7] mm/gup: add gup trace points

[Steven Rostedt]

On Wed, 2 Dec 2015 15:36:50 -0800
Dave Hansen  wrote:

> On 12/02/2015 02:53 PM, Yang Shi wrote:
> > diff --git a/mm/gup.c b/mm/gup.c
> > index deafa2c..10245a4 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -13,6 +13,9 @@
> >  #include 
> >  #include 
> >  
> > +#define CREATE_TRACE_POINTS
> > +#include 
> > +
> >  #include 
> >  #include   
> 
> This needs to be _the_ last thing that gets #included.  Otherwise, you
> risk colliding with any other trace header that gets implicitly included
> below.

Agreed.

> 
> > @@ -1340,6 +1346,8 @@ int __get_user_pages_fast(unsigned long start, int 
> > nr_pages, int write,
> > start, len)))
> > return 0;
> >  
> > +   trace_gup_get_user_pages_fast(start, nr_pages, write, pages);
> > +
> > /*
> >  * Disable interrupts.  We use the nested form as we can already have
> >  * interrupts disabled by get_futex_key.  
> 
> It would be _really_ nice to be able to see return values from the
> various gup calls as well.  Is that feasible?

Only if you rewrite the functions to have a single return code path
that we can add a tracepoint too. Or have a wrapper function that gets
called directly that calls these functions internally and the tracepoint
can trap the return value.

I can probably make function_graph tracer give return values, although
it will give a return value for void functions as well. And it may give
long long returns for int returns that may have bogus data in the
higher bits.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/vmstat: retrieve more accurate vmstat value

[Joonsoo Kim]

On Thu, Nov 26, 2015 at 10:52:52AM +0900, Joonsoo Kim wrote:
> On Wed, Nov 25, 2015 at 10:04:44AM -0600, Christoph Lameter wrote:
> > > Although vmstat values aren't designed for accuracy, these are already
> > > used by some sensitive places so it is better to be more accurate.
> > 
> > The design is to sacrifice accuracy and the time the updates occur for
> > performance reasons. This is not the purpose the counters were designed
> > for. If you put these demands on the vmstat then you will get complex
> > convoluted code and compromise performance.
> 
> I understand design decision, but, it is better to get value as much
> as accurate if there is no performance problem. My patch would not
> cause much performance degradation because it is just adding one
> this_cpu_read().
> 
> Consider about following example. Current implementation returns
> interesting output if someone do following things.
> 
> v1 = zone_page_state(XXX);
> mod_zone_page_state(XXX, 1);
> v2 = zone_page_state(XXX);
> 
> v2 would be same with v1 in most of cases even if we already update
> it.
> 
> This situation could occurs in page allocation path and others. If
> some task try to allocate many pages, then watermark check returns
> same values until updating vmstat even if some freepage are allocated.
> There are some adjustments for this imprecision but why not do it become
> accurate? I think that this change is reasonable trade-off.
> 
Christoph, any comment?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm/compaction: restore COMPACT_CLUSTER_MAX to 32

[Joonsoo Kim]

Until now, COMPACT_CLUSTER_MAX is defined as SWAP_CLUSTER_MAX.
Commit ("mm: increase SWAP_CLUSTER_MAX to batch TLB flushes")
changes SWAP_CLUSTER_MAX from 32 to 256 to improve tlb flush performance
so COMPACT_CLUSTER_MAX is also changed to 256. But, it has
no justification on compaction-side and I think that loss is more than
benefit.

One example is that migration scanner would isolates and migrates
too many pages unnecessarily with 256 COMPACT_CLUSTER_MAX. It may be
enough to migrate 4 pages in order to make order-2 page, but, now,
compaction will migrate 256 pages.

To reduce this unneeded overhead, this patch restores
COMPACT_CLUSTER_MAX to 32.

Signed-off-by: Joonsoo Kim 
---
 include/linux/swap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index d08feef..31eb343 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -155,7 +155,7 @@ enum {
 };
 
 #define SWAP_CLUSTER_MAX 256UL
-#define COMPACT_CLUSTER_MAX SWAP_CLUSTER_MAX
+#define COMPACT_CLUSTER_MAX 32UL
 
 /*
  * Ratio between zone->managed_pages and the "gap" that above the per-zone
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] mm/compaction: __compact_pgdat() code cleanuup

[Joonsoo Kim]

This patch uses is_via_compact_memory() to distinguish compaction
from sysfs or sysctl. And, this patch also reduces indentation
on compaction_defer_reset() by filtering these cases first
before checking watermark.

There is no functional change.

Acked-by: Yaowei Bai 
Acked-by: David Rientjes 
Signed-off-by: Joonsoo Kim 
---
 mm/compaction.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index de3e1e7..01b1e5e 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1658,14 +1658,15 @@ static void __compact_pgdat(pg_data_t *pgdat, struct 
compact_control *cc)
!compaction_deferred(zone, cc->order))
compact_zone(zone, cc);
 
-   if (cc->order > 0) {
-   if (zone_watermark_ok(zone, cc->order,
-   low_wmark_pages(zone), 0, 0))
-   compaction_defer_reset(zone, cc->order, false);
-   }
-
VM_BUG_ON(!list_empty(>freepages));
VM_BUG_ON(!list_empty(>migratepages));
+
+   if (is_via_compact_memory(cc->order))
+   continue;
+
+   if (zone_watermark_ok(zone, cc->order,
+   low_wmark_pages(zone), 0, 0))
+   compaction_defer_reset(zone, cc->order, false);
}
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 6/6] cpufreq: ondemand: update update_sampling_rate() to make it more efficient

[Viresh Kumar]

Currently update_sampling_rate() runs over each online CPU and
cancels/queues timers on all policy->cpus every time. This should be
done just once for any cpu belonging to a policy.

Create a cpumask and keep on clearing it as and when we process
policies, so that we don't have to traverse through all CPUs of the same
policy.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_ondemand.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index f879012cf849..eae51070c034 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -246,6 +246,7 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
unsigned int new_rate)
 {
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
+   struct cpumask cpumask;
int cpu;
 
od_tuners->sampling_rate = new_rate = max(new_rate,
@@ -256,7 +257,9 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 */
mutex_lock(_dbs_cdata.mutex);
 
-   for_each_online_cpu(cpu) {
+   cpumask_copy(, cpu_online_mask);
+
+   for_each_cpu(cpu, ) {
struct cpufreq_policy *policy;
struct od_cpu_dbs_info_s *dbs_info;
struct cpu_dbs_info *cdbs;
@@ -276,6 +279,9 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 
policy = shared->policy;
 
+   /* clear all CPUs of this policy */
+   cpumask_andnot(, , policy->cpus);
+
/*
 * Update sampling rate for CPUs whose policy is governed by
 * dbs_data. In case of governor_per_policy, only a single
@@ -285,6 +291,10 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
if (dbs_data != policy->governor_data)
continue;
 
+   /*
+* Checking this for any CPU should be fine, timers for all of
+* them are scheduled together.
+*/
next_sampling = jiffies + usecs_to_jiffies(new_rate);
appointed_at = dbs_info->cdbs.timer.expires;
 
-- 
2.6.2.198.g614a2ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers

[Viresh Kumar]

cpufreq governors evaluate load at sampling rate and based on that they
update frequency for a group of CPUs belonging to the same cpufreq
policy.

This is required to be done in a single thread for all policy->cpus, but
because we don't want to wakeup idle CPUs to do just that, we use
deferrable work for this. If we would have used a single delayed
deferrable work for the entire policy, there were chances that the CPU
required to run the handler can be in idle and we might end up not
changing the frequency for the entire group with load variations.

And so we were forced to keep per-cpu works, and only the one that
expires first need to do the real work and others are rescheduled for
next sampling time.

We have been using the more complex solution until now, where we used a
delayed deferrable work for this, which is a combination of a timer and
a work.

This could be made lightweight by keeping per-cpu deferred timers with a
single work item, which is scheduled by the first timer that expires.

This patch does just that and here are important changes:
- The timer handler will run in irq context and so we need to use a
  spin_lock instead of the timer_mutex. And so a separate timer_lock is
  created. This also makes the use of the mutex and lock quite clear, as
  we know what exactly they are protecting.
- A new field 'skip_work' is added to track when the timer handlers can
  queue a work. More comments present in code.

Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ashwin Chaugule 
---
 drivers/cpufreq/cpufreq_governor.c | 139 +
 drivers/cpufreq/cpufreq_governor.h |  20 --
 drivers/cpufreq/cpufreq_ondemand.c |   8 +--
 3 files changed, 98 insertions(+), 69 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 999e1f6addf9..a3f9bc9b98e9 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -158,47 +158,52 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 }
 EXPORT_SYMBOL_GPL(dbs_check_cpu);
 
-static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
-   unsigned int delay)
+void gov_add_timers(struct cpufreq_policy *policy, unsigned int delay)
 {
-   struct cpu_dbs_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
-
-   mod_delayed_work_on(cpu, system_wq, >dwork, delay);
-}
-
-void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
-   unsigned int delay, bool all_cpus)
-{
-   int i;
+   struct dbs_data *dbs_data = policy->governor_data;
+   struct cpu_dbs_info *cdbs;
+   int cpu;
 
-   if (!all_cpus) {
-   /*
-* Use raw_smp_processor_id() to avoid preemptible warnings.
-* We know that this is only called with all_cpus == false from
-* works that have been queued with *_work_on() functions and
-* those works are canceled during CPU_DOWN_PREPARE so they
-* can't possibly run on any other CPU.
-*/
-   __gov_queue_work(raw_smp_processor_id(), dbs_data, delay);
-   } else {
-   for_each_cpu(i, policy->cpus)
-   __gov_queue_work(i, dbs_data, delay);
+   for_each_cpu(cpu, policy->cpus) {
+   cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
+   cdbs->timer.expires = jiffies + delay;
+   add_timer_on(>timer, cpu);
}
 }
-EXPORT_SYMBOL_GPL(gov_queue_work);
+EXPORT_SYMBOL_GPL(gov_add_timers);
 
-static inline void gov_cancel_work(struct dbs_data *dbs_data,
-   struct cpufreq_policy *policy)
+static inline void gov_cancel_timers(struct cpufreq_policy *policy)
 {
+   struct dbs_data *dbs_data = policy->governor_data;
struct cpu_dbs_info *cdbs;
int i;
 
for_each_cpu(i, policy->cpus) {
cdbs = dbs_data->cdata->get_cpu_cdbs(i);
-   cancel_delayed_work_sync(>dwork);
+   del_timer_sync(>timer);
}
 }
 
+void gov_cancel_work(struct cpu_common_dbs_info *shared)
+{
+   unsigned long flags;
+
+   /*
+* No work will be queued from timer handlers after skip_work is
+* updated. And so we can safely cancel the work first and then the
+* timers.
+*/
+   spin_lock_irqsave(>timer_lock, flags);
+   shared->skip_work++;
+   spin_unlock_irqrestore(>timer_lock, flags);
+
+   cancel_work_sync(>work);
+
+   gov_cancel_timers(shared->policy);
+
+   shared->skip_work = 0;
+}
+
 /* Will return if we need to evaluate cpu load again or not */
 static bool need_load_eval(struct cpu_common_dbs_info *shared,
   unsigned int sampling_rate)
@@ -217,29 +222,21 @@ static bool need_load_eval(struct cpu_common_dbs_info 
*shared,
return true;
 }
 
-static void dbs_timer(struct work_struct *work)
+static void 

[PATCH V2 3/6] cpufreq: governor: Pass policy as argument to ->gov_dbs_timer()

[Viresh Kumar]

Pass 'policy' as argument to ->gov_dbs_timer() instead of cdbs and
dbs_data.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_conservative.c | 6 +++---
 drivers/cpufreq/cpufreq_governor.c | 2 +-
 drivers/cpufreq/cpufreq_governor.h | 3 +--
 drivers/cpufreq/cpufreq_ondemand.c | 5 ++---
 4 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 1fa1deb6e91f..606ad74abe6e 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -115,13 +115,13 @@ static void cs_check_cpu(int cpu, unsigned int load)
}
 }
 
-static unsigned int cs_dbs_timer(struct cpu_dbs_info *cdbs,
-struct dbs_data *dbs_data, bool modify_all)
+static unsigned int cs_dbs_timer(struct cpufreq_policy *policy, bool 
modify_all)
 {
+   struct dbs_data *dbs_data = policy->governor_data;
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
 
if (modify_all)
-   dbs_check_cpu(dbs_data, cdbs->shared->policy->cpu);
+   dbs_check_cpu(dbs_data, policy->cpu);
 
return delay_for_sampling_rate(cs_tuners->sampling_rate);
 }
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index b260576ddb12..cdcb56a49b28 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -253,7 +253,7 @@ static void dbs_timer(struct work_struct *work)
if (!need_load_eval(cdbs->shared, sampling_rate))
modify_all = false;
 
-   delay = dbs_data->cdata->gov_dbs_timer(cdbs, dbs_data, modify_all);
+   delay = dbs_data->cdata->gov_dbs_timer(policy, modify_all);
gov_queue_work(dbs_data, policy, delay, modify_all);
 
 unlock:
diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index 5621bb03e874..0c7589016b6c 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -209,8 +209,7 @@ struct common_dbs_data {
 
struct cpu_dbs_info *(*get_cpu_cdbs)(int cpu);
void *(*get_cpu_dbs_info_s)(int cpu);
-   unsigned int (*gov_dbs_timer)(struct cpu_dbs_info *cdbs,
- struct dbs_data *dbs_data,
+   unsigned int (*gov_dbs_timer)(struct cpufreq_policy *policy,
  bool modify_all);
void (*gov_check_cpu)(int cpu, unsigned int load);
int (*init)(struct dbs_data *dbs_data, bool notify);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 08f2aa602f9e..fc0384b4d02d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -191,10 +191,9 @@ static void od_check_cpu(int cpu, unsigned int load)
}
 }
 
-static unsigned int od_dbs_timer(struct cpu_dbs_info *cdbs,
-struct dbs_data *dbs_data, bool modify_all)
+static unsigned int od_dbs_timer(struct cpufreq_policy *policy, bool 
modify_all)
 {
-   struct cpufreq_policy *policy = cdbs->shared->policy;
+   struct dbs_data *dbs_data = policy->governor_data;
unsigned int cpu = policy->cpu;
struct od_cpu_dbs_info_s *dbs_info = _cpu(od_cpu_dbs_info,
cpu);
-- 
2.6.2.198.g614a2ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 2/6] cpufreq: ondemand: Work is guaranteed to be pending

[Viresh Kumar]

We are guaranteed to have works scheduled for policy->cpus, as the
policy isn't stopped yet. And so there is no need to check that again.
Drop it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_ondemand.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 089ca6a6ca02..08f2aa602f9e 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -286,9 +286,6 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
if (dbs_data != policy->governor_data)
continue;
 
-   if (!delayed_work_pending(_info->cdbs.dwork))
-   continue;
-
next_sampling = jiffies + usecs_to_jiffies(new_rate);
appointed_at = dbs_info->cdbs.dwork.timer.expires;
 
-- 
2.6.2.198.g614a2ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/7] trace/events: Add gup trace events

[Steven Rostedt]

On Wed,  2 Dec 2015 14:53:27 -0800
Yang Shi  wrote:

> page-faults events record the invoke to handle_mm_fault, but the invoke
> may come from do_page_fault or gup. In some use cases, the finer event count
> mey be needed, so add trace events support for:
> 
> __get_user_pages
> __get_user_pages_fast
> fixup_user_fault
> 
> Signed-off-by: Yang Shi 
> ---
>  include/trace/events/gup.h | 71 
> ++
>  1 file changed, 71 insertions(+)
>  create mode 100644 include/trace/events/gup.h
> 
> diff --git a/include/trace/events/gup.h b/include/trace/events/gup.h
> new file mode 100644
> index 000..03a4674
> --- /dev/null
> +++ b/include/trace/events/gup.h
> @@ -0,0 +1,71 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM gup
> +
> +#if !defined(_TRACE_GUP_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_GUP_H
> +
> +#include 
> +#include 
> +
> +TRACE_EVENT(gup_fixup_user_fault,
> +
> + TP_PROTO(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long address, unsigned int fault_flags),
> +
> + TP_ARGS(tsk, mm, address, fault_flags),

Arges added and not used by TP_fast_assign(), this will slow down the
code while tracing is enabled, as they need to be added to the trace
function call.

> +
> + TP_STRUCT__entry(
> + __field(unsigned long,  address )
> + ),
> +
> + TP_fast_assign(
> + __entry->address= address;
> + ),
> +
> + TP_printk("address=%lx",  __entry->address)
> +);
> +
> +TRACE_EVENT(gup_get_user_pages,
> +
> + TP_PROTO(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long start, unsigned long nr_pages),
> +
> + TP_ARGS(tsk, mm, start, nr_pages),

Here too but this is worse. See below.

> +
> + TP_STRUCT__entry(
> + __field(unsigned long,  start   )
> + __field(unsigned long,  nr_pages)
> + ),
> +
> + TP_fast_assign(
> + __entry->start  = start;
> + __entry->nr_pages   = nr_pages;
> + ),
> +
> + TP_printk("start=%lx nr_pages=%lu", __entry->start, __entry->nr_pages)
> +);
> +
> +TRACE_EVENT(gup_get_user_pages_fast,
> +
> + TP_PROTO(unsigned long start, int nr_pages, int write,
> + struct page **pages),
> +
> + TP_ARGS(start, nr_pages, write, pages),

This and the above "gup_get_user_pages" have the same entry field,
assign and printk. They should be combined into a DECLARE_EVENT_CLASS()
and two DEFINE_EVENT()s. That will save on size as the
DECLARE_EVENT_CLASS() is the biggest part of each TRACE_EVENT().

-- Steve


> +
> + TP_STRUCT__entry(
> + __field(unsigned long,  start   )
> + __field(unsigned long,  nr_pages)
> + ),
> +
> + TP_fast_assign(
> + __entry->start  = start;
> + __entry->nr_pages   = nr_pages;
> + ),
> +
> + TP_printk("start=%lx nr_pages=%lu",  __entry->start, __entry->nr_pages)
> +);
> +
> +#endif /* _TRACE_GUP_H */
> +
> +/* This part must be outside protection */
> +#include 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 1/6] cpufreq: ondemand: Update sampling rate only for concerned policies

[Viresh Kumar]

We are comparing policy->governor against cpufreq_gov_ondemand to make
sure that we update sampling rate only for the concerned CPUs. But that
isn't enough.

In case of governor_per_policy, there can be multiple instances of
ondemand governor and we will always end up updating all of them with
current code. What we rather need to do, is to compare dbs_data with
poilcy->governor_data, which will match only for the policies governed
by dbs_data.

This code is also racy as the governor might be getting stopped at that
time and we may end up scheduling work for a policy, which we have just
disabled.

Fix that by protecting the entire function with _dbs_cdata.mutex,
which will prevent against races with policy START/STOP/etc.

After these locks are in place, we can safely get the policy via per-cpu
dbs_info.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_ondemand.c | 35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 03ac6ce54042..089ca6a6ca02 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -252,20 +252,39 @@ static void update_sampling_rate(struct dbs_data 
*dbs_data,
od_tuners->sampling_rate = new_rate = max(new_rate,
dbs_data->min_sampling_rate);
 
+   /*
+* Lock governor so that governor start/stop can't execute in parallel.
+*/
+   mutex_lock(_dbs_cdata.mutex);
+
for_each_online_cpu(cpu) {
struct cpufreq_policy *policy;
struct od_cpu_dbs_info_s *dbs_info;
+   struct cpu_dbs_info *cdbs;
+   struct cpu_common_dbs_info *shared;
unsigned long next_sampling, appointed_at;
 
-   policy = cpufreq_cpu_get(cpu);
-   if (!policy)
+   dbs_info = _cpu(od_cpu_dbs_info, cpu);
+   cdbs = _info->cdbs;
+   shared = cdbs->shared;
+
+   /*
+* A valid shared and shared->policy means governor hasn't
+* stopped or exited yet.
+*/
+   if (!shared || !shared->policy)
continue;
-   if (policy->governor != _gov_ondemand) {
-   cpufreq_cpu_put(policy);
+
+   policy = shared->policy;
+
+   /*
+* Update sampling rate for CPUs whose policy is governed by
+* dbs_data. In case of governor_per_policy, only a single
+* policy will be governed by dbs_data, otherwise there can be
+* multiple policies that are governed by the same dbs_data.
+*/
+   if (dbs_data != policy->governor_data)
continue;
-   }
-   dbs_info = _cpu(od_cpu_dbs_info, cpu);
-   cpufreq_cpu_put(policy);
 
if (!delayed_work_pending(_info->cdbs.dwork))
continue;
@@ -281,6 +300,8 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
 
}
}
+
+   mutex_unlock(_dbs_cdata.mutex);
 }
 
 static ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
-- 
2.6.2.198.g614a2ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Skylake (XPS 13 9350) TSC is way off

[Brown, Len]

> >> [0.00] tsc: PIT calibration matches HPET. 2 loops
> >> [0.00] tsc: Detected 2399.975 MHz processor
> >> [0.090897] TSC deadline timer enabled
> >> [1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz

> turbostat version 4.10 10 Dec, 2015 - Len Brown 
> CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping 0x6:4e:3 
> (6:78:3)
> CPUID(1): SSE3 MONITOR EIST TM2 TSC MSR ACPI-TM TM
> CPUID(6): APERF, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
> cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MONITOR)
> CPUID(0x15): eax_crystal: 2 ebx_tsc: 200 ecx_crystal_hz: 0
> TSC: 2400 MHz (2400 Hz * 200 / 2 / 100)
> CPUID(0x16): base_mhz: 2400 max_mhz: 2800 bus_mhz: 100


Both the initial and refined TSC calibration are right on the money -- 2400 MHz.
Further, this system happens to also have a base frequency of 2400 MHz,
so tsc_khz = cpu_khz = 2,400,000, exactly.  It would stray from that value
only based on the ppm error of the base 24 MHz crystal.

Anything other than that value is error.

-Len

> RAPL: 17476 sec. Joule Counter Range, at 15 Watts
> cpu1: MSR_PLATFORM_INFO: 0x4043df1011800
> 4 * 100 = 400 MHz max efficiency frequency
> 24 * 100 = 2400 MHz base frequency
> cpu1: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled)
> cpu1: MSR_TURBO_RATIO_LIMIT: 0x1b1b1b1c
> 27 * 100 = 2700 MHz max turbo 4 active cores
> 27 * 100 = 2700 MHz max turbo 3 active cores
> 27 * 100 = 2700 MHz max turbo 2 active cores
> 28 * 100 = 2800 MHz max turbo 1 active cores
> cpu1: MSR_CONFIG_TDP_NOMINAL: 0x0017 (base_ratio=7)
> cpu1: MSR_CONFIG_TDP_LEVEL_1: 0x0008003c (PKG_MIN_PWR_LVL1=0
> PKG_MAX_PWR_LVL1=0 LVL1_RATIO=8 PKG_TDP_LVL1=60)
> cpu1: MSR_CONFIG_TDP_LEVEL_2: 0x001800c8 (PKG_MIN_PWR_LVL2=0
> PKG_MAX_PWR_LVL2=0 LVL2_RATIO=8 PKG_TDP_LVL2=200)
> cpu1: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
> cpu1: MSR_TURBO_ACTIVATION_RATIO: 0x (MAX_NON_TURBO_RATIO=0
> lock=0)
> cpu1: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008006 (UNdemote-C3,
> UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=6: pc8)
> cpu0: MSR_PM_ENABLE: 0x0001 (HWP)
> cpu0: MSR_HWP_CAPABILITIES: 0x0105171c (high 0x1c guar 0x17 eff 0x5 low
> 0x1)
> cpu0: MSR_HWP_REQUEST: 0x80001c04 (min 0x4 max 0x1c des 0x0 epp 0x80
> window 0x0 pkg 0x0)
> cpu0: MSR_HWP_INTERRUPT: 0x0001 (EN_Guaranteed_Perf_Change,
> Dis_Excursion_Min)
> cpu0: MSR_HWP_STATUS: 0x (No-Guaranteed_Perf_Change, No-
> Excursion_Min)
> cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0006 (balanced)
> cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.61
> Joules, 0.000977 sec.)
> cpu0: MSR_PKG_POWER_INFO: 0x0078 (15 W TDP, RAPL 0 - 0 W, 0.00
> sec.)
> cpu0: MSR_PKG_POWER_LIMIT: 0x4280c800dd8078 (UNlocked)
> cpu0: PKG Limit #1: ENabled (15.00 Watts, 28.00 sec, clamp
> ENabled)
> cpu0: PKG Limit #2: ENabled (25.00 Watts, 0.002441* sec, clamp
> DISabled)
> cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de (UNlocked)
> cpu0: DRAM Limit: DISabled (0.00 Watts, 0.000977 sec, clamp DISabled)
> cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0064 (100 C)
> cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88340800 (48 C)
> cpu0: MSR_IA32_THERM_STATUS: 0x88350800 (47 C +/- 1)
> cpu1: MSR_IA32_THERM_STATUS: 0x88340800 (48 C +/- 1)
> Core CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz SMI  CPU%c1
> CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Totl%C0  Any%C0  GFX%C0 CPUGFX%
> Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt
> RAMWatt   PKG_%   RAM_%
>-   -  162.84 5492399   04.13
> 0.020.63   92.39  46  46   12.21   10.772.480.80
> 14.33   71.530.000.000.000.000.001.950.54
>   0.000.00
>0   0  111.92 5632399   02.48
> 0.020.80   94.78  46  46   12.21   10.782.480.80
> 14.34   71.550.000.000.000.000.001.950.54
>   0.000.00
>0   2   81.39 5502399   03.04
>1   1  132.04 6222400   07.48
> 0.020.45   90.01  45
>1   3  316.01 5202400   03.51
> 1.002561 sec
> 
> In case it's at all useful, adjtimex -p says:
> 
>  mode: 0
>offset: 0
> frequency: 135641
>  maxerror: 37498
>  esterror: 1532
>status: 8192
> time_constant: 2
> precision: 1
> tolerance: 32768000
>  tick: 1
>  raw time:  1449098317s 671243180us = 1449098317.671243180
> 
> this suggests a rather small correction, so I really have no idea what
> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
> 
> John, you wrote this code.  What does the error message mean?
> 
> --Andy
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH v2 4/9] ARM: dts: add dts files for hi3519-demb board

[Jiancheng Xue]

add dts files for hi3519-demb board

Signed-off-by: Jiancheng Xue 
---
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  55 
 arch/arm/boot/dts/hi3519.dtsi | 129 ++
 3 files changed, 186 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..39ad947 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -133,6 +133,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb \
exynos5800-peach-pi.dtb
+dtb-$(CONFIG_ARCH_HI3519) += \
+   hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 000..c7a1720
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * 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 .
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+   model = "HiSilicon HI3519 DEMO Board";
+   compatible = "hisilicon,hi3519";
+
+   chosen {
+   bootargs = "mem=64M console=ttyAMA0,115200 early_printk \
+root=/dev/mtdblock2 rootfstype=jffs2 \
+mtdparts=hi_sfc:1M(boot),4M(kernel),11M(rootfs)";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_timer0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 000..32f08e6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,129 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * 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 "skeleton.dtsi"
+#include 
+/ {
+   aliases {
+   serial0 = 
+   };
+
+   gic: interrupt-controller@1030 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   ranges;
+
+   amba {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "arm,amba-bus";
+   ranges;
+
+   uart0: uart@1210 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x1210 0x1000>;
+   interrupts = <0 4 4>;
+   clocks = < HI3519_UART0_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart1: uart@12101000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12101000 0x1000>;
+   interrupts = <0 5 4>;
+   clocks = < HI3519_UART1_CLK>;
+  

Re: [PATCH 2/2] perf hists browser: Reset selection when refresh

[Wangnan (F)]

On 2015/12/3 0:17, Namhyung Kim wrote:

On Wed, Dec 02, 2015 at 12:51:33PM +, Wang Nan wrote:

With following steps:

  Step 1: perf report

  Step 2: Use UP/DOWN to select an entry, don't press 'ENTER'

  Step 3: Use '/' to filter symbols, use a filter which returns
  empty result

  Step 4: Press 'ENTER'

We see that, even if we have filter all symbols (and the main interface
is empty), pressing 'ENTER' still select one symbol. This behavior
surprise user. This patch resets browser->selection in
hist_browser__refresh() and let it choose default selection. In this
case browser->selection keeps NULL so user won't see annotation item
in menu.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
---

Note that if this patch is applied before 1/2 then the steps listed in
commit message in 1/2 won't trigger segfault. However I believe patch 1/1
is still required.

---
  tools/perf/ui/browsers/hists.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 9458da8..523a9ef 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1192,6 +1192,7 @@ static unsigned int hist_browser__refresh(struct 
ui_browser *browser)
}
  
  	ui_browser__hists_init_top(browser);

+   hb->selection = NULL;

This code assumes that hb->selection is not NULL if hb->he_selection
is not NULL.  So I think that the right (and simple) fix is to reset
hb->he_selection rather than hb->selection (or both).  It'll make the
change below unnecessary IMHO.


No. Only set hb->he_selection causes crash:

Step 0: user 'perf record ls' create a perf.data without callchain;
Step 1: perf report
Step 2: choose a annotable entry, don't press 'ENTER'
Step 3: use '/' and enter a filter like 'asdfasdf' which ensure no entry
would be left
Step 3: Press 'ENTER' twice

Crash:
# ./perf report
perf: Segmentation fault
 backtrace 
./perf[0x53e588]
/tmp/oxygen_root/lib64/libc.so.6(+0x3545f)[0x7f2b4d6da45f]
./perf[0x539e03]
./perf(perf_evlist__tui_browse_hists+0x96)[0x53d226]
./perf(cmd_report+0x1b9f)[0x442c7f]
./perf[0x47efc2]
./perf(main+0x5f5)[0x432fa5]
/tmp/oxygen_root/lib64/libc.so.6(__libc_start_main+0xf4)[0x7f2b4d6c6bd4]
./perf[0x4330d4]


GDB result:

Program received signal SIGSEGV, Segmentation fault.
hist_browser__toggle_fold (browser=0x1f71160) at ui/browsers/hists.c:352
(gdb) bt
#0  hist_browser__toggle_fold (browser=0x1f71160) at ui/browsers/hists.c:352
#1  hist_browser__run (help=0x649038 "For a higher level overview, try: 
perf report --sort comm,dso", browser=0x1f71160) at ui/

browsers/hists.c:539
#2  perf_evsel__hists_browse (evsel=0x19ef140, 
nr_events=nr_events@entry=1, helpline=helpline@entry=0x649038 "For a 
higher leve
l overview, try: perf report --sort comm,dso", 
left_exits=left_exits@entry=false, hbt=hbt@entry=0x0, 
min_pcnt=,

env=0x19ed850) at ui/browsers/hists.c:2101
#3  0x0053d227 in perf_evlist__tui_browse_hists 
(evlist=0x19ee730, help=help@entry=0x649038 "For a higher level overvie
w, try: perf report --sort comm,dso", hbt=hbt@entry=0x0, 
min_pcnt=, env=) at ui/browsers/hists.c:

2555
#4  0x00442c80 in report__browse_hists (rep=0x7fffca20) at 
builtin-report.c:440

#5  __cmd_report (rep=0x7fffca20) at builtin-report.c:576
#6  cmd_report (argc=0, argv=0x7fffe590, prefix=) at 
builtin-report.c:962
#7  0x0047efc3 in run_builtin (p=p@entry=0x8ff9e0 
, argc=argc@entry=1, argv=argv@entry=0x7fffe590) at

 perf.c:387
#8  0x00432fa6 in handle_internal_command (argv=0x7fffe590, 
argc=1) at perf.c:448

#9  run_argv (argv=0x7fffe310, argcp=0x7fffe31c) at perf.c:492
#10 main (argc=1, argv=0x7fffe590) at perf.c:609

But setting both of them to NULL in hist_browser__refresh() can avoid 
this crash.


So we have two choice:

1. In hist_browser__refresh() let's set both selection and he_selection 
to NULL;


   By this way after step 3 we won't see annotation options. The 
context menu

   (by pressing ENTER or 'm') is:

Run scripts for all samples
Switch to another data file in PWD
Exit


2. In hist_browser__toggle_fold() let's check both he amd ms.

   By this way we still get annotation and map options in context menu:

Annotate __strcoll_l
Browse map details
Run scripts for all samples
Switch to another data file in PWD
Exit

I'm not sure which one is better because I don't really understand this 
part of

code. But for me the second result is surprising because I have filtered all
entries out in my interface, and I believe I should select nothing, so 
pressing
'ENTER' or 'm' I shall not get annotation option because I don't know 
which entry

would be annotated.

Thank you.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

Re: [PATCH v6 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

[Jiang Liu]

On 2015/11/3 5:33, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> This patch introduces a new driver which exposes a root PCI bus whenever a PCI
> Express device is passed through to a guest VM under Hyper-V. The device can
> be single- or multi-function. The interrupts for the devices are managed by an
> IRQ domain, implemented within the driver.
> 
> Signed-off-by: Jake Oshins 
> ---
>  MAINTAINERS|1 +
>  drivers/pci/Kconfig|7 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/hv_pcifront.c | 2267 
> 
>  4 files changed, 2276 insertions(+)
>  create mode 100644 drivers/pci/host/hv_pcifront.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a2d50fe..a1205b4 100644
[...]
> +/* Interrupt management hooks */
> +
> +/**
> + * hv_msi_free() - Free the MSI.
> + * @domain:  The interrupt domain pointer
> + * @info:Extra MSI-related context
> + * @irq: Identifies the IRQ.
> + *
> + * The Hyper-V parent partition and hypervisor are tracking the
> + * messages that are in use, keeping the interrupt redirection
> + * table up to date.  This callback sends a message that frees
> + * the the IRT entry and related tracking nonsense.
> + */
> +static void hv_msi_free(struct irq_domain *domain, struct msi_domain_info 
> *info,
> + unsigned int irq)
> +{
> + struct pci_delete_interrupt *int_pkt;
> + struct {
> + struct pci_packet pkt;
> + u8 buffer[sizeof(struct pci_delete_interrupt) -
> +   sizeof(struct pci_message)];
> + } ctxt;
> + struct hv_pcibus_device *hbus;
> + struct hv_pci_dev *hpdev;
> + struct irq_desc *desc;
> + struct msi_desc *msi;
> + struct tran_int_desc *int_desc;
> + struct pci_dev *pdev;
> +
> + desc = irq_to_desc(irq);
> + msi = irq_desc_get_msi_desc(desc);
> + pdev = msi_desc_to_pci_dev(msi);
For safety, don't assume this HV MSI irqdomain is the top domain.
So please use:
struct irq_data *irq_data = irq_domain_get_irq_data(domain, irq);
struct msi_desc *desc = irq_data_get_msi_desc(irq_data);
struct tran_int_desc *int_desc = irq_data_get_chip_data(irq_data);

> + hbus = info->data;
> + hpdev = lookup_hv_dev(hbus, devfn_to_wslot(pdev->devfn));
> + if (!hpdev)
> + return;
> +
> + int_desc = irq_get_chip_data(irq);
> + if (int_desc) {
> + memset(, 0, sizeof(ctxt));
> + int_pkt = (struct pci_delete_interrupt *)
> + int_pkt->message_type.message_type =
> + PCI_DELETE_INTERRUPT_MESSAGE;
> + int_pkt->wslot.slot = hpdev->desc.win_slot.slot;
> + int_pkt->int_desc = *int_desc;
> + vmbus_sendpacket(hbus->hdev->channel, int_pkt, sizeof(*int_pkt),
> +  (unsigned long), VM_PKT_DATA_INBAND,
> +  0);
> + desc->irq_data.chip_data = NULL;
> + kfree(int_desc);
> + }
> +
> + hv_pcichild_dec(hpdev, hv_pcidev_ref_by_slot);
> +}
> +
> +static int hv_set_affinity(struct irq_data *data, const struct cpumask *dest,
> +bool force)
> +{
> + struct irq_data *parent = data->parent_data;
> +
> + return parent->chip->irq_set_affinity(parent, dest, force);
> +}
> +
> +void hv_irq_mask(struct irq_data *data)
> +{
> + pci_msi_mask_irq(data);
> +}
> +
> +/**
> + * hv_irq_unmask() - "Unmask" the IRQ by setting its current
> + * affinity.
> + * @data:Describes the IRQ
> + *
> + * Build new a destination for the MSI and make a hypercall to
> + * update the Interrupt Redirection Table. "Device Logical ID"
> + * is built out of this PCI bus's instance GUID and the function
> + * number of the device.
> + */
> +void hv_irq_unmask(struct irq_data *data)
> +{
> + struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
> + struct irq_cfg *cfg = irqd_cfg(data);
> + struct retarget_msi_interrupt params;
> + struct hv_pcibus_device *hbus;
> + struct cpumask *dest;
> + struct pci_bus *pbus;
> + struct pci_dev *pdev;
> + int cpu;
> +
> + dest = irq_data_get_affinity_mask(data);
> + pdev = msi_desc_to_pci_dev(msi_desc);
> + pbus = pdev->bus;
> + hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
> +
> + memset(, 0, sizeof(params));
> + params.partition_id = HV_PARTITION_ID_SELF;
> + params.source = 1; /* MSI(-X) */
> + params.address = msi_desc->msg.address_lo;
> + params.data = msi_desc->msg.data;
> + params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> +(hbus->hdev->dev_instance.b[4] << 16) |
> +(hbus->hdev->dev_instance.b[7] << 8) |
> +(hbus->hdev->dev_instance.b[6] & 0xf8) |
> +PCI_FUNC(pdev->devfn);
> + params.vector = cfg->vector;
> +
> + for_each_cpu_and(cpu, dest, 

[PATCH v2 1/3] perf hists browser: Fix segfault if use symbol filter in cmdline

[Wang Nan]

If feed perf a symbol filter in cmdline and the result is empty,
pressing 'Enter' in the hist browser causes crash:

 # ./perf report perf.data   <-- Common mistake for beginners

Then press 'Enter':

 perf: Segmentation fault
  backtrace 
 /home/wangnan/perf[0x53e578]
 /lib64/libc.so.6(+0x3545f)[0x7f76bafe045f]
 /home/wangnan/perf[0x539dd4]
 /home/wangnan/perf(perf_evlist__tui_browse_hists+0x96)[0x53d216]
 /home/wangnan/perf(cmd_report+0x1b9f)[0x442c7f]
 /home/wangnan/perf[0x47efa2]
 /home/wangnan/perf(main+0x5f5)[0x432fa5]
 /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f76bafccbd4]
 /home/wangnan/perf[0x4330d4]

This is because 'perf.data' is interperted as a symbol filter, and the
result is empty, so selection is empty. However,
hist_browser__toggle_fold() forgets to check it.

This patch simply return false when selection is NULL.

Signed-off-by: Wang Nan 
Acked-by: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index dcdcbaf..601a585 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -340,6 +340,9 @@ static bool hist_browser__toggle_fold(struct hist_browser 
*browser)
struct callchain_list *cl = container_of(ms, struct callchain_list, ms);
bool has_children;
 
+   if (!ms)
+   return false;
+
if (ms == >ms)
has_children = hist_entry__toggle_fold(he);
else
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] perf hists browser: Add NULL pointer check to prevent crash

[Wang Nan]

Before this patch we can trigger a segfault by following steps:

 Step 0: Use 'perf record' to generate a perf.data without callchain

 Step 1: perf report

 Step 2: Use UP/DOWN to select an entry, don't press 'ENTER'

 Step 3: Use '/' to filter symbols, use a filter which returns
 empty result

 Step 4: Press 'ENTER' (notice here that the old selection is still
there. This is another problem)

 Step 5: Press 'ENTER' to annotate that symbol

 Step 6: Press 'LEFT' to go out.

 Result: segfault:

 perf: Segmentation fault
  backtrace 
 /home/wangnan/perf[0x53e568]
 /lib64/libc.so.6(+0x3545f)[0x7fba75d3245f]
 /home/wangnan/perf[0x537516]
 /home/wangnan/perf[0x533fef]
 /home/wangnan/perf[0x53b347]
 /home/wangnan/perf(perf_evlist__tui_browse_hists+0x96)[0x53d206]
 /home/wangnan/perf(cmd_report+0x1b9f)[0x442c7f]
 /home/wangnan/perf[0x47efa2]
 /home/wangnan/perf(main+0x5f5)[0x432fa5]
 /lib64/libc.so.6(__libc_start_main+0xf4)[0x7fba75d1ebd4]
 /home/wangnan/perf[0x4330d4]

This is because in this case 'nd' could be NULL in
ui_browser__hists_seek(), but that function never check it.

This patch adds checker for potential NULL pointer in that function.
After this patch the above steps won't segfault again.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 601a585..7447515 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1297,6 +1297,9 @@ static void ui_browser__hists_seek(struct ui_browser 
*browser,
 * and stop when we printed enough lines to fill the screen.
 */
 do_offset:
+
+   if (!nd)
+   return;
if (offset > 0) {
do {
h = rb_entry(nd, struct hist_entry, rb_node);
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] perf hists browser: Avoid crash in some unusal operations

[Wang Nan]

When using symbol filter in hists browser, some unusal operations
causes segfault. This patchset avoid those crashes.

Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 

Wang Nan (3):
  perf hists browser: Fix segfault if use symbol filter in cmdline
  perf hists browser: Add NULL pointer check to prevent crash
  perf hists browser: Reset selection when refresh

 tools/perf/ui/browsers/hists.c | 8 
 1 file changed, 8 insertions(+)

-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] perf hists browser: Reset selection when refresh

[Wang Nan]

With following steps:

 Step 1: perf report

 Step 2: Use UP/DOWN to select an entry, don't press 'ENTER'

 Step 3: Use '/' to filter symbols, use a filter which returns
 empty result

 Step 4: Press 'ENTER'

We see that, even if we have filter all symbols (and the main interface
is empty), pressing 'ENTER' still select one symbol. This behavior
surprise user. This patch resets browser->{he_,}selection in
hist_browser__refresh() and let it choose default selection. In this
case browser->{he_,}selection keeps NULL so user won't see annotation item
in menu.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 7447515..d555ba9 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1192,6 +1192,8 @@ static unsigned int hist_browser__refresh(struct 
ui_browser *browser)
}
 
ui_browser__hists_init_top(browser);
+   hb->he_selection = NULL;
+   hb->selection = NULL;
 
for (nd = browser->top; nd; nd = rb_next(nd)) {
struct hist_entry *h = rb_entry(nd, struct hist_entry, rb_node);
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 9/9] dmaengine: Kconfig: rename ARCH_HI3xxx to ARCH_HI36xx

[Jiancheng Xue]

Rename ARCH_HI3xxx to ARCH_HI36xx.

Signed-off-by: Jiancheng Xue 
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index e6cd1a3..53d5676 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -279,7 +279,7 @@ config INTEL_MIC_X100_DMA
 
 config K3_DMA
tristate "Hisilicon K3 DMA support"
-   depends on ARCH_HI3xxx
+   depends on ARCH_HI36xx
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 7/9] ARM: hisi: rename ARCH_HI3xxx to ARCH_HI36xx

[Jiancheng Xue]

ARCH_HI3xxx just represents hi36xx soc family.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug  | 4 ++--
 arch/arm/boot/dts/Makefile  | 2 +-
 arch/arm/configs/hisi_defconfig | 2 +-
 arch/arm/configs/multi_v7_defconfig | 2 +-
 arch/arm/mach-hisi/Kconfig  | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4d2ae2a..27d97c8 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -280,7 +280,7 @@ choice
 
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
-   depends on ARCH_HI3xxx
+   depends on ARCH_HI36xx
select DEBUG_UART_PL01X
help
  Say Y here if you want kernel low-level debugging support
@@ -288,7 +288,7 @@ choice
 
config DEBUG_HI3716_UART
bool "Hisilicon Hi3716 Debug UART"
-   depends on ARCH_HI3xxx
+   depends on ARCH_HI36xx
select DEBUG_UART_PL01X
help
  Say Y here if you want kernel low-level debugging support
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39ad947..9a7ba0b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -135,7 +135,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3519) += \
hi3519-demb.dtb
-dtb-$(CONFIG_ARCH_HI3xxx) += \
+dtb-$(CONFIG_ARCH_HI36xx) += \
hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index 321d020..3162709 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -4,7 +4,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_RD_LZMA=y
 CONFIG_ARCH_HISI=y
-CONFIG_ARCH_HI3xxx=y
+CONFIG_ARCH_HI36xx=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_HIX5HD2=y
diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..ddc28ce 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -38,7 +38,7 @@ CONFIG_MACH_BERLIN_BG2Q=y
 CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
-CONFIG_ARCH_HI3xxx=y
+CONFIG_ARCH_HI36xx=y
 CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index bc5b873..15f23ed 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -20,7 +20,7 @@ config ARCH_HI3519
help
  Support for Hisilicon Hi3519 Soc
 
-config ARCH_HI3xxx
+config ARCH_HI36xx
bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7
select CACHE_L2X0
select HAVE_ARM_SCU if SMP
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 8/9] clk: hisilicon: rename ARCH_HI3xxx to ARCH_HI36xx

[Jiancheng Xue]

Rename ARCH_HI3xxx to ARCH_HI36xx.

Signed-off-by: Jiancheng Xue 
---
 drivers/clk/hisilicon/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 9a601c0..5a1c195 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,7 +4,7 @@
 
 obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
 
-obj-$(CONFIG_ARCH_HI3xxx)  += clk-hi3620.o
+obj-$(CONFIG_ARCH_HI36xx)  += clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)   += clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
 obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/9] ARM: debug: add Hi3519 debug uart

[Jiancheng Xue]

Add the support of Hisilicon Hi3519 debug uart.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..4d2ae2a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -270,6 +270,14 @@ choice
  Say Y here if you want the debug print routines to direct
  their output to the 8250 at PCI COM1.
 
+   config DEBUG_HI3519_UART
+   bool "Hisilicon Hi3519 Debug UART"
+   depends on ARCH_HI3519
+   select DEBUG_UART_PL01X
+   help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1449,6 +1457,7 @@ config DEBUG_UART_PHYS
default 0xf7fc9000 if DEBUG_BERLIN_UART
default 0xf8b0 if DEBUG_HIX5HD2_UART
default 0xf991e000 if DEBUG_QCOM_UARTDM
+   default 0x1210 if DEBUG_HI3519_UART
default 0xfcb0 if DEBUG_HI3620_UART
default 0xfd883000 if DEBUG_ALPINE_UART0
default 0xfe80 if ARCH_IOP32X
@@ -1529,6 +1538,7 @@ config DEBUG_UART_VIRT
default 0xfe23 if DEBUG_PICOXCELL_UART
default 0xfe30 if DEBUG_BCM_KONA_UART
default 0xfe80 if ARCH_IOP32X
+   default 0xfef0 if DEBUG_HI3519_UART
default 0xfeb0 if DEBUG_HI3620_UART || DEBUG_HIX5HD2_UART
default 0xfeb24000 if DEBUG_RK3X_UART0
default 0xfeb26000 if DEBUG_RK3X_UART1
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/9] ARM: hisi: enable Hi3519 soc

[Jiancheng Xue]

Hi3519 SOC is mainly used for ip camera and sport dv
solutions.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/mach-hisi/Kconfig | 9 +
 arch/arm/mach-hisi/hisilicon.c | 9 +
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 83061ad..bc5b873 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -12,6 +12,14 @@ if ARCH_HISI
 
 menu "Hisilicon platform type"
 
+config ARCH_HI3519
+   bool "Hisilicon Hi3519 Soc" if ARCH_MULTI_V7
+   select HAVE_ARM_ARCH_TIMER
+   select ARCH_HAS_RESET_CONTROLLER
+
+   help
+ Support for Hisilicon Hi3519 Soc
+
 config ARCH_HI3xxx
bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7
select CACHE_L2X0
@@ -48,6 +56,7 @@ config ARCH_HIX5HD2
select PINCTRL_SINGLE
help
  Support for Hisilicon HIX5HD2 SoC family
+
 endmenu
 
 endif
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..a93ac5c 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -81,3 +81,12 @@ static const char *const hip01_compat[] __initconst = {
 DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
.dt_compat  = hip01_compat,
 MACHINE_END
+
+static const char *const hi3519_compat[] __initconst = {
+   "hisilicon,hi3519",
+   NULL,
+};
+
+DT_MACHINE_START(HI3519_DT, "Hisilicon Hi3519 (Flattened Device Tree)")
+   .dt_compat  = hi3519_compat,
+MACHINE_END
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/9] ARM: config: enable ARCH_HI3519

[Jiancheng Xue]

enable ARCH_HI3519 in hisi_defconfig

Signed-off-by: Jiancheng Xue 
---
 arch/arm/configs/hisi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..321d020 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -10,6 +10,7 @@ CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HI3519=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=16
 CONFIG_PREEMPT=y
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt

[Baolin Wang]

On 3 December 2015 at 03:56, Alasdair G Kergon  wrote:
> On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote:
>> These are the benchmarks for request based dm-crypt. Please check it.
>
> Now please put request-based dm-crypt completely to one side and focus
> just on the existing bio-based code.  Why is it slower and what can be
> adjusted to improve this?
>

OK. I think I find something need to be point out.
1. From the IO block size test in the performance report, for the
request based, we can find it can not get the corresponding
performance if we just expand the IO size. Because In dm crypt, it
will map the data buffer of one request with scatterlists, and send
all scatterlists of one request to the encryption engine to encrypt or
decrypt.  I found if the scatterlist list number is small and each
scatterlist length is bigger, it will improve the encryption speed,
that helps the engine palys best performance. But a big IO size does
not mean bigger scatterlists (maybe many scatterlists with small
length), that's why we can not get the corresponding performance if we
just expand the IO size I think.

2. Why bio based is slower?
If you understand 1, you can obviously understand the crypto engine
likes bigger scatterlists to improve the performance. But for bio
based, it only send one scatterlist (the scatterlist's length is
always '1 << SECTOR_SHIFT' = 512) to the crypto engine at one time. It
means if the bio size is 1M, the bio based will send 2048 times (evey
time the only one scatterlist length is 512 bytes) to crypto engine to
handle, which is more time-consuming and ineffective for the crypto
engine. But for request based, it can map the whole request with many
scatterlists (not just one scatterlist), and send all the scatterlists
to the crypto engine which can improve the performance, is it right?

Another optimization solution I think is we can expand the scatterlist
entry number for bio based.

> People aren't going to take a request-based solution seriously until
> you can explain in full detail *why* bio-based is slower AND why it's
> impossible to improve its performance.
>
>> For request based things, some sequential bios/requests can merged
>> into one request to expand the IO size to be a big block handled by
>> hardware engine at one time.
>
> Bio-based also merges I/O so that does not provide justification.
> Investigate in much more detail the actual merging and scheduling
> involved in the cases you need to optimise.  See if blktrace gives you
> any clues, or add your own instrumentation.  You could even look at some
> of the patches we've had in the list archives for optimising bio-based
> crypt in different situations.
>
> Alasdair
>



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/