Re: [PATCH RFC] mmc: add slot argument to mmc_of_parse

[Ludovic Desroches]

Hi,

Sorry I was on vacation, I'll send a cleaner patch updating other drivers
this week.

Regards

Ludovic

On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
> Hi, All.
> 
> This patch is working on progress?
> I want to merge this patch for fixing dw-mmc controller problem.
> 
> If this patch didn't work on progress, i will send the patch based-on this 
> patch.
> 
> Best Regards,
> Jaehoon Chung
> 
> On 05/14/2014 06:53 PM, Ulf Hansson wrote:
> > On 7 May 2014 12:06, Ludovic Desroches  wrote:
> >> Some hosts manage several slots. In these case information such as the bus
> >> width, chip detect and others are into the slot node. So we have to parse
> >> child nodes. If not NULL, slot node will be used instead of the device
> >> node.
> >>
> >> Signed-off-by: Ludovic Desroches 
> >> ---
> >>
> >> Hi,
> >>
> >> Since this patch is only a RFC, I have not yet updated drivers using this
> >> function.
> >>
> >> I would like to use mmc_of_parse to reduce code duplication. My issue is 
> >> that
> >> atmel mci is a bit different from others mci host since it can provide
> >> several slots, so it allocates several mmc hosts. By the way, it is not the
> >> only one.
> >>
> >> When calling mmc_alloc_host, host->parent is set to &pdev->dev. 
> >> mmc_of_parse
> >> uses host->parent->of_node but in my case settings are in the slot nodes 
> >> so in
> >> the child nodes. That's why I would like to have a way to tell which node I
> >> want to use.
> > 
> > Seems reasonable, thanks for working on this!
> > 
> >>
> >>
> >> Regards
> >>
> >> Ludovic
> >>
> >>
> >>
> >>  drivers/mmc/core/host.c |9 +++--
> >>  1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> >> index fdea825..ed6cea5 100644
> >> --- a/drivers/mmc/core/host.c
> >> +++ b/drivers/mmc/core/host.c
> >> @@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct 
> >> mmc_host *host)
> >>  /**
> >>   * mmc_of_parse() - parse host's device-tree node
> >>   * @host: host whose node should be parsed.
> >> + * @slot: some devices provide several slots so the node to parse
> >> + * is not the host one.
> >>   *
> >>   * To keep the rest of the MMC subsystem unaware of whether DT has been
> >>   * used to to instantiate and configure this host instance or not, we
> >>   * parse the properties and set respective generic mmc-host flags and
> >>   * parameters.
> >>   */
> >> -int mmc_of_parse(struct mmc_host *host)
> >> +int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
> >>  {
> >> struct device_node *np;
> >> u32 bus_width;
> >> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
> >> if (!host->parent || !host->parent->of_node)
> >> return 0;
> >>
> >> -   np = host->parent->of_node;
> >> +   if (slot)
> >> +   np = slot;
> >> +   else
> >> +   np = host->parent->of_node;
> >>
> >> /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
> >> if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
> >> --
> >> 1.7.9.5
> >>
> > 
> > How about adding a new API, __mmc_of_parse((struct mmc_host *host,
> > struct device_node *slot)
> > Then let the old API mmc_of_parse() remain as is, but let it call the
> > new API with slot == NULL.
> > 
> > Atmel can then use the new API, but the other drivers can remain as is.
> > 
> > Kind regards
> > Ulf Hansson
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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/

Re: Radeon wakeup regression in 3.15-rc6

[Malte Schröder]

On 25.05.2014 14:56, Woody Suwalski wrote:
> Malte Schröder wrote:
>> Hi,
>> I just tried 3.15-rc6. I encountered a pretty nasty problem, which is
>> after suspending to RAM the system doesn't wake up properly. v3.14 is
>> fine.
>> On wakeup all seems fine, i.e. hd starts to spin an USB-stuff wakes up.
>> But all I get from the graphics card is a white screen slowly filling
>> with random colored pixels. I had to hard reset the system.
>>
>> I attached the kernel log, the X-servers log, lspci-output and my kernel
>> config.
>>
>> Regards
>> Malte
> I have seen a bit of a screen distortion at the bottom of LCD on Radeon
> after a wakeup.
> I tried to re-run with drm.debug=0x0e, however once I did it - the
> problem has disappeared, and I have not been able to duplicate it again.
> So just watching for now.
> OTOH I have seen (only one time) a black screen after wakeup on Nvidia.
> So maybe some timing is now exposed in PM / DRM...
> 
> Woody
> 
> 

I pulled git://people.freedesktop.org/~deathsimple/linux drm-fixes-3.15
 from http://article.gmane.org/gmane.comp.video.dri.devel/106114 and my
problem is gone ...

-- 
Gruß
Malte Schröder
-
malte...@gmx.de



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks

[Peter Ujfalusi]

Mike,

On 05/06/2014 04:31 PM, Nishanth Menon wrote:
> On 16:24-20140506, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v1:
>> - binding documentation and driver has been separated based on Nishanth 
>> Menon's
>>   comment

Could you take a look at this series please? I really hoped that it would make
it to 3.16...

Thanks,
Péter

>>
>> v1 of the driver can be found:
>> https://lkml.org/lkml/2014/4/3/104
>>
>> Palmas class of devices can provide 32K clock(s) to be used by other devices
>> on the board. Depending on the actual device the provided clocks can be:
>> CLK32K_KG and CLK32K_KGAUDIO
>> or only one:
>> CLK32K_KG (TPS659039 for example)
>>
>> Use separate compatible flags for the two 32K clock.
>> A system which needs or have only one of the 32k clock from
>> Palmas will need to add node(s) for each clock as separate section
>> in the dts file.
>> The two compatible property is:
>> "ti,palmas-clk32kg" for clk32kg clock
>> "ti,palmas-clk32kgaudio" for clk32kgaudio clock
>>
>> Apart from the register control of the clocks - which is done via
>> the clock API there is a posibility to enable the external sleep
>> control. In this way the clock can be enabled/disabled on demand by the
>> user of the clock.
>>
>> Regards,
>> Peter
>> ---
>> Peter Ujfalusi (2):
>>   dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio
>> clocks
>>   clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
>>
>>  .../bindings/clock/clk-palmas-clk32kg-clocks.txt   |  35 +++
>>  drivers/clk/Kconfig|   7 +
>>  drivers/clk/Makefile   |   1 +
>>  drivers/clk/clk-palmas.c   | 307 
>> +
>>  include/dt-bindings/mfd/palmas.h   |  18 ++
>>  5 files changed, 368 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
>>  create mode 100644 drivers/clk/clk-palmas.c
>>  create mode 100644 include/dt-bindings/mfd/palmas.h
>>
>> -- 
>> 1.9.2
>>
> 
> Series:
> Reviewed-by: Nishanth Menon 


--
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: inotify, new idea?

[Richard Weinberger]

Am 26.05.2014 01:46, schrieb Marian Marinov:
> Have anyone of you looked at this: https://github.com/1and1/linux-filemon/
> 
> I haven't stress tested it, but in the past I ported it to more recent 
> kernels:
>   https://github.com/hackman/filemon-patches
> 
> It is not polished, but it works.
> 
> I'm considering fixing some of the issues at has for use in my home setup.

Well, the patch itself has documented its major flaw:
+ * WARNING! This patch has been designed as EXPERIMENTAL. Its usage
+ * is DANGEROUS, because some filesystems could get exhausted by the
+ * masses of ORPHAN INODES!

Thanks,
//richard



signature.asc
Description: OpenPGP digital signature

[RESEND PATCH 2/2] power: max8925: Use of_get_child_by_name

[Krzysztof Kozlowski]

Use of_get_child_by_name to obtain reference to charger node instead of
of_find_node_by_name which can walk outside of the parent node.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/power/max8925_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index 0cf237808d47..a6d45eef64dd 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -443,7 +443,7 @@ max8925_power_dt_init(struct platform_device *pdev)
if (!nproot)
return pdev->dev.platform_data;
 
-   np = of_find_node_by_name(nproot, "charger");
+   np = of_get_child_by_name(nproot, "charger");
if (!np) {
dev_err(&pdev->dev, "failed to find charger node\n");
return NULL;
-- 
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/

[RESEND PATCH 1/2] power: max8925: Fix NULL ptr dereference on memory allocation failure

[Krzysztof Kozlowski]

Check the return value of devm_kzalloc() to fix possible NULL pointer
dereference and properly exit the probe() on memory allocation failure.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/power/max8925_power.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index b4513f284bbc..0cf237808d47 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -452,13 +452,14 @@ max8925_power_dt_init(struct platform_device *pdev)
pdata = devm_kzalloc(&pdev->dev,
sizeof(struct max8925_power_pdata),
GFP_KERNEL);
+   if (!pdata)
+   goto ret;
 
of_property_read_u32(np, "topoff-threshold", &topoff_threshold);
of_property_read_u32(np, "batt-detect", &batt_detect);
of_property_read_u32(np, "fast-charge", &fast_charge);
of_property_read_u32(np, "no-insert-detect", &no_insert_detect);
of_property_read_u32(np, "no-temp-support", &no_temp_support);
-   of_node_put(np);
 
pdata->batt_detect = batt_detect;
pdata->fast_charge = fast_charge;
@@ -466,6 +467,8 @@ max8925_power_dt_init(struct platform_device *pdev)
pdata->no_insert_detect = no_insert_detect;
pdata->no_temp_support = no_temp_support;
 
+ret:
+   of_node_put(np);
return pdata;
 }
 #else
-- 
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: Re: [RFC PATCH 1/2] printk: Add context information to the header of /dev/kmsg

[Yoshihiro YUNOMAE]

Hi Kay,

Thank you for your reply.

(2014/05/19 20:35), Kay Sievers wrote:

On Mon, May 19, 2014 at 7:28 PM, Yoshihiro YUNOMAE
 wrote:

Add context information to the header of /dev/kmsg.

Two printk messages connected with KERN_CONT can be divided in multiple lines
by a different process context message. If the different context message seems
like the 1st divided message, it is difficult to understand which the 2nd
divided message belongs to. This problem can also occur for the situation where
multiple message lines without KERN_CONT are broken into by similar messages.
For example, SCSI disk error messages can be show as follows:

 [110781.736171] sd 2:0:0:0: [sdb]
 [110781.736170] sd 3:0:0:0: [sdc] Unhandled sense code
 [110781.736172] sd 3:0:0:0: [sdc]
 [110781.736175] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
 [110781.736177] sd 3:0:0:0: [sdc]
 [110781.736178] Sense Key : Medium Error [current]
 [110781.736187] Sense Key : Recovered Error
 [110781.736189] [current]


[...]


This patch adds PID and interrupt context flag to the header of /dev/kmsg as
the context information in order to understand relation of output messages. If
PID values of two messages and the interrupt context flags are same, it means
that those messages are same context, so those message have some relation. If
not so, it means that those messages are different context, so users do not
need to take care about the relation of the messages.


[...]


--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -197,6 +197,8 @@ enum log_flags {

  struct printk_log {
 u64 ts_nsec;/* timestamp in nanoseconds */
+   pid_t pid;  /* identify PID */
+   u32 irq_count;  /* identify irq_count */


I don't think it is worth to blow-up this heavily used struct up even
more, just because SCSI cannot log in simple single calls. How about
fixing SCSI to log to a local buffer if it cannot safely print one
line at once.

I'm not convinced, that turning the /dev/kmsg format into an
"annotation language', and requiring a rather complex state machine to
re-construct the "broken" logging makes too much sense here. If tools
rely on properly formatted logging messages, the logging should be
fixed at the source while it is logged, not be reconstructed later.

It is not not my call, but I don't this makes much sense. Continuation
lines are "best effort" not a facility that is or ever was reliable in
the past. I think the proper fix is how the log is created, not how it
is exported.


As we discussed about this issue in LinuxCon Japan, mixed messages will
be fixed in each subsystem. In the SCSI layer, tracing feature will be
used. (http://www.spinics.net/lists/linux-scsi/msg74428.html)
If we found the same issue in other subsystem, we would like to add
new generic printk API to avoid mixed messages.

Thank you,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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 RFC] mmc: add slot argument to mmc_of_parse

[Jaehoon Chung]

Hi, Ludovic.

I have sent the patch based on your RFC patch..how about?
If you have the comment or other opinion, let me know, plz.

https://patchwork.kernel.org/patch/4230101/

It needs to use your suggestion at dw-mmc controller, so i have posted it.

Best Regards,
Jaehoon Chung

On 05/26/2014 04:03 PM, Ludovic Desroches wrote:
> Hi,
> 
> Sorry I was on vacation, I'll send a cleaner patch updating other drivers
> this week.
> 
> Regards
> 
> Ludovic
> 
> On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
>> Hi, All.
>>
>> This patch is working on progress?
>> I want to merge this patch for fixing dw-mmc controller problem.
>>
>> If this patch didn't work on progress, i will send the patch based-on this 
>> patch.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> On 05/14/2014 06:53 PM, Ulf Hansson wrote:
>>> On 7 May 2014 12:06, Ludovic Desroches  wrote:
 Some hosts manage several slots. In these case information such as the bus
 width, chip detect and others are into the slot node. So we have to parse
 child nodes. If not NULL, slot node will be used instead of the device
 node.

 Signed-off-by: Ludovic Desroches 
 ---

 Hi,

 Since this patch is only a RFC, I have not yet updated drivers using this
 function.

 I would like to use mmc_of_parse to reduce code duplication. My issue is 
 that
 atmel mci is a bit different from others mci host since it can provide
 several slots, so it allocates several mmc hosts. By the way, it is not the
 only one.

 When calling mmc_alloc_host, host->parent is set to &pdev->dev. 
 mmc_of_parse
 uses host->parent->of_node but in my case settings are in the slot nodes 
 so in
 the child nodes. That's why I would like to have a way to tell which node I
 want to use.
>>>
>>> Seems reasonable, thanks for working on this!
>>>


 Regards

 Ludovic



  drivers/mmc/core/host.c |9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
 index fdea825..ed6cea5 100644
 --- a/drivers/mmc/core/host.c
 +++ b/drivers/mmc/core/host.c
 @@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct 
 mmc_host *host)
  /**
   * mmc_of_parse() - parse host's device-tree node
   * @host: host whose node should be parsed.
 + * @slot: some devices provide several slots so the node to parse
 + * is not the host one.
   *
   * To keep the rest of the MMC subsystem unaware of whether DT has been
   * used to to instantiate and configure this host instance or not, we
   * parse the properties and set respective generic mmc-host flags and
   * parameters.
   */
 -int mmc_of_parse(struct mmc_host *host)
 +int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
  {
 struct device_node *np;
 u32 bus_width;
 @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
 if (!host->parent || !host->parent->of_node)
 return 0;

 -   np = host->parent->of_node;
 +   if (slot)
 +   np = slot;
 +   else
 +   np = host->parent->of_node;

 /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
 if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
 --
 1.7.9.5

>>>
>>> How about adding a new API, __mmc_of_parse((struct mmc_host *host,
>>> struct device_node *slot)
>>> Then let the old API mmc_of_parse() remain as is, but let it call the
>>> new API with slot == NULL.
>>>
>>> Atmel can then use the new API, but the other drivers can remain as is.
>>>
>>> Kind regards
>>> Ulf Hansson
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.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/

Re: Re: [RFC PATCH 1/2] printk: Add context information to the header of /dev/kmsg

[Yoshihiro YUNOMAE]

Hi,

(2014/05/20 12:36), valdis.kletni...@vt.edu wrote:

On Mon, 19 May 2014 19:28:38 +0900, Yoshihiro YUNOMAE said:


The header information is changed as follows:
/;


Has this been tested with popular userspace that reads /dev/kmsg, to make
sure that it actually plays nice with a 5th field being added?  Yes, I know


I checked it for systemd-journald and rsyslog on the source code level,
those tools don't handle new flag and field before ';' in the header of
/dev/kmsg. Those tools use only log level, sequence#, and timestamp.
So, even if we add these new flag and field for each message,
those tools will be able to work.

But, we'll fix this issue by other method if we found it in any
subsystems except for the SCSI layer.
(In the SCSI layer, we'll tackle this issue by using tracing feature.)

Thank you,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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 V2 0/2] ftrace: Introduce the new I/F "nr_saved_cmdlines"

[Yoshihiro YUNOMAE]

Hi Steven,

Would you review this patch set?

Thanks,
Yoshihiro YUNOMAE

(2014/02/20 17:44), Yoshihiro YUNOMAE wrote:

Hi,

This patch set introduces the new I/F "nr_saved_cmdlines" for increasing
the number of saved cmdlines. Current saved_cmdlines can store just 128 command
names and PIDs, but process names are often lost like <...> when we read trace
data. If the process exists, we can get the name by using ps command. However,
if the process already has not existed, we cannot get the name.

To solve this issue, we introduce the new I/F "nr_saved_cmdlines" to expand
the max number of saved command line names. This I/F is very simple.
If we write a number to nr_saved_cmdlines, the number of command name will be
stored. And, if we read the I/F, we can get current maximum number of command
name. The default number is 128 which is current default number, so this patch
does not change the usage of memory for saved_cmdlines when we boot kernel.

Thanks!

Changes in V2:
- Fix a racing problem of savedcmd between saved_cmdlines I/F and
   nr_saved_cmdlines I/F. If one reads saved_cmdlines and writes a value to
   nr_saved_cmdlines at the same time, then the write returns -EBUSY. [2/2]

---

Yoshihiro YUNOMAE (2):
   ftrace: Make saved_cmdlines use seq_read
   ftrace: Introduce nr_saved_cmdlines I/F


  kernel/trace/trace.c |  316 +-
  1 file changed, 261 insertions(+), 55 deletions(-)



--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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: linux-next: build failure after merge of the devicetree tree

[Thomas Petazzoni]

Dear Stephen Rothwell,

On Mon, 26 May 2014 15:05:57 +1000, Stephen Rothwell wrote:

> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 395ee2b3146d..03e7fc6c93e8 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1901,10 +1901,6 @@ int of_update_property(struct device_node *np, struct 
> property *newprop)
>   if (!of_kset)
>   return 0;
>  
> - /* At early boot, bail out and defer setup to of_init() */
> - if (!of_kset)
> - return found ? 0 : -ENODEV;
> -

Seems like this is in fact reverting my change entirely, so maybe Grant
should drop my patch instead?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal

[Roger Quadros]

Javier,

On 05/23/2014 12:40 PM, Javier Martinez Canillas wrote:
> Hello Roger,
> 
> On Fri, May 23, 2014 at 10:16 AM, Roger Quadros  wrote:
>> Ezequiel & Javier,
>>
>> On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
>>> On 22 May 01:51 PM, Javier Martinez Canillas wrote:
 On Thu, May 22, 2014 at 10:12 AM, Roger Quadros  wrote:
>> On 21 May 02:20 PM, Roger Quadros wrote:
>>>
>>> For DT boot:
>>> - The GPMC controller node should have a chip select (CS) node for each 
>>> used
>>>   chip select. The CS node must have a child device node for each device
>>>   attached to that chip select. Properties for that child are GPMC 
>>> agnostic.
>>>
>>>   i.e.
>>>  gpmc {
>>>  cs0 {
>>>  nand0 {
>>>  }
>>>  };
>>>
>>>  cs1 {
>>>  nor0 {
>>>  }
>>>  }
>>>  ...
>>>  };
>>>
>>
>> While I agree that the GPMC driver is a bit messy, I'm not sure it's 
>> possible
>> to go through such a complete devicetree binding re-design (breaking 
>> backwards
>> compatibility) now that the binding is already in production.
>
> Why not? especially if the existing bindings are poorly dones. Is anyone 
> using these
> bindings burning the DT into ROM and can't change it when they update the 
> kernel?
>

 While I do agree that your DT bindings are much better than the
 current ones, there is a policy that DT bindings are an external API
 and once are released with a kernel are set in stone and can't be
 changed.

>>>
>>> Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
>>> versions. Users can't be coherced into a DTB update after a kernel update.
>>>
>>> That said, I don't really care if you break compatilibity in this case.
>>> Rather, I'm suggesting that you make sure this change is going to be 
>>> accepted
>>> upstream, before doing any more work. The DT maintainers are reluctant to do
>>> so.
>>
>> Appreciate your concern.
>>
>> Would be really nice if you can review patches 1-12. They have nothing to do 
>> with DT changes.
>> Thanks.
>>
> 
> Overall your patches looks good to me. But I think it's better to wait
> until Tony removes the legacy board files for OMAP2+ since AFAIU at
> least the following patches could be dropped or trimmed down when
> board files are gone:
> 
> [RFC PATCH 04/16] ARM: OMAP2+: gpmc: use platform data to configure CS
> space and poplulate
> [RFC PATCH 06/16] ARM: OMAP2+: gpmc: add NAND specific setup
> [RFC PATCH 07/16] ARM: OMAP2+: nand: Update gpmc_nand_init() to use
> generic_gpmc_init()
> 
> Patches 1-3 and 5 are independent and can be applied in the meantime
> as a preparation for further changes following board files removal.
> 
> I really like patches 9-12 since those moves some NAND add-hoc code to
> the NAND driver where it really belongs. I think that similar changes
> can be made for OneNAND and push the special case handling code from
> GPMC driver to drivers/mtd/onenand/omap2.c.
> 
> Other devices (nor, ethernet, uart, etc) are already using
> gpmc_probe_generic_child() so I hope we can isolate the NAND and
> OneNAND specific changes and just use a single probe function for all
> child devices and possibly get even need the enum gpmc_omap_type you
> are adding on your struct gpmc_omap_cs_data.

Yes, I was thinking the same.

> 
> So what do you think if as a first step we add the platform data as
> you propose with all the commons timings and settings there, move all
> the possible code to NAND and OneNAND drivers and try to use a single
> configuration function for all child devices?

Yes, I agree.
> 
> Then once board files are gone we can do further cleanup in the driver
> and then we can discuss about changing the DT bindings. Maybe we can
> even change it while keeping backwards compatibility? Although I'm not
> sure about the last point I think that at least is worth to discuss
> it.

OK.

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] Staging: rtl8192u: r819xU_firmware_img.c Fixed checkpatch.pl ERRORs

[Dan Carpenter]

On Sun, May 25, 2014 at 09:15:06AM -0700, Chaitanya Hazarey wrote:
> Fixed a lot of errors of the type "ERROR: space required after that ',' 
> (ctx:VxV)"
> 
> Added tabs at the beginning of line.
> 
> Signed-off-by: Chaitanya Hazarey 
> ---

Great.  :)  Thanks.

regards,
dan carpenter

--
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: divider: Fix table round up function

[Maxime Coquelin]

On 05/23/2014 11:39 PM, Mike Turquette wrote:

Quoting Maxime COQUELIN (2014-05-07 09:48:52)

Commit 1d9fe6b97 ("clk: divider: Fix best div calculation for power-of-two and
table dividers") introduces a regression in its _table_round_up function.

When the divider passed to this function is greater than the max divider
available in the table, this function returns table's max divider.
Problem is that it causes an infinite loop in clk_divider_bestdiv() because
_next_div() will never return a value greater than maxdiv.

Instead of returning table's max divider, this patch returns INT_MAX.

Reported-by: Fabio Estevam 
Reported-by: Shawn Guo 
Tested-by: Fabio Estevam 
Cc: Mike Turquette 
Signed-off-by: Maxime Coquelin 


Pulled into clk-fixes for -rc7.


Thanks Mike.

Regards,
Maxime



Regards,
Mike


---
  drivers/clk/clk-divider.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index b3c8396..cf9114a 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -158,7 +158,7 @@ static bool _is_valid_div(struct clk_divider *divider, 
unsigned int div)
  static int _round_up_table(const struct clk_div_table *table, int div)
  {
 const struct clk_div_table *clkt;
-   int up = _get_table_maxdiv(table);
+   int up = INT_MAX;

 for (clkt = table; clkt->div; clkt++) {
 if (clkt->div == div)
--
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: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal

[Roger Quadros]

On 05/23/2014 05:53 PM, Tony Lindgren wrote:
> * Roger Quadros  [140523 01:17]:
>> On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
>>> On 22 May 01:51 PM, Javier Martinez Canillas wrote:
 On Thu, May 22, 2014 at 10:12 AM, Roger Quadros  wrote:
>> On 21 May 02:20 PM, Roger Quadros wrote:
>> While I agree that the GPMC driver is a bit messy, I'm not sure it's 
>> possible
>> to go through such a complete devicetree binding re-design (breaking 
>> backwards
>> compatibility) now that the binding is already in production.
>
> Why not? especially if the existing bindings are poorly dones. Is anyone 
> using these
> bindings burning the DT into ROM and can't change it when they update the 
> kernel?
>

 While I do agree that your DT bindings are much better than the
 current ones, there is a policy that DT bindings are an external API
 and once are released with a kernel are set in stone and can't be
 changed.

>>>
>>> Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
>>> versions. Users can't be coherced into a DTB update after a kernel update.
>>>
>>> That said, I don't really care if you break compatilibity in this case.
>>> Rather, I'm suggesting that you make sure this change is going to be 
>>> accepted
>>> upstream, before doing any more work. The DT maintainers are reluctant to do
>>> so.
>>
>> Appreciate your concern.
>>
>> Would be really nice if you can review patches 1-12. They have nothing to do 
>> with DT changes.
>> Thanks.
> 
> I'm mostly concerned about keeping things working. I think the
> only way we can keep things working is to keep support for
> the old binding around in addition to the new one. That way
> we can update devices one at a time.

Good to hear that you are not keen on keeping the old bindings forever. I 
understand
that we need to keep things working during the transition. I'll think of 
something to
maintain backward compatibility while supporting the new binding.

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/

linux-next: manual merge of the cgroup tree with Linus' tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in
mm/memcontrol.c between commit 6f6acb00514c ("memcg: fix swapcache
charge from kernel thread context") from Linus' tree and commit
ec903c0c858e ("cgroup: rename css_tryget*() to css_tryget_online*()")
from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc mm/memcontrol.c
index 5177c6d4a2dd,b6f91d61b3af..
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -1077,19 -1074,10 +1074,19 @@@ static struct mem_cgroup *get_mem_cgrou
  
rcu_read_lock();
do {
 -  memcg = mem_cgroup_from_task(rcu_dereference(mm->owner));
 -  if (unlikely(!memcg))
 +  /*
 +   * Page cache insertions can happen withou an
 +   * actual mm context, e.g. during disk probing
 +   * on boot, loopback IO, acct() writes etc.
 +   */
 +  if (unlikely(!mm))
memcg = root_mem_cgroup;
 +  else {
 +  memcg = 
mem_cgroup_from_task(rcu_dereference(mm->owner));
 +  if (unlikely(!memcg))
 +  memcg = root_mem_cgroup;
 +  }
-   } while (!css_tryget(&memcg->css));
+   } while (!css_tryget_online(&memcg->css));
rcu_read_unlock();
return memcg;
  }


signature.asc
Description: PGP signature

Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace f2fs_submit_page_mbio event in ra_sum_pages

[Changman Lee]

On Mon, May 26, 2014 at 02:26:24PM +0800, Chao Yu wrote:
> Hi changman,
> 
> > -Original Message-
> > From: Changman Lee [mailto:cm224@samsung.com]
> > Sent: Friday, May 23, 2014 1:14 PM
> > To: Jaegeuk Kim
> > Cc: Chao Yu; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: Re: [f2fs-dev] [PATCH] f2fs: avoid crash when trace 
> > f2fs_submit_page_mbio event in
> > ra_sum_pages
> > 
> > On Wed, May 21, 2014 at 12:36:46PM +0900, Jaegeuk Kim wrote:
> > > Hi Chao,
> > >
> > > 2014-05-16 (금), 17:14 +0800, Chao Yu:
> > > > Previously we allocate pages with no mapping in ra_sum_pages(), so we 
> > > > may
> > > > encounter a crash in event trace of f2fs_submit_page_mbio where we 
> > > > access
> > > > mapping data of the page.
> > > >
> > > > We'd better allocate pages in bd_inode mapping and invalidate these 
> > > > pages after
> > > > we restore data from pages. It could avoid crash in above scenario.
> > > >
> > > > Call Trace:
> > > >  [] ? ftrace_raw_event_f2fs_write_checkpoint+0x80/0x80 [f2fs]
> > > >  [] f2fs_submit_page_mbio+0x1cb/0x200 [f2fs]
> > > >  [] restore_node_summary+0x13a/0x280 [f2fs]
> > > >  [] build_curseg+0x2bd/0x620 [f2fs]
> > > >  [] build_segment_manager+0x1cb/0x920 [f2fs]
> > > >  [] f2fs_fill_super+0x535/0x8e0 [f2fs]
> > > >  [] mount_bdev+0x16a/0x1a0
> > > >  [] f2fs_mount+0x1f/0x30 [f2fs]
> > > >  [] mount_fs+0x36/0x170
> > > >  [] vfs_kern_mount+0x55/0xe0
> > > >  [] do_mount+0x1e8/0x900
> > > >  [] SyS_mount+0x82/0xc0
> > > >  [] sysenter_do_call+0x12/0x22
> > > >
> > > > Signed-off-by: Chao Yu 
> > > > ---
> > > >  fs/f2fs/node.c |   49 -
> > > >  1 file changed, 28 insertions(+), 21 deletions(-)
> > > >
> > > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > > > index 3d60d3d..b5cd814 100644
> > > > --- a/fs/f2fs/node.c
> > > > +++ b/fs/f2fs/node.c
> > > > @@ -1658,13 +1658,16 @@ int recover_inode_page(struct f2fs_sb_info 
> > > > *sbi, struct page *page)
> > > >
> > > >  /*
> > > >   * ra_sum_pages() merge contiguous pages into one bio and submit.
> > > > - * these pre-readed pages are linked in pages list.
> > > > + * these pre-readed pages are alloced in bd_inode's mapping tree.
> > > >   */
> > > > -static int ra_sum_pages(struct f2fs_sb_info *sbi, struct list_head 
> > > > *pages,
> > > > +static int ra_sum_pages(struct f2fs_sb_info *sbi, struct page **pages,
> > > > int start, int nrpages)
> > > >  {
> > > > struct page *page;
> > > > +   struct inode *inode = sbi->sb->s_bdev->bd_inode;
> > 
> > How about use sbi->meta_inode instead of bd_inode, then we can do
> > caching summary pages for further i/o.
> 
> In my understanding, In ra_sum_pages() we readahead node pages in NODE 
> segment,
> then we could padding current summary caching with nid of node page's footer.
> So we should not cache this readaheaded pages in meta_inode's mapping.
> Do I miss something?
> 
> Regards
> 

Sorry, you're right. Forget about caching. I've confused ra_sum_pages with 
summary segments.

> > 
> > > > +   struct address_space *mapping = inode->i_mapping;
> > > > int page_idx = start;
> > > > +   int alloced, readed;
> > > > struct f2fs_io_info fio = {
> > > > .type = META,
> > > > .rw = READ_SYNC | REQ_META | REQ_PRIO
> > > > @@ -1672,21 +1675,23 @@ static int ra_sum_pages(struct f2fs_sb_info 
> > > > *sbi, struct list_head
> > *pages,
> > > >
> > > > for (; page_idx < start + nrpages; page_idx++) {
> > > > /* alloc temporal page for read node summary info*/
> > > > -   page = alloc_page(GFP_F2FS_ZERO);
> > > > +   page = grab_cache_page(mapping, page_idx);
> > > > if (!page)
> > > > break;
> > > > -
> > > > -   lock_page(page);
> > > > -   page->index = page_idx;
> > > > -   list_add_tail(&page->lru, pages);
> > > > +   page_cache_release(page);
> > >
> > > IMO, we don't need to do like this.
> > > Instead,
> > >   for() {
> > >   page = grab_cache_page();
> > >   if (!page)
> > >   break;
> > >   page[page_idx] = page;
> > >   f2fs_submit_page_mbio(sbi, page, &fio);
> > >   }
> > >   f2fs_submit_merged_bio(sbi, META, READ);
> > >   return page_idx - start;
> > >
> > > Afterwards, in restore_node_summry(),
> > >   lock_page() will wait the end_io for read.
> > >   ...
> > >   f2fs_put_page(pages[index], 1);
> > >
> > > Thanks,
> > >
> > > > }
> > > >
> > > > -   list_for_each_entry(page, pages, lru)
> > > > -   f2fs_submit_page_mbio(sbi, page, page->index, &fio);
> > > > +   alloced = page_idx - start;
> > > > +   readed = find_get_pages_contig(mapping, start, alloced, pages);
> > > > +   BUG_ON(alloced != readed);
> > > > +
> > > > +   for (page_

[RESEND PATCH 0/5] charger/mfd: max14577: Part 2 of adding support for MAX77836

[Krzysztof Kozlowski]

Dear Dmitry, David,


This is resend of second part of patches adding support for MAX77836
device to the max14577 drivers.

These patches are hanging on the lists for some time. Could you
look at them and give me acks or any comment what have to be fixed?

It is still before 3.16 merge window so your acks would be appreciated.
If it is possible I would like to push the patches through Lee Jones'
MFD tree (I already have other necessary acks).


I need acks or reviews from power supply subsystem maintainers for
patches:
 - 1/5: charger: max14577: Add support for MAX77836 charger
 - 3/5: charger: max14577: Configure battery-dependent settings from DTS
 - 4/5: power: max17040: Add ID for MAX77836 Fuel Gauge block
These patches were published for the first time around February 2014.

Could you look at them?


Below is original cover letter.


Best regards,
Krzysztof Kozlowski


Cover letter


This is second part of patches adding support for MAX77836 device
to the max14577 drivers.

The first part [1] was applied by Lee Jones [2][3] and this patchset
*depends* on it.

This patchset changes the max14577 charger and regulator drivers
and documents Device Tree bindings.

The patches 1 to 3 depends on each other so they should be pulled at once.
Patches 4, 5 and 6 can be applied independently. However still the
smoothest way to apply this would be through one tree after obtaining
necessary acks from maintainers.



Changes since v4 (for this second part only)

1. Updated Kconfig entries mentioning MAX77836.
2. Added patch 5/6 (regulator: max14577: Implement SUSPEND mode for
   MAX77836 LDO-s)
3. Charger: Require a charger subnode in DTS with charger settings.
   Previously the charger driver didn't use any properties from DTS.
   Now it needs a subnode with settings because it supports different
   devices with different charging characteristics.
4. Rebased on 3.15-rc2.

Changes since v3

1. Applied minor fixes (pointed by Lee Jones).
2. Added one ACK (Lee Jones) and Review-by (Tomasz Figa).
3. Patch 14/charger: Minor change in parsing EOC value from DTS.
4. Rebased on next-20140224.

Changes since v2

1. Added ACK-s.
2. Applied minor checkpatch fixes (pointed by Lee Jones).
3. Rebased on next-20140217.

Changes since v1

1. Added ACK-s, reviews and tested-by tags.
2. Removed applied patches (they were merged to the linux-next tree).
3. Applied comments from review (Lee Jones) to 5/15 (detection of device type)
   and 8/15 (add max77836 support to max14577).
4. Rebased on next tree.
5. Added patch 13 and 14 (pointed by Jenny Tc):
   - regulator/mfd: max14577: Export symbols for calculating charger current
   - charger: max14577: Configure battery-dependent settings from DTS
6. Updated bindings documentation with new charger bindings.


References
==
[1] http://thread.gmane.org/gmane.linux.kernel/1682503
[2] http://www.spinics.net/lists/kernel/msg1728274.html
[3] 
https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/log/?h=ib-mfd-extcon-3.16

Previous, full v4 patchset can be found here:
http://thread.gmane.org/gmane.linux.kernel/1654267


Krzysztof Kozlowski (5):
  charger: max14577: Add support for MAX77836 charger
  regulator/mfd: max14577: Export symbols for calculating charger
current
  charger: max14577: Configure battery-dependent settings from DTS
  power: max17040: Add ID for MAX77836 Fuel Gauge block
  devicetree: mfd: max14577: Add device tree bindings document

 Documentation/devicetree/bindings/mfd/max14577.txt | 152 +++
 drivers/mfd/max14577.c | 100 ++-
 drivers/power/Kconfig  |   4 +-
 drivers/power/max14577_charger.c   | 291 ++---
 drivers/power/max17040_battery.c   |   1 +
 drivers/regulator/max14577.c   |  80 +-
 include/linux/mfd/max14577-private.h   |  92 +--
 include/linux/mfd/max14577.h   |  31 +++
 8 files changed, 614 insertions(+), 137 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt

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

[RESEND PATCH 4/5] power: max17040: Add ID for MAX77836 Fuel Gauge block

[Krzysztof Kozlowski]

MAX77836 has the same Fuel Gauge as MAX17040/17048. The max17040 driver
can be safely re-used. The patch adds MAX77836 ID to array of
i2c_device_id.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Anton Vorontsov 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
---
 drivers/power/max17040_battery.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/power/max17040_battery.c b/drivers/power/max17040_battery.c
index 0fbac861080d..165ffe381803 100644
--- a/drivers/power/max17040_battery.c
+++ b/drivers/power/max17040_battery.c
@@ -278,6 +278,7 @@ static SIMPLE_DEV_PM_OPS(max17040_pm_ops, max17040_suspend, 
max17040_resume);
 
 static const struct i2c_device_id max17040_id[] = {
{ "max17040", 0 },
+   { "max77836-battery", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, max17040_id);
-- 
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/

[RESEND PATCH 1/5] charger: max14577: Add support for MAX77836 charger

[Krzysztof Kozlowski]

Add support for MAX77836 charger to the max14577 driver. The MAX77836
charger is almost the same as 14577 model except:
 - No dead-battery detection;
 - Support for special charger (like in MAX77693);
 - Support for DX over-voltage protection (like in MAX77693);
 - Lower values of charging current (two times lower current for
   slow/fast charge, much lower EOC current);
 - Slightly different values in ChgTyp field of STATUS2 register. On
   MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
   0x6 means special charger and 0x7 is reserved. Regardless of these
   differences the driver maps them to one enum max14577_muic_charger_type.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Anton Vorontsov 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
Acked-by: Lee Jones 
---
 drivers/power/Kconfig|  4 +-
 drivers/power/max14577_charger.c | 77 +---
 include/linux/mfd/max14577-private.h | 54 ++---
 3 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ba6975123071..94086a5238c6 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -318,11 +318,11 @@ config CHARGER_MANAGER
   with help of suspend_again support.
 
 config CHARGER_MAX14577
-   tristate "Maxim MAX14577 MUIC battery charger driver"
+   tristate "Maxim MAX14577/77836 battery charger driver"
depends on MFD_MAX14577
help
  Say Y to enable support for the battery charger control sysfs and
- platform data of MAX14577 MUICs.
+ platform data of MAX14577/77836 MUICs.
 
 config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index fad2a75b3604..19c8f42abf24 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -1,7 +1,7 @@
 /*
- * Battery charger driver for the Maxim 14577
+ * max14577_charger.c - Battery charger driver for the Maxim 14577/77836
  *
- * Copyright (C) 2013 Samsung Electronics
+ * Copyright (C) 2013,2014 Samsung Electronics
  * Krzysztof Kozlowski 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -25,10 +25,35 @@ struct max14577_charger {
struct max14577 *max14577;
struct power_supply charger;
 
-   unsigned intcharging_state;
-   unsigned intbattery_state;
+   unsigned intcharging_state;
+   unsigned intbattery_state;
 };
 
+/*
+ * Helper function for mapping values of STATUS2/CHGTYP register on max14577
+ * and max77836 chipsets to enum maxim_muic_charger_type.
+ */
+static enum max14577_muic_charger_type maxim_get_charger_type(
+   enum maxim_device_type dev_type, u8 val) {
+   switch (val) {
+   case MAX14577_CHARGER_TYPE_NONE:
+   case MAX14577_CHARGER_TYPE_USB:
+   case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
+   case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
+   case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
+   case MAX14577_CHARGER_TYPE_SPECIAL_1A:
+   return val;
+   case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+   case MAX14577_CHARGER_TYPE_RESERVED:
+   if (dev_type == MAXIM_DEVICE_TYPE_MAX77836)
+   val |= 0x8;
+   return val;
+   default:
+   WARN_ONCE(1, "max14577: Unsupported chgtyp register value 
0x%02x", val);
+   return val;
+   }
+}
+
 static int max14577_get_charger_state(struct max14577_charger *chg)
 {
struct regmap *rmap = chg->max14577->regmap;
@@ -89,19 +114,23 @@ static int max14577_get_online(struct max14577_charger 
*chg)
 {
struct regmap *rmap = chg->max14577->regmap;
u8 reg_data;
+   enum max14577_muic_charger_type chg_type;
 
max14577_read_reg(rmap, MAX14577_MUIC_REG_STATUS2, ®_data);
reg_data = ((reg_data & STATUS2_CHGTYP_MASK) >> STATUS2_CHGTYP_SHIFT);
-   switch (reg_data) {
+   chg_type = maxim_get_charger_type(chg->max14577->dev_type, reg_data);
+   switch (chg_type) {
case MAX14577_CHARGER_TYPE_USB:
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
case MAX14577_CHARGER_TYPE_DEAD_BATTERY:
+   case MAX77836_CHARGER_TYPE_SPECIAL_BIAS:
return 1;
case MAX14577_CHARGER_TYPE_NONE:
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
case MAX14577_CHARGER_TYPE_RESERVED:
+   case MAX77836_CHARGER_TYPE_RESERVED:
default:
return 0;
}
@@ -118,10 +147,12 @@ static int max14577_get_battery_health(struct 
max14577_charger *chg)
struct regmap *rmap = chg->max14577->regmap;
int state = POWER_SUPPLY_HEALTH_GOOD;
u8 reg_data;
+   enum max14577_muic_charger_type chg_ty

Re: [PATCH RFC] mmc: add slot argument to mmc_of_parse

[Ludovic Desroches]

On Mon, May 26, 2014 at 09:03:01AM +0200, Ludovic Desroches wrote:
> Hi,
> 
> Sorry I was on vacation, I'll send a cleaner patch updating other drivers
> this week.

Continuing to clear out my inbox, I have seen you send a patch for it.
Thanks. 

> 
> Regards
> 
> Ludovic
> 
> On Fri, May 23, 2014 at 01:38:06PM +0900, Jaehoon Chung wrote:
> > Hi, All.
> > 
> > This patch is working on progress?
> > I want to merge this patch for fixing dw-mmc controller problem.
> > 
> > If this patch didn't work on progress, i will send the patch based-on this 
> > patch.
> > 
> > Best Regards,
> > Jaehoon Chung
> > 
> > On 05/14/2014 06:53 PM, Ulf Hansson wrote:
> > > On 7 May 2014 12:06, Ludovic Desroches  
> > > wrote:
> > >> Some hosts manage several slots. In these case information such as the 
> > >> bus
> > >> width, chip detect and others are into the slot node. So we have to parse
> > >> child nodes. If not NULL, slot node will be used instead of the device
> > >> node.
> > >>
> > >> Signed-off-by: Ludovic Desroches 
> > >> ---
> > >>
> > >> Hi,
> > >>
> > >> Since this patch is only a RFC, I have not yet updated drivers using this
> > >> function.
> > >>
> > >> I would like to use mmc_of_parse to reduce code duplication. My issue is 
> > >> that
> > >> atmel mci is a bit different from others mci host since it can provide
> > >> several slots, so it allocates several mmc hosts. By the way, it is not 
> > >> the
> > >> only one.
> > >>
> > >> When calling mmc_alloc_host, host->parent is set to &pdev->dev. 
> > >> mmc_of_parse
> > >> uses host->parent->of_node but in my case settings are in the slot nodes 
> > >> so in
> > >> the child nodes. That's why I would like to have a way to tell which 
> > >> node I
> > >> want to use.
> > > 
> > > Seems reasonable, thanks for working on this!
> > > 
> > >>
> > >>
> > >> Regards
> > >>
> > >> Ludovic
> > >>
> > >>
> > >>
> > >>  drivers/mmc/core/host.c |9 +++--
> > >>  1 file changed, 7 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > >> index fdea825..ed6cea5 100644
> > >> --- a/drivers/mmc/core/host.c
> > >> +++ b/drivers/mmc/core/host.c
> > >> @@ -300,13 +300,15 @@ static inline void mmc_host_clk_sysfs_init(struct 
> > >> mmc_host *host)
> > >>  /**
> > >>   * mmc_of_parse() - parse host's device-tree node
> > >>   * @host: host whose node should be parsed.
> > >> + * @slot: some devices provide several slots so the node to parse
> > >> + * is not the host one.
> > >>   *
> > >>   * To keep the rest of the MMC subsystem unaware of whether DT has been
> > >>   * used to to instantiate and configure this host instance or not, we
> > >>   * parse the properties and set respective generic mmc-host flags and
> > >>   * parameters.
> > >>   */
> > >> -int mmc_of_parse(struct mmc_host *host)
> > >> +int mmc_of_parse(struct mmc_host *host, struct device_node *slot)
> > >>  {
> > >> struct device_node *np;
> > >> u32 bus_width;
> > >> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
> > >> if (!host->parent || !host->parent->of_node)
> > >> return 0;
> > >>
> > >> -   np = host->parent->of_node;
> > >> +   if (slot)
> > >> +   np = slot;
> > >> +   else
> > >> +   np = host->parent->of_node;
> > >>
> > >> /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
> > >> if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
> > >> --
> > >> 1.7.9.5
> > >>
> > > 
> > > How about adding a new API, __mmc_of_parse((struct mmc_host *host,
> > > struct device_node *slot)
> > > Then let the old API mmc_of_parse() remain as is, but let it call the
> > > new API with slot == NULL.
> > > 
> > > Atmel can then use the new API, but the other drivers can remain as is.
> > > 
> > > Kind regards
> > > Ulf Hansson
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.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/

[RESEND PATCH 3/5] charger: max14577: Configure battery-dependent settings from DTS

[Krzysztof Kozlowski]

Remove hard-coded values for:
 - Fast Charge current,
 - End Of Charge current,
 - Fast Charge timer,
 - Overvoltage Protection Threshold,
 - Battery Constant Voltage,
and use DTS to configure them. This allows using the max14577 charger
driver with different batteries.

Now the charger driver requires valid configuration data from DTS. In
case of wrong configuration data it fails during probe. Patch adds
of_compatible to the charger mfd cell in MFD driver core.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
Cc: Jenny Tc 
Acked-by: Lee Jones 
---
 drivers/mfd/max14577.c   |   5 +-
 drivers/power/max14577_charger.c | 232 +++
 include/linux/mfd/max14577-private.h |  16 +++
 include/linux/mfd/max14577.h |   8 ++
 4 files changed, 233 insertions(+), 28 deletions(-)

diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index cef2149ac096..13030573a8ca 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -116,7 +116,10 @@ static struct mfd_cell max14577_devs[] = {
.name = "max14577-regulator",
.of_compatible = "maxim,max14577-regulator",
},
-   { .name = "max14577-charger", },
+   {
+   .name = "max14577-charger",
+   .of_compatible = "maxim,max14577-charger",
+   },
 };
 
 static struct mfd_cell max77836_devs[] = {
diff --git a/drivers/power/max14577_charger.c b/drivers/power/max14577_charger.c
index 19c8f42abf24..f32f94a9a144 100644
--- a/drivers/power/max14577_charger.c
+++ b/drivers/power/max14577_charger.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct max14577_charger {
struct device *dev;
@@ -27,6 +28,8 @@ struct max14577_charger {
 
unsigned intcharging_state;
unsigned intbattery_state;
+
+   struct max14577_charger_platform_data   *pdata;
 };
 
 /*
@@ -178,15 +181,107 @@ static int max14577_get_present(struct max14577_charger 
*chg)
return 1;
 }
 
+static inline int max14577_init_constant_voltage(struct max14577_charger *chg,
+   unsigned int uvolt)
+{
+   u8 reg_data;
+
+   if (uvolt < MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN ||
+   uvolt > MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+   return -EINVAL;
+
+   if (uvolt == 420)
+   reg_data = 0x0;
+   else if (uvolt == MAXIM_CHARGER_CONSTANT_VOLTAGE_MAX)
+   reg_data = 0x1f;
+   else if (uvolt <= 428) {
+   unsigned int val = uvolt;
+
+   val -= MAXIM_CHARGER_CONSTANT_VOLTAGE_MIN;
+   val /= MAXIM_CHARGER_CONSTANT_VOLTAGE_STEP;
+   if (uvolt <= 418)
+   reg_data = 0x1 + val;
+   else
+   reg_data = val; /* Fix for gap between 4.18V and 4.22V 
*/
+   } else
+   return -EINVAL;
+
+   reg_data <<= CHGCTRL3_MBCCVWRC_SHIFT;
+
+   return max14577_write_reg(chg->max14577->regmap,
+   MAX14577_CHG_REG_CHG_CTRL3, reg_data);
+}
+
+static inline int max14577_init_eoc(struct max14577_charger *chg,
+   unsigned int uamp)
+{
+   unsigned int current_bits = 0xf;
+   u8 reg_data;
+
+   switch (chg->max14577->dev_type) {
+   case MAXIM_DEVICE_TYPE_MAX77836:
+   if (uamp < 5000)
+   return -EINVAL; /* Requested current is too low */
+
+   if (uamp >= 7500 && uamp < 1)
+   current_bits = 0x0;
+   else if (uamp <= 5) {
+   /* <5000, 7499> and <1, 5> */
+   current_bits = uamp / 5000;
+   } else {
+   uamp = min(uamp, 10U) - 5U;
+   current_bits = 0xa + uamp / 1;
+   }
+   break;
+
+   case MAXIM_DEVICE_TYPE_MAX14577:
+   default:
+   if (uamp < MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN)
+   return -EINVAL; /* Requested current is too low */
+
+   uamp = min(uamp, MAX14577_CHARGER_EOC_CURRENT_LIMIT_MAX);
+   uamp -= MAX14577_CHARGER_EOC_CURRENT_LIMIT_MIN;
+   current_bits = uamp / MAX14577_CHARGER_EOC_CURRENT_LIMIT_STEP;
+   break;
+   }
+
+   reg_data = current_bits << CHGCTRL5_EOCS_SHIFT;
+
+   return max14577_update_reg(chg->max14577->regmap,
+   MAX14577_CHG_REG_CHG_CTRL5, CHGCTRL5_EOCS_MASK,
+   reg_data);
+}
+
+static inline int max14577_init_fast_charge(struct max14577_charger *chg,
+   unsigned int uamp)
+{
+   u8 reg_data;
+   int ret;
+   const struct maxim_charger_current *limits =
+   &maxim_charger_currents[chg->max14577->dev_type];
+
+   ret = maxim_charger_calc_reg_current(limits, uamp, uamp, ®_data);
+   if (ret) {
+  

Re: [PATCH v2 01/11] sched: fix imbalance flag reset

[Vincent Guittot]

On 25 May 2014 12:33, Preeti U Murthy  wrote:
> Hi Vincent,
>
> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
>> The imbalance flag can stay set whereas there is no imbalance.
>>
>> Let assume that we have 3 tasks that run on a dual cores /dual cluster 
>> system.
>> We will have some idle load balance which are triggered during tick.
>> Unfortunately, the tick is also used to queue background work so we can reach
>> the situation where short work has been queued on a CPU which already runs a
>> task. The load balance will detect this imbalance (2 tasks on 1 CPU and an 
>> idle
>> CPU) and will try to pull the waiting task on the idle CPU. The waiting task 
>> is
>> a worker thread that is pinned on a CPU so an imbalance due to pinned task is
>> detected and the imbalance flag is set.
>> Then, we will not be able to clear the flag because we have at most 1 task on
>> each CPU but the imbalance flag will trig to useless active load balance
>> between the idle CPU and the busy CPU.
>
> Why do we do active balancing today when there is at-most 1 task on the
> busiest cpu? Shouldn't we be skipping load balancing altogether? If we
> do active balancing when the number of tasks = 1, it will lead to a ping
> pong right?

That's the purpose of the patch to prevent this useless active load
balance. When the imbalance flag is set, an active load balance is
triggered whatever the load balance is because of pinned tasks that
prevents a balance state.

Vincent

>
> Regards
> Preeti U Murthy
>
--
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: manual merge of the clockevents tree with the arm-soc tree

[Shawn Guo]

Hi Daniel,

On Mon, May 26, 2014 at 03:43:31PM +1000, Stephen Rothwell wrote:
> Hi Daniel,
> 
> Today's linux-next merge of the clockevents tree got a conflict in
> arch/arm/boot/dts/vf610.dtsi between commit 0517fe6aa880 ("ARM: dts:
> vf610-twr: Add support for sdhc1") from the arm-soc tree and commit
> 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer
> node") from the clockevents tree.

Next time, please leave the dts patches to go via arch tree, so that we
can save such conflicts.

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

[RESEND PATCH 2/5] regulator/mfd: max14577: Export symbols for calculating charger current

[Krzysztof Kozlowski]

This patch prepares for changing the max14577 charger driver to allow
configuring battery-dependent settings from DTS.

The patch moves from regulator driver to MFD core driver and exports:
 - function for calculating register value for charger's current;
 - table of limits for chargers (MAX14577, MAX77836).

Previously they were used only by the max14577 regulator driver. In next
patch the charger driver will use them as well. Exporting them will
reduce unnecessary code duplication.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Acked-by: Mark Brown 
Acked-by: Lee Jones 
---
 drivers/mfd/max14577.c   | 95 
 drivers/regulator/max14577.c | 80 ++
 include/linux/mfd/max14577-private.h | 22 -
 include/linux/mfd/max14577.h | 23 +
 4 files changed, 133 insertions(+), 87 deletions(-)

diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
index 484d372a4892..cef2149ac096 100644
--- a/drivers/mfd/max14577.c
+++ b/drivers/mfd/max14577.c
@@ -26,6 +26,87 @@
 #include 
 #include 
 
+/*
+ * Table of valid charger currents for different Maxim chipsets.
+ * It is placed here because it is used by both charger and regulator driver.
+ */
+const struct maxim_charger_current maxim_charger_currents[] = {
+   [MAXIM_DEVICE_TYPE_UNKNOWN] = { 0, 0, 0, 0 },
+   [MAXIM_DEVICE_TYPE_MAX14577] = {
+   .min= MAX14577_CHARGER_CURRENT_LIMIT_MIN,
+   .high_start = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_START,
+   .high_step  = MAX14577_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+   .max= MAX14577_CHARGER_CURRENT_LIMIT_MAX,
+   },
+   [MAXIM_DEVICE_TYPE_MAX77836] = {
+   .min= MAX77836_CHARGER_CURRENT_LIMIT_MIN,
+   .high_start = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_START,
+   .high_step  = MAX77836_CHARGER_CURRENT_LIMIT_HIGH_STEP,
+   .max= MAX77836_CHARGER_CURRENT_LIMIT_MAX,
+   },
+};
+EXPORT_SYMBOL_GPL(maxim_charger_currents);
+
+/*
+ * maxim_charger_calc_reg_current - Calculate register value for current
+ * @limits:constraints for charger, matching the MBCICHWRC register
+ * @min_ua:minimal requested current, micro Amps
+ * @max_ua:maximum requested current, micro Amps
+ * @dst:   destination to store calculated register value
+ *
+ * Calculates the value of MBCICHWRC (Fast Battery Charge Current) register
+ * for given current and stores it under pointed 'dst'. The stored value
+ * combines low bit (MBCICHWRCL) and high bits (MBCICHWRCH). It is also
+ * properly shifted.
+ *
+ * The calculated register value matches the current which:
+ *  - is always between ;
+ *  - is always less or equal to max_ua;
+ *  - is the highest possible value;
+ *  - may be lower than min_ua.
+ *
+ * On success returns 0. On error returns -EINVAL (requested min/max current
+ * is outside of given charger limits) and 'dst' is not set.
+ */
+int maxim_charger_calc_reg_current(const struct maxim_charger_current *limits,
+   unsigned int min_ua, unsigned int max_ua, u8 *dst)
+{
+   unsigned int current_bits = 0xf;
+
+   if (min_ua > max_ua)
+   return -EINVAL;
+
+   if (min_ua > limits->max || max_ua < limits->min)
+   return -EINVAL;
+
+   if (max_ua < limits->high_start) {
+   /*
+* Less than high_start, so set the minimal current
+* (turn Low Bit off, 0 as high bits).
+*/
+   *dst = 0x0;
+   return 0;
+   }
+
+   /* max_ua is in range: , cut it to limits.max */
+   max_ua = min(limits->max, max_ua);
+   max_ua -= limits->high_start;
+   /*
+* There is no risk of overflow 'max_ua' here because:
+*  - max_ua >= limits.high_start
+*  - BUILD_BUG checks that 'limits' are: max >= high_start + high_step
+*/
+   current_bits = max_ua / limits->high_step;
+
+   /* Turn Low Bit on (use range ) ... */
+   *dst = 0x1 << CHGCTRL4_MBCICHWRCL_SHIFT;
+   /* and set proper High Bits */
+   *dst |= current_bits << CHGCTRL4_MBCICHWRCH_SHIFT;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(maxim_charger_calc_reg_current);
+
 static struct mfd_cell max14577_devs[] = {
{
.name = "max14577-muic",
@@ -465,6 +546,20 @@ static int __init max14577_i2c_init(void)
BUILD_BUG_ON(ARRAY_SIZE(max14577_i2c_id) != MAXIM_DEVICE_TYPE_NUM);
BUILD_BUG_ON(ARRAY_SIZE(max14577_dt_match) != MAXIM_DEVICE_TYPE_NUM);
 
+   /* Valid charger current values must be provided for each chipset */
+   BUILD_BUG_ON(ARRAY_SIZE(maxim_charger_currents) != 
MAXIM_DEVICE_TYPE_NUM);
+
+   /* Check for valid values for charger */
+   BUILD_BUG_ON(MAX14577_CHARGER_CURRENT_LIMIT_HIGH_START +
+   MAX14577_CHARGER_CURRENT_LIMIT_HIGH_STEP * 0xf !

[RESEND PATCH 5/5] devicetree: mfd: max14577: Add device tree bindings document

[Krzysztof Kozlowski]

Add document describing device tree bindings for MAX14577 MFD
drivers: MFD core, extcon, regulator and charger.

Both MAX14577 and MAX77836 chipsets are documented.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Cc: Tomasz Figa 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Reviewed-by: Tomasz Figa 
---
 Documentation/devicetree/bindings/mfd/max14577.txt | 152 +
 1 file changed, 152 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt

diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt 
b/Documentation/devicetree/bindings/mfd/max14577.txt
new file mode 100644
index ..b235250a7b41
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max14577.txt
@@ -0,0 +1,152 @@
+Maxim MAX14577/77836 Multi-Function Device
+
+MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+
+Battery Charger and SFOUT LDO output for powering USB devices. It is
+interfaced to host controller using I2C.
+
+MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge.
+
+
+Required properties:
+- compatible : Must be "maxim,max14577" or "maxim,max77836".
+- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836)
+- interrupts : IRQ line for the chip.
+- interrupt-parent :  The parent interrupt controller.
+
+
+Required nodes:
+ - charger :
+   Node for configuring the charger driver.
+   Required properties:
+   - compatible : "maxim,max14577-charger"
+   or "maxim,max77836-charger"
+   - maxim,fast-charge-timer : Timer in hours to trigger the
+   INT3/MBCCHGERR interrupt; Valid values:
+   - 5, 6 or 7 (hours),
+   - 0 to disable.
+   - maxim,fast-charge-uamp : Current in uA for Fast Charge;
+   Valid values:
+   - for max14577: 9 - 95;
+   - for max77836: 45000 - 475000;
+   - maxim,eoc-uamp : Current in uA for End-Of-Charge mode;
+   Valid values:
+   - for max14577: 5 - 20;
+   - for max77836: 5000 - 10;
+   - maxim,ovp-uvolt : OverVoltage Protection Threshold in uV;
+   In an overvoltage condition, INT asserts and charging
+   stops. Valid values:
+   - 600, 650, 700, 750;
+   - maxim,constant-uvolt : Battery Constant Voltage in uV;
+   Valid values:
+   - 400 - 428 (step by 2);
+   - 435;
+
+
+Optional nodes:
+- max14577-muic/max77836-muic :
+   Node used only by extcon consumers.
+   Required properties:
+   - compatible : "maxim,max14577-muic" or "maxim,max77836-muic"
+
+- regulators :
+   Required properties:
+   - compatible : "maxim,max14577-regulator"
+   or "maxim,max77836-regulator"
+
+   May contain a sub-node per regulator from the list below. Each
+   sub-node should contain the constraints and initialization information
+   for that regulator. See regulator.txt for a description of standard
+   properties for these sub-nodes.
+
+   List of valid regulator names:
+   - for max14577: CHARGER, SAFEOUT.
+   - for max77836: CHARGER, SAFEOUT, LDO1, LDO2.
+
+   The SAFEOUT is a fixed voltage regulator so there is no need to specify
+   voltages for it.
+
+
+Example:
+
+#include 
+
+max14577@25 {
+   compatible = "maxim,max14577";
+   reg = <0x25>;
+   interrupt-parent = <&gpx1>;
+   interrupts = <5 IRQ_TYPE_NONE>;
+
+   muic: max14577-muic {
+   compatible = "maxim,max14577-muic";
+   };
+
+   regulators {
+   compatible = "maxim,max14577-regulator";
+
+   SAFEOUT {
+   regulator-name = "SAFEOUT";
+   };
+   CHARGER {
+   regulator-name = "CHARGER";
+   regulator-min-microamp = <9>;
+   regulator-max-microamp = <95>;
+   regulator-boot-on;
+   };
+   };
+
+   charger {
+   compatible = "maxim,max14577-charger";
+
+   maxim,fast-charge-timer = <6>;
+   maxim,constant-uvolt = <435>;
+   maxim,fast-charge-uamp = <45>;
+   maxim,eoc-uamp = <5>;
+   maxim,ovp-uvolt = <650>;
+   };
+};
+
+
+max77836@25 {
+   compatible = "maxim,max77836";
+   reg = <0x25>;
+   interrupt-parent = <&gpx1>;
+   interrupts = <5 IRQ_TYPE_NONE>;
+
+   muic: max77836-muic {
+   compatible = "maxim,max77836-muic";
+   };
+
+   regulators {
+   compatible = "maxi

Re: [PATCH v2] zram: remove global tb_lock with fine grain lock

[Weijie Yang]

Hello,

Sorry for my late reply, because of a biz trip.

On Wed, May 21, 2014 at 3:51 PM, Minchan Kim  wrote:
> Hello Andrew,
>
> On Tue, May 20, 2014 at 03:10:51PM -0700, Andrew Morton wrote:
>> On Thu, 15 May 2014 16:00:47 +0800 Weijie Yang  
>> wrote:
>>
>> > Currently, we use a rwlock tb_lock to protect concurrent access to
>> > the whole zram meta table. However, according to the actual access model,
>> > there is only a small chance for upper user to access the same 
>> > table[index],
>> > so the current lock granularity is too big.
>> >
>> > The idea of optimization is to change the lock granularity from whole
>> > meta table to per table entry (table -> table[index]), so that we can
>> > protect concurrent access to the same table[index], meanwhile allow
>> > the maximum concurrency.
>> > With this in mind, several kinds of locks which could be used as a
>> > per-entry lock were tested and compared:
>> >
>> > ...
>> >
>> > --- a/drivers/block/zram/zram_drv.c
>> > +++ b/drivers/block/zram/zram_drv.c
>> > @@ -179,23 +179,32 @@ static ssize_t comp_algorithm_store(struct device 
>> > *dev,
>> > return len;
>> >  }
>> >
>> > -/* flag operations needs meta->tb_lock */
>> > -static int zram_test_flag(struct zram_meta *meta, u32 index,
>> > -   enum zram_pageflags flag)
>> > +static int zram_test_zero(struct zram_meta *meta, u32 index)
>> >  {
>> > -   return meta->table[index].flags & BIT(flag);
>> > +   return meta->table[index].value & BIT(ZRAM_ZERO);
>> >  }
>> >
>> > -static void zram_set_flag(struct zram_meta *meta, u32 index,
>> > -   enum zram_pageflags flag)
>> > +static void zram_set_zero(struct zram_meta *meta, u32 index)
>> >  {
>> > -   meta->table[index].flags |= BIT(flag);
>> > +   meta->table[index].value |= BIT(ZRAM_ZERO);
>> >  }
>> >
>> > -static void zram_clear_flag(struct zram_meta *meta, u32 index,
>> > -   enum zram_pageflags flag)
>> > +static void zram_clear_zero(struct zram_meta *meta, u32 index)
>> >  {
>> > -   meta->table[index].flags &= ~BIT(flag);
>> > +   meta->table[index].value &= ~BIT(ZRAM_ZERO);
>> > +}
>> > +
>> > +static int zram_get_obj_size(struct zram_meta *meta, u32 index)
>> > +{
>> > +   return meta->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
>> > +}
>> > +
>> > +static void zram_set_obj_size(struct zram_meta *meta,
>> > +   u32 index, int size)
>> > +{
>> > +   meta->table[index].value = (unsigned long)size |
>> > +   ((meta->table[index].value >> ZRAM_FLAG_SHIFT)
>> > +   << ZRAM_FLAG_SHIFT );
>> >  }
>>
>> Let's sort out the types here?  It makes no sense for `size' to be
>> signed.  And I don't think we need *any* 64-bit quantities here
>> (discussed below).
>>
>> So I think we can make `size' a u32 and remove that typecast.
>>
>> Also, please use checkpatch ;)
>>

I will remove the typecast and do checkpatch in the next patch version.

>> >  static inline int is_partial_io(struct bio_vec *bvec)
>> > @@ -255,7 +264,6 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
>> > goto free_table;
>> > }
>> >
>> > -   rwlock_init(&meta->tb_lock);
>> > return meta;
>> >
>> >  free_table:
>> > @@ -304,19 +312,19 @@ static void handle_zero_page(struct bio_vec *bvec)
>> > flush_dcache_page(page);
>> >  }
>> >
>> > -/* NOTE: caller should hold meta->tb_lock with write-side */
>>
>> Can we please update this important comment rather than simply deleting
>> it?
>>

Of couse, I will update it.

>> >  static void zram_free_page(struct zram *zram, size_t index)
>> >  {
>> > struct zram_meta *meta = zram->meta;
>> > unsigned long handle = meta->table[index].handle;
>> > +   int size;
>> >
>> > if (unlikely(!handle)) {
>> > /*
>> >  * No memory is allocated for zero filled pages.
>> >  * Simply clear zero page flag.
>> >  */
>> > -   if (zram_test_flag(meta, index, ZRAM_ZERO)) {
>> > -   zram_clear_flag(meta, index, ZRAM_ZERO);
>> > +   if (zram_test_zero(meta, index)) {
>> > +   zram_clear_zero(meta, index);
>> > atomic64_dec(&zram->stats.zero_pages);
>> > }
>> > return;
>> >
>> > ...
>> >
>> > @@ -64,9 +76,8 @@ enum zram_pageflags {
>> >  /* Allocated for each disk page */
>> >  struct table {
>> > unsigned long handle;
>> > -   u16 size;   /* object size (excluding header) */
>> > -   u8 flags;
>> > -} __aligned(4);
>> > +   unsigned long value;
>> > +};
>>
>> Does `value' need to be 64 bit on 64-bit machines?  I think u32 will be
>> sufficient?  The struct will still be 16 bytes but if we then play
>> around adding __packed to this structure we should be able to shrink it
>> to 12 bytes, save large amounts of memory?
>>

I agree that u32 is sufficient to value(size and flags), the reason I choice
unsigned long is as you said bit_spin_lock() requires a ulong *.

>> And does `handle' n

Re: balance storm

[Mike Galbraith]

On Mon, 2014-05-26 at 11:04 +0800, Libo Chen wrote: 
> hi,
> my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
> 3.4.24stable, startup 50 same process, every process is sample:
> 
>   #include 
> 
>   int main()
>   {
>   for (;;)
>   {
>   unsigned int i = 0;
>while (i< 100){
>i++;
>   }
>   usleep(100);
>   }
> 
>return 0;
>   }
> 
> the result is process uses 15% cpu time, perf tool shows 70w migrations in 5 
> second.

My 8 socket 64 core DL980 running 256 copies (3.14-rt5) munches ~4%/copy
per top, and does roughly 1 sh*tload migrations, nano-work loop or not.
Turn SD_SHARE_PKG_RESOURCES off at MC (not a noop here), and consumption
drops to ~2%/copy, and migrations ('course) mostly go away.

vogelweide:/abuild/mike/:[0]# perf stat -a -e sched:sched_migrate_task -- sleep 
5

 Performance counter stats for 'system wide':

  3108  sched:sched_migrate_task


   5.001367910 seconds time elapsed

(turns SD_SHARE_PKG_RESOURCES back on)

vogelweide:/abuild/mike/:[0]# perf stat -a -e sched:sched_migrate_task -- sleep 
5

 Performance counter stats for 'system wide':

   4182334  sched:sched_migrate_task


   5.001365023 seconds time elapsed

vogelweide:/abuild/mike/:[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] clk: Neaten clk_summary output

[Geert Uytterhoeven]

Hi Mike,

On Fri, May 23, 2014 at 11:12 PM, Mike Turquette  wrote:
> Quoting Geert Uytterhoeven (2014-05-23 00:14:41)
>> On Tue, May 13, 2014 at 2:17 AM, Mike Turquette  
>> wrote:
>> > Quoting Geert Uytterhoeven (2014-03-25 04:16:24)
>> >> From: Geert Uytterhoeven 
>> >>
>> >>   - Limit ruler to 80 characters (was: 81),
>> >>   - Widen rate column by 1 for nicer spacing,
>> >>   - Right-align numbers and their column headers,
>> >>   - Move a newline to reduce the number of seq_printf() calls,
>> >>   - Use set_puts() for fixed strings.
>>
>> >> Signed-off-by: Geert Uytterhoeven 
>> >
>> > Thanks for the fix. Taken into clk-next.
>>
>> I don't see it in clk-next, though?
>
> When I say "clk-next" I really mean my local/private branch. You'll see
> it at the end of today when I push my next set of tested patches out to
> my linaro mirror.

Thanks, I can see it now.

Sorry for being so impatient.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/

linux-next: manual merge of the target-updates tree with the scsi tree

[Stephen Rothwell]

Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/scsi/qla2xxx/qla_target.c between commit f83adb617f55
("qla2xxx: T10-Dif: add T10-PI support") from the scsi tree and commit
ed6849ff4921 ("qla2xxx: Convert to percpu_ida session tag
pre-allocation") from the target-updates tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/scsi/qla2xxx/qla_target.c
index b1d10f9935c7,bd9c725c08e1..
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@@ -2705,15 -2164,18 +2704,22 @@@ done
  
  void qlt_free_cmd(struct qla_tgt_cmd *cmd)
  {
+   struct qla_tgt_sess *sess = cmd->sess;
+ 
 -  BUG_ON(cmd->sg_mapped);
 +  ql_dbg(ql_dbg_tgt, cmd->vha, 0xe074,
 +  "%s: se_cmd[%p] ox_id %04x\n",
 +  __func__, &cmd->se_cmd,
 +  be16_to_cpu(cmd->atio.u.isp24.fcp_hdr.ox_id));
  
 +  BUG_ON(cmd->sg_mapped);
if (unlikely(cmd->free_sg))
kfree(cmd->sg);
-   kmem_cache_free(qla_tgt_cmd_cachep, cmd);
+ 
+   if (!sess || !sess->se_sess) {
+   WARN_ON(1);
+   return;
+   }
+   percpu_ida_free(&sess->se_sess->sess_tag_pool, cmd->se_cmd.map_tag);
  }
  EXPORT_SYMBOL(qlt_free_cmd);
  
@@@ -3149,12 -2533,11 +3119,12 @@@ static void __qlt_do_work(struct qla_tg
atio->u.isp24.fcp_cmnd.add_cdb_len]));
  
ql_dbg(ql_dbg_tgt, vha, 0xe022,
 -  "qla_target: START qla command: %p lun: 0x%04x (tag %d)\n",
 -  cmd, cmd->unpacked_lun, cmd->tag);
 +  "qla_target: START qla cmd: %p se_cmd %p lun: 0x%04x (tag %d) 
len(%d) ox_id %x\n",
 +  cmd, &cmd->se_cmd, cmd->unpacked_lun, cmd->tag, data_length,
 +  cmd->atio.u.isp24.fcp_hdr.ox_id);
  
-   ret = vha->hw->tgt.tgt_ops->handle_cmd(vha, cmd, cdb, data_length,
-   fcp_task_attr, data_dir, bidi);
+   ret = ha->tgt.tgt_ops->handle_cmd(vha, cmd, cdb, data_length,
+ fcp_task_attr, data_dir, bidi);
if (ret != 0)
goto out_term;
/*


signature.asc
Description: PGP signature

Re: [RFT PATCH] regulator: s2mpa01: Use correct register for buck[36] ramp delay

[Sachin Kamat]

Hi Krzysztof

Apologies for the delay. I was on vacation during the early part of
this month and
got busy with some other stuff later and this mail fell through the cracks.


On 23 May 2014 19:49, Krzysztof Kozlowski  wrote:
> Hi Sachin,
>
> The s2mpa01 regulator driver uses wrong registers for ramp delay (buck1
> and buck3 in RAMP1, buck6 in RAMP2) but I am not sure which layout is
> proper (it seems that that buck1 should be in RAMP2 register).
>
> Could you check in S2MPA01 datasheet the registers for ramp delay for
> buck1, buck3 and buck6?

I checked the datasheet available with me and according to it

buck 1 and 6 share the ramp register 0x11 (RAMP2) (bit 4 and 5) and buck 3 uses
bit 4 and 5 of register 0x10 (RAMP1).

-- 
With warm regards,
Sachin
--
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/3] mmc: host: add slot argument to mmc_of_parse

[Ludovic Desroches]

On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
> From: Ludovic Desroches 
> 
> Some hosts manage several slots. In these case information such as the
> bus width, chi detect and others are into the slot node. So we have to

/s/chi detect/chip detect

> parse child node. If not NULL, slot node will be used instead of the
> device node.
> 
> Signed-off-by: Ludovic Desroches 
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/core/host.c  |   13 +
>  include/linux/mmc/host.h |   10 +-
>  2 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 95cceae..0f677b3 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct 
> mmc_host *host)
>  #endif
>  
>  /**
> - *   mmc_of_parse() - parse host's device-tree node
> + *   __mmc_of_parse() - parse host's device-tree node
>   *   @host: host whose node should be parsed.
> + *   @slot : some device provide several slots so the node to parse
> + *   is not the host one.
>   *
>   * To keep the rest of the MMC subsystem unaware of whether DT has been
>   * used to to instantiate and configure this host instance or not, we
>   * parse the properties and set respective generic mmc-host flags and
>   * parameters.
>   */
> -int mmc_of_parse(struct mmc_host *host)
> +int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
>  {
>   struct device_node *np;
>   u32 bus_width;
> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
>   if (!host->parent || !host->parent->of_node)
>   return 0;
>  
> - np = host->parent->of_node;
> + if (slot)
> + np = slot;
> + else
> + np = host->parent->of_node;
>  
>   /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
>   if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
> @@ -459,7 +464,7 @@ out:
>   return ret;
>  }
>  
> -EXPORT_SYMBOL(mmc_of_parse);
> +EXPORT_SYMBOL(__mmc_of_parse);
>  
>  /**
>   *   mmc_alloc_host - initialise the per-host structure.
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 7960424..c62af91 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct device 
> *);
>  int mmc_add_host(struct mmc_host *);
>  void mmc_remove_host(struct mmc_host *);
>  void mmc_free_host(struct mmc_host *);
> -int mmc_of_parse(struct mmc_host *host);
> +int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
> +/*
> + * mmc_of_parse - parse host's device-tree node
> + *   @host: host whose node should be parsed.
> + */
> +static inline int mmc_of_parse(struct mmc_host *host)
> +{
> + return __mmc_of_parse(host, NULL);
> +}
>  
>  static inline void *mmc_priv(struct mmc_host *host)
>  {
> -- 
> 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: Re: [PATCH RESEND] scsi: Output error messages using structured printk in single line

[Yoshihiro YUNOMAE]

Hi Hannes,

(2014/05/21 15:30), Hannes Reinecke wrote:

On 05/21/2014 05:18 AM, Elliott, Robert (Server Storage) wrote:




-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of James Bottomley
Sent: Tuesday, May 20, 2014 9:22 PM
To: Yoshihiro YUNOMAE
Cc: Hannes Reinecke; Prarit Bhargava; linux-s...@vger.kernel.org; Kay
Sievers; linux-kernel@vger.kernel.org; Hidehiro Kawai; yrl.pp-
manager...@hitachi.com; Masami Hiramatsu
Subject: Re: [PATCH RESEND] scsi: Output error messages using structured
printk in single line

On Thu, 2014-02-27 at 13:17 +0900, Yoshihiro YUNOMAE wrote:

+/* Maximum size of a local buffer for structured printk */
+#define SCSI_LOG_LINE_MAX 512
+
+/* Local buffer for structured printk */
+struct scsi_log_line {
+int offset;
+char buf[SCSI_LOG_LINE_MAX];
+};


This piece isn't going to fly; it's an on stack allocation of 0.5kb;
that's too much for small stack kernels.  Just changing this to a kalloc
is going be problematic too because we're in the io paths and the
allocation may fail.  So I appreciate the problem, but I don't think the
solution works.  Could we just tag the messages and use grep to put them
back together?

James



When the system gets busy, I've seen CDB bytes strung out with each
byte getting its own timestamp, with messages from different devices
and threads interleaved together, so like the idea of printing each
line with a single printk() call.

Most lines aren't anywhere near 512 bytes long.  Can this be coded to
let the calling function define an appropriate buffer size for
whatever it is printing, with sizeof() used to bounds check?



As mentioned several times, I'm working on a patchset to update
scsi logging.

The original patchset tried to convert any logging message into a single
statement, which wouldn't be broken up even under heavy load.

While this works reasonably well for most things, printing out decoded
sense with just one line (and not end up in massive switch()
statements) is near impossible.

Plus you'll end up having to use a static buffer at one point, which
again increases the stack size.

The alternative approach as discussed at LSF is to move scsi_logging
over to tracing. There is already some coding for scsi tracing, but


Oh, I didn't attend the meeting, so I didn't know it.
Did you completely change the development from fixing scsi_logging
to using tracing?


in most cases it just duplicates existing logging statements.
So if we were to replace the entire scsi_logging infrastructure
with scsi tracing most of the issues (like chopped-up CDBs) would
be gone.
Plus we would have a far better control about _what_ is being printed.

And yes, I do have some patches for that :-)


I would like to develop the feature together because this
is an important problem.
Would you upload the patches to your tree?
And, would you share current status and issues with us?

Thank you,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.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] arch: cris: arch-v32: drivers: axisflashmap.c: Cleaning up inconsistent NULL checks

[Jesper Nilsson]

On Fri, May 23, 2014 at 06:40:17PM +0200, Rickard Strandqvist wrote:
> Hej Jesper!

Tjo!

> But in several other place in the feature ensures that main_mtd is not NULL.
> (That's what cppcheck base their misjudgment on too)
>
> Then all these checks are unnecessary?

No, it is still necessary to check for NULL, however as I wrote in my reply,
we do check for ptable_head, which is only set if main_mtd is set.

> You should know, looks like you've written most of the code in 2007 :)
>
> Best regards
> Rickard Strandqvist

/Jesper

> 2014-05-23 9:00 GMT+02:00 Jesper Nilsson :
> > On Fri, May 23, 2014 at 12:00:09AM +0200, Rickard Strandqvist wrote:
> >> Cleaning up inconsistent NULL checks.
> >> There is otherwise a risk of a possible null pointer dereference.
> >>
> >> Was largely found by using a static code analysis program called cppcheck.
> >
> > ... and is a false positive.
> >
> > We can't enter this if-block unless ptable_head is set,
> > which is only set if main_mtd is set.
> >
> > It might be useful to add it anyways, but there's a refactoring
> > needed for the axisflashmaps, so I'll keep it for then.
> >
> > /^JN - Jesper Nilsson
> > --
> >Jesper Nilsson -- jesper.nils...@axis.com

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.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/

[PATCH 1/9] drm/exynos: ipp: remove usless list_empty() functions

[Andrzej Hajda]

From: YoungJun Cho 

list_for_each_entry() handles empty lists, so there is no
need to check whether the list is empty first.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 61 +
 1 file changed, 9 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index bf71d97..c8cfa24 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -276,11 +276,6 @@ static struct exynos_drm_ippdrv 
*ipp_find_drv_by_handle(u32 prop_id)
 
DRM_DEBUG_KMS("prop_id[%d]\n", prop_id);
 
-   if (list_empty(&exynos_drm_ippdrv_list)) {
-   DRM_DEBUG_KMS("ippdrv_list is empty.\n");
-   return ERR_PTR(-ENODEV);
-   }
-
/*
 * This case is search ipp driver by prop_id handle.
 * sometimes, ipp subsystem find driver by prop_id.
@@ -289,11 +284,9 @@ static struct exynos_drm_ippdrv 
*ipp_find_drv_by_handle(u32 prop_id)
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]\n", count++, (int)ippdrv);
 
-   if (!list_empty(&ippdrv->cmd_list)) {
-   list_for_each_entry(c_node, &ippdrv->cmd_list, list)
-   if (c_node->property.prop_id == prop_id)
-   return ippdrv;
-   }
+   list_for_each_entry(c_node, &ippdrv->cmd_list, list)
+   if (c_node->property.prop_id == prop_id)
+   return ippdrv;
}
 
return ERR_PTR(-ENODEV);
@@ -573,11 +566,6 @@ static int ipp_check_mem_list(struct 
drm_exynos_ipp_cmd_node *c_node)
/* source/destination memory list */
head = &c_node->mem_list[i];
 
-   if (list_empty(head)) {
-   DRM_DEBUG_KMS("%s memory empty.\n", i ? "dst" : "src");
-   continue;
-   }
-
/* find memory node entry */
list_for_each_entry(m_node, head, list) {
DRM_DEBUG_KMS("%s,count[%d]m_node[0x%x]\n",
@@ -816,11 +804,6 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node 
*c_node,
struct drm_exynos_ipp_send_event *e, *te;
int count = 0;
 
-   if (list_empty(&c_node->event_list)) {
-   DRM_DEBUG_KMS("event_list is empty.\n");
-   return;
-   }
-
list_for_each_entry_safe(e, te, &c_node->event_list, base.link) {
DRM_DEBUG_KMS("count[%d]e[0x%x]\n", count++, (int)e);
 
@@ -918,14 +901,12 @@ static void ipp_clean_queue_buf(struct drm_device 
*drm_dev,
 {
struct drm_exynos_ipp_mem_node *m_node, *tm_node;
 
-   if (!list_empty(&c_node->mem_list[qbuf->ops_id])) {
-   /* delete list */
-   list_for_each_entry_safe(m_node, tm_node,
-   &c_node->mem_list[qbuf->ops_id], list) {
-   if (m_node->buf_id == qbuf->buf_id &&
-   m_node->ops_id == qbuf->ops_id)
-   ipp_put_mem_node(drm_dev, c_node, m_node);
-   }
+   /* delete list */
+   list_for_each_entry_safe(m_node, tm_node,
+   &c_node->mem_list[qbuf->ops_id], list) {
+   if (m_node->buf_id == qbuf->buf_id &&
+   m_node->ops_id == qbuf->ops_id)
+   ipp_put_mem_node(drm_dev, c_node, m_node);
}
 }
 
@@ -1361,11 +1342,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* source/destination memory list */
head = &c_node->mem_list[i];
 
-   if (list_empty(head)) {
-   DRM_DEBUG_KMS("mem_list is empty.\n");
-   break;
-   }
-
list_for_each_entry_safe(m_node, tm_node,
head, list) {
ret = ipp_put_mem_node(drm_dev, c_node,
@@ -1381,11 +1357,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* destination memory list */
head = &c_node->mem_list[EXYNOS_DRM_OPS_DST];
 
-   if (list_empty(head)) {
-   DRM_DEBUG_KMS("mem_list is empty.\n");
-   break;
-   }
-
list_for_each_entry_safe(m_node, tm_node, head, list) {
ret = ipp_put_mem_node(drm_dev, c_node, m_node);
if (ret) {
@@ -1398,11 +1369,6 @@ static int ipp_stop_property(struct drm_device *drm_dev,
/* source memory list */
head = &c_node->mem_list[EXYNOS_DRM_OPS_SRC];
 
-   if (list_empty(head)) {
-   DRM

[PATCH 0/9] drm/exynos/ipp: image post processing improvements, part deux

[Andrzej Hajda]

This is the next part of ipp improvement patches, this time made
by YoungJun Cho, I am posting them as he is on leave.

The patchset is based on drm-exynos/exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (1):
  drm/exynos: ipp: remove description of non-existing field

YoungJun Cho (8):
  drm/exynos: ipp: remove usless list_empty() functions
  drm/exynos: ipp: remove duplicated setting
  drm/exynos: ipp: rename cmd_lock to lock
  drm/exynos: ipp: add cmd_lock for cmd_list
  drm/exynos: ipp: add ipp_remove_id()
  drm/exynos: ipp: rearrange c_node->mem_lock using routines
  drm/exynos: ipp: rearrange c_node->event_lock using routine
  drm/exynos: ipp: update comment for struct drm_ipp_buf_info

 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 242 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |   9 +-
 2 files changed, 129 insertions(+), 122 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 5/9] drm/exynos: ipp: add ipp_remove_id()

[Andrzej Hajda]

From: YoungJun Cho 

This patch adds ipp_remove_id() for idr resource free.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 42 -
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b60ae54..f1c51b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -167,6 +167,13 @@ static int ipp_create_id(struct idr *id_idr, struct mutex 
*lock, void *obj,
return 0;
 }
 
+static void ipp_remove_id(struct idr *id_idr, struct mutex *lock, u32 id)
+{
+   mutex_lock(lock);
+   idr_remove(id_idr, id);
+   mutex_unlock(lock);
+}
+
 static void *ipp_find_obj(struct idr *id_idr, struct mutex *lock, u32 id)
 {
void *obj;
@@ -501,7 +508,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
c_node->start_work = ipp_create_cmd_work();
if (IS_ERR(c_node->start_work)) {
DRM_ERROR("failed to create start work.\n");
-   goto err_clear;
+   goto err_remove_id;
}
 
c_node->stop_work = ipp_create_cmd_work();
@@ -542,16 +549,22 @@ err_free_stop:
kfree(c_node->stop_work);
 err_free_start:
kfree(c_node->start_work);
+err_remove_id:
+   ipp_remove_id(&ctx->prop_idr, &ctx->prop_lock, property->prop_id);
 err_clear:
kfree(c_node);
return ret;
 }
 
-static void ipp_clean_cmd_node(struct drm_exynos_ipp_cmd_node *c_node)
+static void ipp_clean_cmd_node(struct ipp_context *ctx,
+   struct drm_exynos_ipp_cmd_node *c_node)
 {
/* delete list */
list_del(&c_node->list);
 
+   ipp_remove_id(&ctx->prop_idr, &ctx->prop_lock,
+   c_node->property.prop_id);
+
/* destroy mutex */
mutex_destroy(&c_node->lock);
mutex_destroy(&c_node->mem_lock);
@@ -1122,7 +1135,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,
c_node->state = IPP_STATE_STOP;
ippdrv->dedicated = false;
mutex_lock(&ippdrv->cmd_lock);
-   ipp_clean_cmd_node(c_node);
+   ipp_clean_cmd_node(ctx, c_node);
 
if (list_empty(&ippdrv->cmd_list))
pm_runtime_put_sync(ippdrv->dev);
@@ -1686,7 +1699,7 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
&ipp_id);
if (ret || ipp_id == 0) {
DRM_ERROR("failed to create id.\n");
-   goto err_idr;
+   goto err;
}
 
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]ipp_id[%d]\n",
@@ -1707,34 +1720,40 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ret = drm_iommu_attach_device(drm_dev, ippdrv->dev);
if (ret) {
DRM_ERROR("failed to activate iommu\n");
-   goto err_iommu;
+   goto err;
}
}
}
 
return 0;
 
-err_iommu:
+err:
/* get ipp driver entry */
-   list_for_each_entry_reverse(ippdrv, &exynos_drm_ippdrv_list, drv_list)
+   list_for_each_entry_continue_reverse(ippdrv, &exynos_drm_ippdrv_list,
+   drv_list) {
if (is_drm_iommu_supported(drm_dev))
drm_iommu_detach_device(drm_dev, ippdrv->dev);
 
-err_idr:
-   idr_destroy(&ctx->ipp_idr);
-   idr_destroy(&ctx->prop_idr);
+   ipp_remove_id(&ctx->ipp_idr, &ctx->ipp_lock,
+   ippdrv->prop_list.ipp_id);
+   }
+
return ret;
 }
 
 static void ipp_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
 {
struct exynos_drm_ippdrv *ippdrv;
+   struct ipp_context *ctx = get_ipp_context(dev);
 
/* get ipp driver entry */
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
if (is_drm_iommu_supported(drm_dev))
drm_iommu_detach_device(drm_dev, ippdrv->dev);
 
+   ipp_remove_id(&ctx->ipp_idr, &ctx->ipp_lock,
+   ippdrv->prop_list.ipp_id);
+
ippdrv->drm_dev = NULL;
exynos_drm_ippdrv_unregister(ippdrv);
}
@@ -1765,6 +1784,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev, 
struct device *dev,
struct drm_exynos_file_private *file_priv = file->driver_priv;
struct exynos_drm_ipp_private *priv = file_priv->ipp_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
+   struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp

[PATCH 4/9] drm/exynos: ipp: add cmd_lock for cmd_list

[Andrzej Hajda]

From: YoungJun Cho 

This patch adds cmd_lock for cmd_list synchronization.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 20 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  2 ++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 0d85433..b60ae54 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -284,9 +284,14 @@ static struct exynos_drm_ippdrv 
*ipp_find_drv_by_handle(u32 prop_id)
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]\n", count++, (int)ippdrv);
 
-   list_for_each_entry(c_node, &ippdrv->cmd_list, list)
-   if (c_node->property.prop_id == prop_id)
+   mutex_lock(&ippdrv->cmd_lock);
+   list_for_each_entry(c_node, &ippdrv->cmd_list, list) {
+   if (c_node->property.prop_id == prop_id) {
+   mutex_unlock(&ippdrv->cmd_lock);
return ippdrv;
+   }
+   }
+   mutex_unlock(&ippdrv->cmd_lock);
}
 
return ERR_PTR(-ENODEV);
@@ -318,6 +323,7 @@ int exynos_drm_ipp_get_property(struct drm_device *drm_dev, 
void *data,
if (!prop_list->ipp_id) {
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list)
count++;
+
/*
 * Supports ippdrv list count for user application.
 * First step user application getting ippdrv count.
@@ -379,9 +385,11 @@ static int ipp_find_and_set_property(struct 
drm_exynos_ipp_property *property)
 * when we find this command no using prop_id.
 * return property information set in this command node.
 */
+   mutex_lock(&ippdrv->cmd_lock);
list_for_each_entry(c_node, &ippdrv->cmd_list, list) {
if ((c_node->property.prop_id == prop_id) &&
(c_node->state == IPP_STATE_STOP)) {
+   mutex_unlock(&ippdrv->cmd_lock);
DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
property->cmd, (int)ippdrv);
 
@@ -389,6 +397,7 @@ static int ipp_find_and_set_property(struct 
drm_exynos_ipp_property *property)
return 0;
}
}
+   mutex_unlock(&ippdrv->cmd_lock);
 
DRM_ERROR("failed to search property.\n");
 
@@ -519,7 +528,9 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
 
INIT_LIST_HEAD(&c_node->event_list);
list_splice_init(&priv->event_list, &c_node->event_list);
+   mutex_lock(&ippdrv->cmd_lock);
list_add_tail(&c_node->list, &ippdrv->cmd_list);
+   mutex_unlock(&ippdrv->cmd_lock);
 
/* make dedicated state without m2m */
if (!ipp_is_m2m_cmd(property->cmd))
@@ -1110,10 +1121,12 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,
 
c_node->state = IPP_STATE_STOP;
ippdrv->dedicated = false;
+   mutex_lock(&ippdrv->cmd_lock);
ipp_clean_cmd_node(c_node);
 
if (list_empty(&ippdrv->cmd_list))
pm_runtime_put_sync(ippdrv->dev);
+   mutex_unlock(&ippdrv->cmd_lock);
break;
case IPP_CTRL_PAUSE:
cmd_work = c_node->stop_work;
@@ -1688,6 +1701,7 @@ static int ipp_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
ippdrv->event_workq = ctx->event_workq;
ippdrv->sched_event = ipp_sched_event;
INIT_LIST_HEAD(&ippdrv->cmd_list);
+   mutex_init(&ippdrv->cmd_lock);
 
if (is_drm_iommu_supported(drm_dev)) {
ret = drm_iommu_attach_device(drm_dev, ippdrv->dev);
@@ -1757,6 +1771,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev, 
struct device *dev,
DRM_DEBUG_KMS("for priv[0x%x]\n", (int)priv);
 
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
+   mutex_lock(&ippdrv->cmd_lock);
list_for_each_entry_safe(c_node, tc_node,
&ippdrv->cmd_list, list) {
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]\n",
@@ -1781,6 +1796,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev, 
struct device *dev,
pm_runtime_put_sync(ippdrv->dev);
}
}
+   mutex_unlock(&ippdrv->cmd_lock);
}
 
kfree(priv);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index fbb80ac..09cb5a2 100644
--- a/drivers/gpu/drm/exyn

[PATCH 6/9] drm/exynos: ipp: rearrange c_node->mem_lock using routines

[Andrzej Hajda]

From: YoungJun Cho 

The c_node->mem_list[] should be protected with
c_node->mem_lock.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 86 ++---
 1 file changed, 48 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index f1c51b4..4b5afd3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -584,8 +584,6 @@ static int ipp_check_mem_list(struct 
drm_exynos_ipp_cmd_node *c_node)
struct list_head *head;
int ret, i, count[EXYNOS_DRM_OPS_MAX] = { 0, };
 
-   mutex_lock(&c_node->mem_lock);
-
for_each_ipp_ops(i) {
/* source/destination memory list */
head = &c_node->mem_list[i];
@@ -614,8 +612,6 @@ static int ipp_check_mem_list(struct 
drm_exynos_ipp_cmd_node *c_node)
ret = max(count[EXYNOS_DRM_OPS_SRC],
count[EXYNOS_DRM_OPS_DST]);
 
-   mutex_unlock(&c_node->mem_lock);
-
return ret;
 }
 
@@ -658,16 +654,13 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
*ippdrv,
return -EFAULT;
}
 
-   mutex_lock(&c_node->mem_lock);
-
DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
 
/* get operations callback */
ops = ippdrv->ops[m_node->ops_id];
if (!ops) {
DRM_ERROR("not support ops.\n");
-   ret = -EFAULT;
-   goto err_unlock;
+   return -EFAULT;
}
 
/* set address and enable irq */
@@ -676,12 +669,10 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
*ippdrv,
m_node->buf_id, IPP_BUF_ENQUEUE);
if (ret) {
DRM_ERROR("failed to set addr.\n");
-   goto err_unlock;
+   return ret;
}
}
 
-err_unlock:
-   mutex_unlock(&c_node->mem_lock);
return ret;
 }
 
@@ -696,11 +687,9 @@ static struct drm_exynos_ipp_mem_node
void *addr;
int i;
 
-   mutex_lock(&c_node->mem_lock);
-
m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
if (!m_node)
-   goto err_unlock;
+   return ERR_PTR(-ENOMEM);
 
/* clear base address for error handling */
memset(&buf_info, 0x0, sizeof(buf_info));
@@ -734,15 +723,14 @@ static struct drm_exynos_ipp_mem_node
 
m_node->filp = file;
m_node->buf_info = buf_info;
+   mutex_lock(&c_node->mem_lock);
list_add_tail(&m_node->list, &c_node->mem_list[qbuf->ops_id]);
-
mutex_unlock(&c_node->mem_lock);
+
return m_node;
 
 err_clear:
kfree(m_node);
-err_unlock:
-   mutex_unlock(&c_node->mem_lock);
return ERR_PTR(-EFAULT);
 }
 
@@ -759,13 +747,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
return -EFAULT;
}
 
-   if (list_empty(&m_node->list)) {
-   DRM_ERROR("empty memory node.\n");
-   return -ENOMEM;
-   }
-
-   mutex_lock(&c_node->mem_lock);
-
DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
 
/* put gem buffer */
@@ -780,8 +761,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
list_del(&m_node->list);
kfree(m_node);
 
-   mutex_unlock(&c_node->mem_lock);
-
return 0;
 }
 
@@ -894,7 +873,9 @@ static int ipp_queue_buf_with_run(struct device *dev,
return 0;
}
 
+   mutex_lock(&c_node->mem_lock);
if (!ipp_check_mem_list(c_node)) {
+   mutex_unlock(&c_node->mem_lock);
DRM_DEBUG_KMS("empty memory.\n");
return 0;
}
@@ -911,10 +892,12 @@ static int ipp_queue_buf_with_run(struct device *dev,
} else {
ret = ipp_set_mem_node(ippdrv, c_node, m_node);
if (ret) {
+   mutex_unlock(&c_node->mem_lock);
DRM_ERROR("failed to set m node.\n");
return ret;
}
}
+   mutex_unlock(&c_node->mem_lock);
 
return 0;
 }
@@ -926,12 +909,14 @@ static void ipp_clean_queue_buf(struct drm_device 
*drm_dev,
struct drm_exynos_ipp_mem_node *m_node, *tm_node;
 
/* delete list */
+   mutex_lock(&c_node->mem_lock);
list_for_each_entry_safe(m_node, tm_node,
&c_node->mem_list[qbuf->ops_id], list) {
if (m_node->buf_id == qbuf->buf_id &&
m_node->ops_id == qbuf->ops_id)
ipp_put_mem_node(drm_dev, c_node, m_node);
}
+   mutex_unlock(&c_node->mem_lock);
 }
 
 int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data,
@@ -1267,9 +1252,11 @@ static int ipp_start_property(struct exynos_drm_ippdrv 
*ippdrv,
/* store comma

[PATCH 8/9] drm/exynos: ipp: update comment for struct drm_ipp_buf_info

[Andrzej Hajda]

From: YoungJun Cho 

The attribute gem_objs in struct drm_exynos_ipp_buf_info was
changed to handles. So the comment needs to be updated also.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 09cb5a2..e06c41e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -83,7 +83,7 @@ struct drm_exynos_ipp_cmd_node {
 /*
  * A structure of buffer information.
  *
- * @gem_objs: Y, Cb, Cr each gem object.
+ * @handles: Y, Cb, Cr each gem object handle.
  * @base: Y, Cb, Cr each planar address.
  */
 struct drm_exynos_ipp_buf_info {
-- 
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 7/9] drm/exynos: ipp: rearrange c_node->event_lock using routine

[Andrzej Hajda]

From: YoungJun Cho 

The c_node->event_list should be protected with
c_node->event_lock.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 4b5afd3..603a796 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -796,7 +796,9 @@ static int ipp_get_event(struct drm_device *drm_dev,
e->base.event = &e->event.base;
e->base.file_priv = file;
e->base.destroy = ipp_free_event;
+   mutex_lock(&c_node->event_lock);
list_add_tail(&e->base.link, &c_node->event_list);
+   mutex_unlock(&c_node->event_lock);
 
return 0;
 }
@@ -807,6 +809,7 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node 
*c_node,
struct drm_exynos_ipp_send_event *e, *te;
int count = 0;
 
+   mutex_lock(&c_node->event_lock);
list_for_each_entry_safe(e, te, &c_node->event_list, base.link) {
DRM_DEBUG_KMS("count[%d]e[0x%x]\n", count++, (int)e);
 
@@ -827,9 +830,13 @@ static void ipp_put_event(struct drm_exynos_ipp_cmd_node 
*c_node,
/* delete list */
list_del(&e->base.link);
kfree(e);
-   return;
+   goto out_unlock;
}
}
+
+out_unlock:
+   mutex_unlock(&c_node->event_lock);
+   return;
 }
 
 static void ipp_handle_cmd_work(struct device *dev,
@@ -1515,9 +1522,11 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,
return -EINVAL;
}
 
+   mutex_lock(&c_node->event_lock);
if (list_empty(&c_node->event_list)) {
DRM_DEBUG_KMS("event list is empty.\n");
-   return 0;
+   ret = 0;
+   goto err_event_unlock;
}
 
mutex_lock(&c_node->mem_lock);
@@ -1609,11 +1618,6 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,
e = list_first_entry(&c_node->event_list,
struct drm_exynos_ipp_send_event, base.link);
 
-   if (!e) {
-   DRM_ERROR("empty event.\n");
-   return -EINVAL;
-   }
-
do_gettimeofday(&now);
DRM_DEBUG_KMS("tv_sec[%ld]tv_usec[%ld]\n", now.tv_sec, now.tv_usec);
e->event.tv_sec = now.tv_sec;
@@ -1628,6 +1632,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,
list_move_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
+   mutex_unlock(&c_node->event_lock);
 
DRM_DEBUG_KMS("done cmd[%d]prop_id[%d]buf_id[%d]\n",
property->cmd, property->prop_id, tbuf_id[EXYNOS_DRM_OPS_DST]);
@@ -1636,6 +1641,8 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
*ippdrv,
 
 err_mem_unlock:
mutex_unlock(&c_node->mem_lock);
+err_event_unlock:
+   mutex_unlock(&c_node->event_lock);
return ret;
 }
 
@@ -1678,8 +1685,6 @@ void ipp_sched_event(struct work_struct *work)
goto err_completion;
}
 
-   mutex_lock(&c_node->event_lock);
-
ret = ipp_send_event(ippdrv, c_node, event_work->buf_id);
if (ret) {
DRM_ERROR("failed to send event.\n");
@@ -1689,8 +1694,6 @@ void ipp_sched_event(struct work_struct *work)
 err_completion:
if (ipp_is_m2m_cmd(c_node->property.cmd))
complete(&c_node->start_complete);
-
-   mutex_unlock(&c_node->event_lock);
 }
 
 static int ipp_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
-- 
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 9/9] drm/exynos: ipp: remove description of non-existing field

[Andrzej Hajda]

ipp_id field is removed from exynos_drm_ippdrv struct.
The patch removes its description as well.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index e06c41e..7aaeaae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -142,7 +142,6 @@ struct exynos_drm_ipp_ops {
  * @parent_dev: parent device information.
  * @dev: platform device.
  * @drm_dev: drm device.
- * @ipp_id: id of ipp driver.
  * @dedicated: dedicated ipp device.
  * @ops: source, destination operations.
  * @event_workq: event work queue.
-- 
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/9] drm/exynos: ipp: remove duplicated setting

[Andrzej Hajda]

From: YoungJun Cho 

This patch removes duplicated setting.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c8cfa24..0968777 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1090,12 +1090,12 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,
case IPP_CTRL_PLAY:
if (pm_runtime_suspended(ippdrv->dev))
pm_runtime_get_sync(ippdrv->dev);
+
c_node->state = IPP_STATE_START;
 
cmd_work = c_node->start_work;
cmd_work->ctrl = cmd_ctrl->ctrl;
ipp_handle_cmd_work(dev, ippdrv, cmd_work, c_node);
-   c_node->state = IPP_STATE_START;
break;
case IPP_CTRL_STOP:
cmd_work = c_node->stop_work;
-- 
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 3/9] drm/exynos: ipp: rename cmd_lock to lock

[Andrzej Hajda]

From: YoungJun Cho 

The ippdrv->cmd_list requires cmd_lock.
So renames cmd_lock to lock for context.

Signed-off-by: YoungJun Cho 
Acked-by: Seong-Woo Kim 
Acked-by: Kyungmin Park 
Tested-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 0968777..0d85433 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -507,7 +507,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
goto err_free_stop;
}
 
-   mutex_init(&c_node->cmd_lock);
+   mutex_init(&c_node->lock);
mutex_init(&c_node->mem_lock);
mutex_init(&c_node->event_lock);
 
@@ -542,7 +542,7 @@ static void ipp_clean_cmd_node(struct 
drm_exynos_ipp_cmd_node *c_node)
list_del(&c_node->list);
 
/* destroy mutex */
-   mutex_destroy(&c_node->cmd_lock);
+   mutex_destroy(&c_node->lock);
mutex_destroy(&c_node->mem_lock);
mutex_destroy(&c_node->event_lock);
 
@@ -979,7 +979,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
}
break;
case IPP_BUF_DEQUEUE:
-   mutex_lock(&c_node->cmd_lock);
+   mutex_lock(&c_node->lock);
 
/* put event for destination buffer */
if (qbuf->ops_id == EXYNOS_DRM_OPS_DST)
@@ -987,7 +987,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
 
ipp_clean_queue_buf(drm_dev, c_node, qbuf);
 
-   mutex_unlock(&c_node->cmd_lock);
+   mutex_unlock(&c_node->lock);
break;
default:
DRM_ERROR("invalid buffer control.\n");
@@ -1412,7 +1412,7 @@ void ipp_sched_cmd(struct work_struct *work)
return;
}
 
-   mutex_lock(&c_node->cmd_lock);
+   mutex_lock(&c_node->lock);
 
property = &c_node->property;
 
@@ -1460,7 +1460,7 @@ void ipp_sched_cmd(struct work_struct *work)
DRM_DEBUG_KMS("ctrl[%d] done.\n", cmd_work->ctrl);
 
 err_unlock:
-   mutex_unlock(&c_node->cmd_lock);
+   mutex_unlock(&c_node->lock);
 }
 
 static int ipp_send_event(struct exynos_drm_ippdrv *ippdrv,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index eea4db3..fbb80ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -52,7 +52,7 @@ struct drm_exynos_ipp_cmd_work {
  * @list: list head to command queue information.
  * @event_list: list head of event.
  * @mem_list: list head to source,destination memory queue information.
- * @cmd_lock: lock for synchronization of access to ioctl.
+ * @lock: lock for synchronization of access to ioctl.
  * @mem_lock: lock for synchronization of access to memory nodes.
  * @event_lock: lock for synchronization of access to scheduled event.
  * @start_complete: completion of start of command.
@@ -68,7 +68,7 @@ struct drm_exynos_ipp_cmd_node {
struct list_headlist;
struct list_headevent_list;
struct list_headmem_list[EXYNOS_DRM_OPS_MAX];
-   struct mutexcmd_lock;
+   struct mutexlock;
struct mutexmem_lock;
struct mutexevent_lock;
struct completion   start_complete;
-- 
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: [RFC PATCH 00/11][V2] kexec: A new system call to allow in kernel loading

[Borislav Petkov]

Hi Vivek,

On Mon, Jan 27, 2014 at 01:57:40PM -0500, Vivek Goyal wrote:
> Hi
> 
> This is V2 of new system call patches. Previous version was posted here.

just a quick ping here, are you working on a v3? Anything I can help with?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 05/11] ARM: topology: use new cpu_power interface

[Vincent Guittot]

On 25 May 2014 15:22, Preeti U Murthy  wrote:
> Hi Vincent,
>
> Why do we have two interfaces arch_scale_freq_power() and
> arch_scale_cpu_power()? Does it make sense to consolidate them now ?
Hi Preeti,

They don't have the same purpose. arch_scale_cpu_power set the max
capacity of your CPU whereas arch_scale_freq_power can be used to give
the current capacity. ARM platform were using arch_scale_freq_power
because it was the only one available for non SMT system but this
induces some misunderstanding and some limitation in the
characterization of a CPUs. This consolidation is a necessary step so
we can now have the max capacity of a CPU and let
arch_scale_freq_power for other purpose (or even remove it if
useless).

Regards,
Vincent

>
> Regards
> Preeti U Murthy
>
>
> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
>> Use the new arch_scale_cpu_power in order to reflect the original capacity of
>> a CPU instead of arch_scale_freq_power which is more linked to a scaling of
>> the capacity linked to the frequency.
>>
>> Signed-off-by: Vincent Guittot 
>> ---
>>  arch/arm/kernel/topology.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
>> index 71e1fec..6cc25a8 100644
>> --- a/arch/arm/kernel/topology.c
>> +++ b/arch/arm/kernel/topology.c
>> @@ -42,7 +42,7 @@
>>   */
>>  static DEFINE_PER_CPU(unsigned long, cpu_scale);
>>
>> -unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu)
>> +unsigned long arch_scale_cpu_power(struct sched_domain *sd, int cpu)
>>  {
>>   return per_cpu(cpu_scale, cpu);
>>  }
>> @@ -166,7 +166,7 @@ static void update_cpu_power(unsigned int cpu)
>>   set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
>>
>>   printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
>> - cpu, arch_scale_freq_power(NULL, cpu));
>> + cpu, arch_scale_cpu_power(NULL, cpu));
>>  }
>>
>>  #else
>>
>
--
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] regulator: s2mpa01: Use correct register for buck1 ramp delay

[Krzysztof Kozlowski]

Fix the register for ramp delay of buck1 regulator. Buck1 and buck6
share the field (offset 4) in ramp delay register S2MPA01_REG_RAMP2.

The driver used the same register and field for ramp delay of buck3 and
buck1. This lead to updating of ramp delay of buck3 when setting buck1
and actually the ramp delay of buck1 was never set.

Cc: 
Fixes: f18792714608 ("regulator: Add support for S2MPA01 regulator")
Signed-off-by: Krzysztof Kozlowski 
---
Changes since v1:
1. Adjust the patch to match datasheet of S2MPA01.
---
 drivers/regulator/s2mpa01.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index f19a30f0fb42..a52cb1cec576 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -116,7 +116,6 @@ static int s2mpa01_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
ramp_delay = s2mpa01->ramp_delay16;
 
ramp_shift = S2MPA01_BUCK16_RAMP_SHIFT;
-   ramp_reg = S2MPA01_REG_RAMP1;
break;
case S2MPA01_BUCK2:
enable_shift = S2MPA01_BUCK2_RAMP_EN_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 2/2] ASoC: max98095: Add master clock handling

[Tushar Behera]

If master clock is provided through device tree, then update
the master clock frequency during set_sysclk.

Documentation has been updated to reflect the change.

Signed-off-by: Tushar Behera 
---
 .../devicetree/bindings/sound/max98095.txt |6 +
 sound/soc/codecs/max98095.c|   24 
 2 files changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/max98095.txt 
b/Documentation/devicetree/bindings/sound/max98095.txt
index bacbeaa..318a4c8 100644
--- a/Documentation/devicetree/bindings/sound/max98095.txt
+++ b/Documentation/devicetree/bindings/sound/max98095.txt
@@ -8,6 +8,12 @@ Required properties:
 
 - reg : The I2C address of the device.
 
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be "mclk"
+
 Example:
 
 max98095: codec@11 {
diff --git a/sound/soc/codecs/max98095.c b/sound/soc/codecs/max98095.c
index d6c1e4c..89ec004 100644
--- a/sound/soc/codecs/max98095.c
+++ b/sound/soc/codecs/max98095.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,6 +43,7 @@ struct max98095_priv {
struct regmap *regmap;
enum max98095_type devtype;
struct max98095_pdata *pdata;
+   struct clk *mclk;
unsigned int sysclk;
struct max98095_cdata dai[3];
const char **eq_texts;
@@ -1395,6 +1397,11 @@ static int max98095_dai_set_sysclk(struct snd_soc_dai 
*dai,
if (freq == max98095->sysclk)
return 0;
 
+   if (!IS_ERR(max98095->mclk)) {
+   freq = clk_round_rate(max98095->mclk, freq);
+   clk_set_rate(max98095->mclk, freq);
+   }
+
/* Setup clocks for slave mode, and using the PLL
 * PSCLK = 0x01 (when master clk is 10MHz to 20MHz)
 * 0x02 (when master clk is 20MHz to 40MHz)..
@@ -1634,6 +1641,19 @@ static int max98095_set_bias_level(struct snd_soc_codec 
*codec,
break;
 
case SND_SOC_BIAS_PREPARE:
+   /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+   if (!IS_ERR(max98095->mclk)) {
+   if (codec->dapm.bias_level == SND_SOC_BIAS_ON)
+   clk_disable_unprepare(max98095->mclk);
+   else
+   clk_prepare_enable(max98095->mclk);
+   }
break;
 
case SND_SOC_BIAS_STANDBY:
@@ -2238,6 +2258,10 @@ static int max98095_probe(struct snd_soc_codec *codec)
struct i2c_client *client;
int ret = 0;
 
+   max98095->mclk = devm_clk_get(codec->dev, "mclk");
+   if (PTR_ERR(max98095->mclk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
/* reset the codec, the DSP core, and disable all interrupts */
max98095_reset(codec);
 
-- 
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/

[PATCH V2 0/2] ASoC: max98090/max98095: Add master clock handing

[Tushar Behera]

These CODECs are used on Snow/Peach-pit boards and the master clock
needs to be set at 24MHz.

Adding support in respective codec drivers so that we can update the
master clock frequency from sound card driver through set_sysclk.

Changes for V2:
1. Added PROBE_DEFER if clock driver has not yet been probed
2. Moved clk_prepare_enable from .probe to .set_bias_level
3. Moved clk_disable_unprepare from .remove to .set_bias_level

Tushar Behera (2):
  ASoC: max98090: Add master clock handling
  ASoC: max98095: Add master clock handling

 .../devicetree/bindings/sound/max98090.txt |6 +
 .../devicetree/bindings/sound/max98095.txt |6 +
 sound/soc/codecs/max98090.c|   23 +++
 sound/soc/codecs/max98090.h|1 +
 sound/soc/codecs/max98095.c|   24 
 5 files changed, 60 insertions(+)

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

[PATCH V2 1/2] ASoC: max98090: Add master clock handling

[Tushar Behera]

If master clock is provided through device tree, then update
the master clock frequency during set_sysclk.

Documentation has been updated to reflect the change.

Signed-off-by: Tushar Behera 
---
 .../devicetree/bindings/sound/max98090.txt |6 +
 sound/soc/codecs/max98090.c|   23 
 sound/soc/codecs/max98090.h|1 +
 3 files changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/max98090.txt 
b/Documentation/devicetree/bindings/sound/max98090.txt
index e4c8b36..a5e63fa 100644
--- a/Documentation/devicetree/bindings/sound/max98090.txt
+++ b/Documentation/devicetree/bindings/sound/max98090.txt
@@ -10,6 +10,12 @@ Required properties:
 
 - interrupts : The CODEC's interrupt output.
 
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be "mclk"
+
 Pins on the device (for linking into audio routes):
 
   * MIC1
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 9b76f5a..9275785 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1800,6 +1801,19 @@ static int max98090_set_bias_level(struct snd_soc_codec 
*codec,
break;
 
case SND_SOC_BIAS_PREPARE:
+   /*
+* SND_SOC_BIAS_PREPARE is called while preparing for a
+* transition to ON or away from ON. If current bias_level
+* is SND_SOC_BIAS_ON, then it is preparing for a transition
+* away from ON. Disable the clock in that case, otherwise
+* enable it.
+*/
+   if (!IS_ERR(max98090->mclk)) {
+   if (codec->dapm.bias_level == SND_SOC_BIAS_ON)
+   clk_disable_unprepare(max98090->mclk);
+   else
+   clk_prepare_enable(max98090->mclk);
+   }
break;
 
case SND_SOC_BIAS_STANDBY:
@@ -1929,6 +1943,11 @@ static int max98090_dai_set_sysclk(struct snd_soc_dai 
*dai,
if (freq == max98090->sysclk)
return 0;
 
+   if (!IS_ERR(max98090->mclk)) {
+   freq = clk_round_rate(max98090->mclk, freq);
+   clk_set_rate(max98090->mclk, freq);
+   }
+
/* Setup clocks for slave mode, and using the PLL
 * PSCLK = 0x01 (when master clk is 10MHz to 20MHz)
 *   0x02 (when master clk is 20MHz to 40MHz)..
@@ -2213,6 +2232,10 @@ static int max98090_probe(struct snd_soc_codec *codec)
 
dev_dbg(codec->dev, "max98090_probe\n");
 
+   max98090->mclk = devm_clk_get(codec->dev, "mclk");
+   if (PTR_ERR(max98090->mclk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
max98090->codec = codec;
 
/* Reset the codec, the DSP core, and disable all interrupts */
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h
index 5a3c8d0..cf1b606 100644
--- a/sound/soc/codecs/max98090.h
+++ b/sound/soc/codecs/max98090.h
@@ -1524,6 +1524,7 @@ struct max98090_priv {
struct snd_soc_codec *codec;
enum max98090_type devtype;
struct max98090_pdata *pdata;
+   struct clk *mclk;
unsigned int sysclk;
unsigned int bclk;
unsigned int lrclk;
-- 
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 v4] i2c: add driver for Rockchip RK3xxx SoC I2C adapter

[Heiko Stübner]

Hi,

Am Montag, 19. Mai 2014, 11:32:55 schrieb Max Schwarz:
> Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
> 
> Configuration is only possible through devicetree. The driver is
> interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
> 
> Signed-off-by: Max Schwarz 

As I just saw it, the previous Ack, was sent to the wrong patch, and was 
actually meant for v4, so here it is again:

Acked-by: Heiko Stuebner 


Thanks
Heiko

> ---
> 
> The driver cannot be used without a proper clock driver
> supporting rate calculation, such as Heiko Stübner's RK3xxx clock
> driver series [1].
> 
> Changes since v3:
>   - fixed style issues found by Maxime Ripard
>   - use dt alias id to calculate the bit offset in GRF,
> as suggested by Maxime Ripard
>   - also use dt alias id for i2c_add_numbered_adapter()
> 
> Changes since v2:
>   - support for the new GRF syscon mapping by Heiko Stübner
>   - probe error handling improvements by Heiko Stübner
>   - fixed wrong remove() order found by Heiko Stübner
>   - removed unnecessary clk_enable() during probe
>   - removed switch back to old interface during remove
> 
> Changes since v1:
>   - dt property names "rockchip,*" suggested by Heiko Stübner
>   - fixed overly specific RK3188 comment (Heiko Stübner)
> 
> The dts files needed for testing on Radxa Rock are in my tree at
> 
> https://github.com/xqms/linux.git topic/i2c-rk3x-clean-v4
> 
> [1]: http://www.spinics.net/lists/arm-kernel/msg329102.html
> 
>  Documentation/devicetree/bindings/i2c/i2c-rk3x.txt |  42 ++
>  drivers/i2c/busses/Kconfig |  10 +
>  drivers/i2c/busses/Makefile|   1 +
>  drivers/i2c/busses/i2c-rk3x.c  | 742
> + 4 files changed, 795 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
>  create mode 100644 drivers/i2c/busses/i2c-rk3x.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
> b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt new file mode 100644
> index 000..dde6c22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
> @@ -0,0 +1,42 @@
> +* Rockchip RK3xxx I2C controller
> +
> +This driver interfaces with the native I2C controller present in Rockchip
> +RK3xxx SoCs.
> +
> +Required properties :
> +
> + - reg : Offset and length of the register set for the device
> + - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or
> + "rockchip,rk3288-i2c".
> + - interrupts : interrupt number
> + - clocks : parent clock
> +
> +Required on RK3066, RK3188 :
> +
> + - rockchip,grf : the phandle of the syscon node for the general register
> +   file (GRF)
> + - on those SoCs an alias with the correct I2C bus ID (bit offset in the
> GRF) +   is also required.
> +
> +Optional properties :
> +
> + - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is
> used. +
> +Example:
> +
> +aliases {
> + i2c0 = &i2c0;
> +}
> +
> +i2c0: i2c@2002d000 {
> + compatible = "rockchip,rk3188-i2c";
> + reg = <0x2002d000 0x1000>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + rockchip,grf = <&grf>;
> +
> + clock-names = "i2c";
> + clocks = <&cru PCLK_I2C0>;
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index c94db1c..f973632 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -663,6 +663,16 @@ config I2C_PXA_SLAVE
> is necessary for systems where the PXA may be a target on the
> I2C bus.
> 
> +config I2C_RK3X
> + tristate "Rockchip RK3xxx I2C adapter"
> + depends on OF
> + help
> +   Say Y here to include support for the I2C adapter in Rockchip RK3xxx
> +   SoCs.
> +
> +   This driver can also be built as a module. If so, the module will
> +   be called i2c-rk3x.
> +
>  config I2C_QUP
>   tristate "Qualcomm QUP based I2C controller"
>   depends on ARCH_QCOM
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 18d18ff..39b6851 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -65,6 +65,7 @@ obj-$(CONFIG_I2C_PNX)   += i2c-pnx.o
>  obj-$(CONFIG_I2C_PUV3)   += i2c-puv3.o
>  obj-$(CONFIG_I2C_PXA)+= i2c-pxa.o
>  obj-$(CONFIG_I2C_PXA_PCI)+= i2c-pxa-pci.o
> +obj-$(CONFIG_I2C_RK3X)   += i2c-rk3x.o
>  obj-$(CONFIG_I2C_QUP)+= i2c-qup.o
>  obj-$(CONFIG_I2C_RIIC)   += i2c-riic.o
>  obj-$(CONFIG_I2C_S3C2410)+= i2c-s3c2410.o
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> new file mode 100644
> index 000..429983b
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -0,0 +1,742 @@
> +/*
> + * Driver for I2C adapter in Rockchip RK3xxx SoC
> + *
> + * Max Schwarz 
> + * based on the patches by Rockchip Inc.
> + *
> + * This pro

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

[Srivatsa S. Bhat]

On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> On some systems the platform doesn't support neither
> PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> only available system sleep state.  However, some user space frameworks
> only use the "mem" and (sometimes) "standby" sleep state labels, so
> the users of those systems need to modify user space in order to be
> able to use system suspend at all and that is not always possible.
>

So, is this going to be a temporary solution until all the user-space
frameworks have been fixed? I certainly hope so, because this clearly looks
like a bug (or a lack of feature) in user-space to me... in the sense that
those user-space frameworks don't have support for (i.e., don't know how to
deal with) freeze-only systems yet.

The more elegant long term solution would have been to teach the kernel to
export *truly* relative names such as SUSPEND_DEEP, SUSPEND_SHALLOW,
and SUSPEND_LIGHT or something like that (of course, we can debate on what
naming would suit best).

But this patch continues to keep the names 'SUSPEND_MEM' ("mem") etc., which
still implies that we are doing Suspend-to-RAM, because the name itself betrays
that info. So IMHO it doesn't really match what the command-line-switch
'relative_sleep_states' says.

But I understand that this is a quick hack to make existing user-space work
with systems that support only the freeze state. However, for the reasons
mentioned above, I hope that this is a temporary solution and we can remove
or enhance this once all those user-space frameworks have been fixed.

Regards,
Srivatsa S. Bhat
 
> For this reason, add a new kernel command line argument,
> relative_sleep_states, allowing the users of those systems to change
> the way in which the kernel assigns labels to system sleep states.
> Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
> labels will enumerate the available system sleem states from the
> deepest to the shallowest, respectively, so that "mem" is always
> present in /sys/power/state and the other state strings may or may
> not be presend depending on what is supported by the platform.
> 
> Update system sleep states documentation to reflect this change.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> This update is needed after patch [2/3] has been updated.
> 
> Thanks!
> 
> ---
>  Documentation/ABI/testing/sysfs-power |   29 +++
>  Documentation/kernel-parameters.txt   |7 ++
>  Documentation/power/states.txt|   89 
> +-
>  kernel/power/main.c   |   12 ++--
>  kernel/power/suspend.c|   33 +++-
>  5 files changed, 120 insertions(+), 50 deletions(-)
> 
> Index: linux-pm/kernel/power/suspend.c
> ===
> --- linux-pm.orig/kernel/power/suspend.c
> +++ linux-pm/kernel/power/suspend.c
> @@ -86,19 +86,46 @@ static bool valid_state(suspend_state_t
>   return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
>  }
> 
> +/*
> + * If this is set, the "mem" label always corresponds to the deepest sleep 
> state
> + * available, the "standby" label corresponds to the second deepest sleep 
> state
> + * available (if any), and the "freeze" label corresponds to the remaining
> + * available sleep state (if there is one).
> + */
> +static bool relative_states;
> +
> +static int __init sleep_states_setup(char *str)
> +{
> + relative_states = !strncmp(str, "1", 1);
> + if (relative_states) {
> + pm_states[PM_SUSPEND_MEM].state = PM_SUSPEND_FREEZE;
> + pm_states[PM_SUSPEND_FREEZE].state = 0;
> + }
> + return 1;
> +}
> +
> +__setup("relative_sleep_states=", sleep_states_setup);
> +
>  /**
>   * suspend_set_ops - Set the global suspend method table.
>   * @ops: Suspend operations to use.
>   */
>  void suspend_set_ops(const struct platform_suspend_ops *ops)
>  {
> - suspend_state_t i;
> + suspend_state_t i, j = PM_SUSPEND_MAX - 1;
> 
>   lock_system_sleep();
> 
>   suspend_ops = ops;
> - for (i = PM_SUSPEND_STANDBY; i <= PM_SUSPEND_MEM; i++)
> - pm_states[i].state = valid_state(i) ? i : 0;
> + for (i = PM_SUSPEND_MEM; i >= PM_SUSPEND_STANDBY; i--)
> + if (valid_state(i))
> + pm_states[j--].state = i;
> + else if (!relative_states)
> + pm_states[j--].state = 0;
> +
> + pm_states[j--].state = PM_SUSPEND_FREEZE;
> + while (j >= PM_SUSPEND_MIN)
> + pm_states[j--].state = 0;
> 
>   unlock_system_sleep();
>  }
> Index: linux-pm/Documentation/kernel-parameters.txt
> ===
> --- linux-pm.orig/Documentation/kernel-parameters.txt
> +++ linux-pm/Documentation/kernel-parameters.txt
> @@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes
>   [KNL, SM

Re: [RFT PATCH] regulator: s2mpa01: Use correct register for buck[36] ramp delay

[Krzysztof Kozlowski]

On pon, 2014-05-26 at 13:37 +0530, Sachin Kamat wrote:
> Hi Krzysztof
> 
> Apologies for the delay. I was on vacation during the early part of
> this month and
> got busy with some other stuff later and this mail fell through the cracks.
> 
> 
> On 23 May 2014 19:49, Krzysztof Kozlowski  wrote:
> > Hi Sachin,
> >
> > The s2mpa01 regulator driver uses wrong registers for ramp delay (buck1
> > and buck3 in RAMP1, buck6 in RAMP2) but I am not sure which layout is
> > proper (it seems that that buck1 should be in RAMP2 register).
> >
> > Could you check in S2MPA01 datasheet the registers for ramp delay for
> > buck1, buck3 and buck6?
> 
> I checked the datasheet available with me and according to it
> 
> buck 1 and 6 share the ramp register 0x11 (RAMP2) (bit 4 and 5) and buck 3 
> uses
> bit 4 and 5 of register 0x10 (RAMP1).

Thanks! I'll send updated version of the patchset.

Best regards,
Krzysztof

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

color box, display box, corrugated box, color card, blister card, color sleeve, hang tag, label

[Jinghao Printing - CHINA]

Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.

I will send you the website then.

Best regards,
David Wu
--
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] HID: Debug: Add labels for HID Sensor Usages

[Jiri Kosina]

On Sat, 24 May 2014, Jonathan Cameron wrote:

> This looks reasonable to me, but I haven't checked every entry.  Also 
> Reyad, you need to sign off on the patch if you expect anyone to pick it 
> up.
> 
> Jiri, this is one for you. (note Jiri should probably have been cc'd in the
> first place as the HID maintainer - unless he specifically asked not to be).

I definitely want (and need) to be CCed on such patches, thanks for 
letting me know, Jonathan.

Reyad, please add you signoff as Jonathan said, and resend the patch 
properly to me.

-- 
Jiri Kosina
SUSE Labs
--
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] regulator: ltc3589: Add DT binding documentation

[Philipp Zabel]

This patch adds the device tree binding documentation for Linear
Technology LTC3589, LTC3589-1, and LTC3589-2 8-port regulators.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Changed vendor prefix to lltc
---
 .../devicetree/bindings/regulator/ltc3589.txt  | 99 ++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/ltc3589.txt

diff --git a/Documentation/devicetree/bindings/regulator/ltc3589.txt 
b/Documentation/devicetree/bindings/regulator/ltc3589.txt
new file mode 100644
index 000..8010530
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3589.txt
@@ -0,0 +1,99 @@
+Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-output regulators
+
+Required properties:
+- compatible: "lltc,ltc3589", "lltc,ltc3589-1" or "lltc,ltc3589-2"
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains eight regulator child nodes sw1, sw2, sw3, bb-out,
+  ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as
+  documented in Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for sw1, sw2, sw3, bb-out, ldo1, and ldo2 additionally need to specify
+the resistor values of their external feedback voltage dividers:
+
+Required properties (not on ldo3, ldo4):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+  values R1 and R2 of the feedback voltage divider in ohms.
+
+Regulators sw1, sw2, sw3, and ldo2 can regulate the feedback reference from
+0.3625 V to 0.75 V in 12.5 mV steps. The output voltage thus ranges between
+0.3625 * (1 + R1/R2) V and 0.75 * (1 + R1/R2) V. Regulators bb-out and ldo1
+have a fixed 0.8 V reference and thus output 0.8 * (1 + R1/R2) V. The ldo3
+regulator is fixed to 1.8 V on LTC3589 and to 2.8 V on LTC3589-1,2. The ldo4
+regulator can output between 1.8 V and 3.3 V on LTC3589 and between 1.2 V
+and 3.2 V on LTC3589-1,2 in four steps. The ldo1 standby regulator can not
+be disabled and thus should have the regulator-always-on property set.
+
+Example:
+
+   ltc3589: pmic@34 {
+   compatible = "lltc,ltc3589-1";
+   reg = <0x34>;
+
+   regulators {
+   sw1_reg: sw1 {
+   regulator-min-microvolt = <591930>;
+   regulator-max-microvolt = <1224671>;
+   lltc,fb-voltage-divider = <10 158000>;
+   regulator-ramp-delay = <7000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw2_reg: sw2 {
+   regulator-min-microvolt = <704123>;
+   regulator-max-microvolt = <1456803>;
+   lltc,fb-voltage-divider = <18 191000>;
+   regulator-ramp-delay = <7000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3_reg: sw3 {
+   regulator-min-microvolt = <1341250>;
+   regulator-max-microvolt = <2775000>;
+   lltc,fb-voltage-divider = <27 10>;
+   regulator-ramp-delay = <7000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   bb_out_reg: bb-out {
+   regulator-min-microvolt = <3387341>;
+   regulator-max-microvolt = <3387341>;
+   lltc,fb-voltage-divider = <511000 158000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-min-microvolt = <1306329>;
+   regulator-max-microvolt = <1306329>;
+   lltc,fb-voltage-divider = <10 158000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo2_reg: ldo2 {
+   regulator-min-microvolt = <704123>;
+   regulator-max-microvolt = <1456806>;
+   lltc,fb-voltage-divider = <18 191000>;
+   regulator-ramp-delay = <7000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo3_reg: ldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-mic

[PATCH v2 3/3] regulator: Add LTC3589 support

[Philipp Zabel]

This patch adds support for the Linear Technology LTC3589, LTC3589-1,
and LTC3589-2 8-output I2C voltage regulator ICs.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Changed vendor prefix to lltc
 - Lucas added a .ramp_delay initial value for the ramping regulators
---
 drivers/regulator/Kconfig   |   6 +
 drivers/regulator/Makefile  |   1 +
 drivers/regulator/ltc3589.c | 565 
 3 files changed, 572 insertions(+)
 create mode 100644 drivers/regulator/ltc3589.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 903eb37..5599a61 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -265,6 +265,12 @@ config REGULATOR_LP8788
help
  This driver supports LP8788 voltage regulator chip.
 
+config REGULATOR_LTC3589
+   bool "LTC3589 8-output voltage regulator"
+   help
+ This enables support for the LTC3589, LTC3589-1, and LTC3589-2
+ 8-output regulators controlled via I2C.
+
 config REGULATOR_MAX14577
tristate "Maxim 14577 regulator"
depends on MFD_MAX14577
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 12ef277..16d429b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
 obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
 obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
 obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
+obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
 obj-$(CONFIG_REGULATOR_MAX14577) += max14577.o
 obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
 obj-$(CONFIG_REGULATOR_MAX8649)+= max8649.o
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
new file mode 100644
index 000..fef64ee
--- /dev/null
+++ b/drivers/regulator/ltc3589.c
@@ -0,0 +1,565 @@
+/*
+ * Linear Technology LTC3589,LTC3589-1 regulator support
+ *
+ * Copyright (c) 2014 Philipp Zabel , Pengutronix
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"ltc3589"
+
+#define LTC3589_IRQSTAT0x02
+#define LTC3589_SCR1   0x07
+#define LTC3589_OVEN   0x10
+#define LTC3589_SCR2   0x12
+#define LTC3589_PGSTAT 0x13
+#define LTC3589_VCCR   0x20
+#define LTC3589_CLIRQ  0x21
+#define LTC3589_B1DTV1 0x23
+#define LTC3589_B1DTV2 0x24
+#define LTC3589_VRRCR  0x25
+#define LTC3589_B2DTV1 0x26
+#define LTC3589_B2DTV2 0x27
+#define LTC3589_B3DTV1 0x29
+#define LTC3589_B3DTV2 0x2a
+#define LTC3589_L2DTV1 0x32
+#define LTC3589_L2DTV2 0x33
+
+#define LTC3589_IRQSTAT_PGOOD_TIMEOUT  BIT(3)
+#define LTC3589_IRQSTAT_UNDERVOLT_WARN BIT(4)
+#define LTC3589_IRQSTAT_UNDERVOLT_FAULTBIT(5)
+#define LTC3589_IRQSTAT_THERMAL_WARN   BIT(6)
+#define LTC3589_IRQSTAT_THERMAL_FAULT  BIT(7)
+
+#define LTC3589_OVEN_SW1   BIT(0)
+#define LTC3589_OVEN_SW2   BIT(1)
+#define LTC3589_OVEN_SW3   BIT(2)
+#define LTC3589_OVEN_BB_OUTBIT(3)
+#define LTC3589_OVEN_LDO2  BIT(4)
+#define LTC3589_OVEN_LDO3  BIT(5)
+#define LTC3589_OVEN_LDO4  BIT(6)
+#define LTC3589_OVEN_SW_CTRL   BIT(7)
+
+#define LTC3589_VCCR_SW1_GOBIT(0)
+#define LTC3589_VCCR_SW2_GOBIT(2)
+#define LTC3589_VCCR_SW3_GOBIT(4)
+#define LTC3589_VCCR_LDO2_GO   BIT(6)
+
+enum ltc3589_variant {
+   LTC3589,
+   LTC3589_1,
+   LTC3589_2,
+};
+
+enum ltc3589_reg {
+   LTC3589_SW1,
+   LTC3589_SW2,
+   LTC3589_SW3,
+   LTC3589_BB_OUT,
+   LTC3589_LDO1,
+   LTC3589_LDO2,
+   LTC3589_LDO3,
+   LTC3589_LDO4,
+   LTC3589_NUM_REGULATORS,
+};
+
+struct ltc3589_regulator {
+   struct regulator_desc desc;
+
+   /* External feedback voltage divider */
+   unsigned int r1;
+   unsigned int r2;
+};
+
+struct ltc3589 {
+   struct regmap *regmap;
+   struct device *dev;
+   enum ltc3589_variant variant;
+   struct ltc3589_regulator regulator_descs[LTC3589_NUM_REGULATORS];
+   struct regulator_dev *regulators[LTC3589_NUM_REGULATORS];
+};
+
+static const int ltc3589_ldo4[] = {
+   280, 250, 180, 330,
+};
+
+static const int ltc3589_12_ldo4[] = {
+   120, 18

Re: [PATCH 1/3] mmc: host: add slot argument to mmc_of_parse

[Jaehoon Chung]

Hi,

On 05/26/2014 05:09 PM, Ludovic Desroches wrote:
> On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
>> From: Ludovic Desroches 
>>
>> Some hosts manage several slots. In these case information such as the
>> bus width, chi detect and others are into the slot node. So we have to
> 
> /s/chi detect/chip detect
Will fix.

Tushar have suggested the rename mmc_of_parse_slot() instead of 
__mmc_of_parse().
I'm not sure which name is better. How about?

If never mind, i will change to mmc_of_parse_slot(), then send patch-v2.

Best Regards,
Jaehoon Chung
> 
>> parse child node. If not NULL, slot node will be used instead of the
>> device node.
>>
>> Signed-off-by: Ludovic Desroches 
>> Signed-off-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/core/host.c  |   13 +
>>  include/linux/mmc/host.h |   10 +-
>>  2 files changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
>> index 95cceae..0f677b3 100644
>> --- a/drivers/mmc/core/host.c
>> +++ b/drivers/mmc/core/host.c
>> @@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct 
>> mmc_host *host)
>>  #endif
>>  
>>  /**
>> - *  mmc_of_parse() - parse host's device-tree node
>> + *  __mmc_of_parse() - parse host's device-tree node
>>   *  @host: host whose node should be parsed.
>> + *  @slot : some device provide several slots so the node to parse
>> + *  is not the host one.
>>   *
>>   * To keep the rest of the MMC subsystem unaware of whether DT has been
>>   * used to to instantiate and configure this host instance or not, we
>>   * parse the properties and set respective generic mmc-host flags and
>>   * parameters.
>>   */
>> -int mmc_of_parse(struct mmc_host *host)
>> +int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
>>  {
>>  struct device_node *np;
>>  u32 bus_width;
>> @@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
>>  if (!host->parent || !host->parent->of_node)
>>  return 0;
>>  
>> -np = host->parent->of_node;
>> +if (slot)
>> +np = slot;
>> +else
>> +np = host->parent->of_node;
>>  
>>  /* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
>>  if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
>> @@ -459,7 +464,7 @@ out:
>>  return ret;
>>  }
>>  
>> -EXPORT_SYMBOL(mmc_of_parse);
>> +EXPORT_SYMBOL(__mmc_of_parse);
>>  
>>  /**
>>   *  mmc_alloc_host - initialise the per-host structure.
>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
>> index 7960424..c62af91 100644
>> --- a/include/linux/mmc/host.h
>> +++ b/include/linux/mmc/host.h
>> @@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct 
>> device *);
>>  int mmc_add_host(struct mmc_host *);
>>  void mmc_remove_host(struct mmc_host *);
>>  void mmc_free_host(struct mmc_host *);
>> -int mmc_of_parse(struct mmc_host *host);
>> +int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
>> +/*
>> + * mmc_of_parse - parse host's device-tree node
>> + *  @host: host whose node should be parsed.
>> + */
>> +static inline int mmc_of_parse(struct mmc_host *host)
>> +{
>> +return __mmc_of_parse(host, NULL);
>> +}
>>  
>>  static inline void *mmc_priv(struct mmc_host *host)
>>  {
>> -- 
>> 1.7.9.5
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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/

[PATCH v2 1/3] of: Add vendor prefix for Linear Technology Corporation

[Philipp Zabel]

Add Linear Technology Corporation to the list of device tree vendor prefixes.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Changed vendor prefix to lltc
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0f01c9b..98e739f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -65,6 +65,7 @@ lantiqLantiq Semiconductor
 lg LG Corporation
 linux  Linux-specific binding
 lsiLSI Corp. (LSI Logic)
+lltc   Linear Technology Corporation
 marvellMarvell Technology Group Ltd.
 maxim  Maxim Integrated Products
 microchip  Microchip Technology Inc.
-- 
2.0.0.rc2

--
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] export efi.flags to sysfs

[Dave Young]

For efi=old_map and any old_map quirks like SGI UV in current
tree kexec/kdump will fail because it depends on the new 1:1 mapping.

Thus export the mapping method to sysfs so kexec tools can switch
to original way to boot.

Since we have efi.flags for all efi facilities so let's just export the
efi.flags itself, it maybe useful for other arches and use cases.

Signed-off-by: Dave Young 
---
 drivers/firmware/efi/efi.c |3 +++
 1 file changed, 3 insertions(+)

Index: linux-2.6/drivers/firmware/efi/efi.c
===
--- linux-2.6.orig/drivers/firmware/efi/efi.c
+++ linux-2.6/drivers/firmware/efi/efi.c
@@ -86,16 +86,19 @@ static ssize_t name##_show(struct kobjec
 EFI_ATTR_SHOW(fw_vendor);
 EFI_ATTR_SHOW(runtime);
 EFI_ATTR_SHOW(config_table);
+EFI_ATTR_SHOW(flags);
 
 static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
 static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
 static struct kobj_attribute efi_attr_config_table = __ATTR_RO(config_table);
+static struct kobj_attribute efi_attr_flags = __ATTR_RO(flags);
 
 static struct attribute *efi_subsys_attrs[] = {
&efi_attr_systab.attr,
&efi_attr_fw_vendor.attr,
&efi_attr_runtime.attr,
&efi_attr_config_table.attr,
+   &efi_attr_flags.attr,
NULL,
 };
 
--
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] regulator: s2mpa01: Use correct register for buck1 ramp delay

[Sachin Kamat]

On 26 May 2014 13:56, Krzysztof Kozlowski  wrote:
> Fix the register for ramp delay of buck1 regulator. Buck1 and buck6
> share the field (offset 4) in ramp delay register S2MPA01_REG_RAMP2.
>
> The driver used the same register and field for ramp delay of buck3 and
> buck1. This lead to updating of ramp delay of buck3 when setting buck1
> and actually the ramp delay of buck1 was never set.
>
> Cc: 
> Fixes: f18792714608 ("regulator: Add support for S2MPA01 regulator")
> Signed-off-by: Krzysztof Kozlowski 

Reviewed-by: Sachin Kamat 

-- 
With warm regards,
Sachin
--
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/3] mmc: host: add slot argument to mmc_of_parse

[Ulf Hansson]

On 26 May 2014 10:38, Jaehoon Chung  wrote:
> Hi,
>
> On 05/26/2014 05:09 PM, Ludovic Desroches wrote:
>> On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
>>> From: Ludovic Desroches 
>>>
>>> Some hosts manage several slots. In these case information such as the
>>> bus width, chi detect and others are into the slot node. So we have to
>>
>> /s/chi detect/chip detect
> Will fix.
>
> Tushar have suggested the rename mmc_of_parse_slot() instead of 
> __mmc_of_parse().
> I'm not sure which name is better. How about?
>
> If never mind, i will change to mmc_of_parse_slot(), then send patch-v2.

I would prefer to keep it as is, but just because that's my taste. :-)

Kind regards
Ulf Hansson
--
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 1/6] usb: musb: core: Handle Babble condition only in HOST mode

[George Cherian]

On 5/23/2014 2:12 AM, Bin Liu wrote:

Hi George,

On Mon, May 19, 2014 at 11:32 PM, George Cherian  wrote:

Hi Bin,

On 5/19/2014 9:24 PM, Bin Liu wrote:

Hi,

On Mon, May 19, 2014 at 8:39 AM, George Cherian 
wrote:

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.

Signed-off-by: George Cherian 
---
   drivers/usb/musb/musb_core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..eff3c5c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -849,7 +849,7 @@ b_host:
  }

  /* handle babble condition */
-   if (int_usb & MUSB_INTR_BABBLE)
+   if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
  schedule_work(&musb->recover_work);

I guess my following comments are for Daniel's patch as while which
initially added the babble work.

Should this if statement be merged into the previous 'if(int_usb &
MUSB_INTR_RESET)' one, which handles the same interrupt and already
handles host and device mode respectively.


Initially I too had the babble handling as part of  'if(int_usb &
MUSB_INTR_RESET)'
one. But during my tests I hit a corner case where in we hit a BABBLE
condition
on disconnect. In such case the babble interrupt can be handled only if we
have a seperate
check, else its considered as a BUS RESET.

When all devices are disconnected  MUSB_DEVCTL_HM = 0 and the code always
enter the
else path. In this path it treats the BABBLE as a BUS RESET.

The code flow is a bit confusing, two if() handle the same interrupt.
The second one implied using 'handled = IRQ_HANDLED;' from the first
one.
Also does the switch() in else{} in the first if() cause any side effect?

No it doesn't.

Since this babble handing is AM335x specific, how about handle it in
dsps_interrupt() in musb_dsps.c, which already has an entry for babble
interrupt? TI 3.2 kernel does this way.
That the reason we have platform specific callbacks added  from the main 
interrupt handler.

Regards,
-Bin.




Regards,
-Bin.


   #if 0
--
1.8.3.1

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



--
-George




--
-George

--
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: [RFC 03/16] kgr: initial code

[Jiri Kosina]

On Tue, 20 May 2014, Jiri Slaby wrote:

> Yes, this is a problem I was thinking of in another context yesterday.
> Patching ->read or any other file_openrations which hold state over
> user<->kernel switches may be a potential threat like above. The same as
> in other implementations of live patching IMO. I put that on a TODO
> checklist for creating patches. This has to be investigated manually
> when creating a patch.

Another thing that has to be handled very carefully is patching functions 
which are using self-modifying code (static keys), to make sure that the 
logic is not switched in the new function.

-- 
Jiri Kosina
SUSE Labs
--
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] ARM: mvebu: rename ARM_ERRATA_753970

[Paul Bolle]

ARM_ERRATA_753970 was renamed to PL310_ERRATA_753970 in v3.2, through
commit fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for
PL310 errata workarounds"). Two selects were added in v3.15-rc1 that
still use the previous name. Rename these.

Make these statements depend on CACHE_PL310, like all other selects of
PL310_ERRATA_753970. That way it will only be selected if its dependency
is met.

Signed-off-by: Paul Bolle 
---
I reported this before v3.15-rc1. I don't know whether any fixes are
pending. None are in linux-next. And ignoring an errata were one
apparently could be needed sounds, well, scary. Perhaps it is not.
Anyhow, to make sure this gets fixed, hopefully before v3.15, I'm
submitting this (untested!) patch.

A related observation. There are three PL310 errata options: one depends
on CACHE_PL310, three depend on CACHE_L2X0. The one depending on
CACHE_PL310 is selected only if CACHE_PL310 is set.

But the three depending on CACHE_L2X0 are selected a few times if
CACHE_L2X0 is set, in other cases if CACHE_PL310 is set, and in some
cases always. There may be good reasons for this, but it looks odd. I
know nothing about the PL310 cache and its erratas, so I haven't looked
into this any further.

 arch/arm/mach-mvebu/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 3f73eecbcfb0..501d0f42e7b2 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -35,7 +35,7 @@ config MACH_ARMADA_370
 config MACH_ARMADA_375
bool "Marvell Armada 375 boards" if ARCH_MULTI_V7
select ARM_ERRATA_720789
-   select ARM_ERRATA_753970
+   select PL310_ERRATA_753970 if CACHE_PL310
select ARM_GIC
select ARMADA_375_CLK
select CPU_V7
@@ -48,7 +48,7 @@ config MACH_ARMADA_375
 config MACH_ARMADA_38X
bool "Marvell Armada 380/385 boards" if ARCH_MULTI_V7
select ARM_ERRATA_720789
-   select ARM_ERRATA_753970
+   select PL310_ERRATA_753970 if CACHE_PL310
select ARM_GIC
select ARMADA_38X_CLK
select CPU_V7
-- 
1.9.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: [RFC 1/2] cfg80211: Add channel flags limiting availability to OCB mode only

[Rostislav Lisovy]

On Mon, 2014-05-19 at 16:51 +0200, Johannes Berg wrote:
> This patch is fine, but insufficient - you should also do something
> with
> the new flags?

That's definitely a good point. I think the biggest issue is that the
flags can't be checked only with the knowledge of the 'wiphy' but they
are related to the 'vif' type -- this prohibits checking in the
cfg80211_chandef_usable() (I assume).

Would the following be sufficient?

--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -801,6 +801,10 @@ static int __ieee80211_vif_change_channel(struct 
ieee80211_sub_if_data *sdata,
*changed |= BSS_CHANGED_BANDWIDTH;
}
 
+   if (sdata->vif.type == NL80211_IFTYPE_OCB &&
+   !(chandef->chan->flags & IEEE80211_CHAN_OCB_ONLY))
+   return -EINVAL;
+
sdata->vif.bss_conf.chandef = *chandef;
ctx->conf.def = *chandef;
 
@@ -1049,6 +1053,12 @@ int ieee80211_vif_change_bandwidth(struct 
ieee80211_sub_if_data *sdata,
goto out;
}
 
+   if (sdata->vif.type == NL80211_IFTYPE_OCB &&
+   !(chandef->chan->flags & IEEE80211_CHAN_OCB_ONLY)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
if (chandef->width == NL80211_CHAN_WIDTH_20_NOHT ||
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT) {
ret = -EINVAL;

--
Best regards;
Rostislav Lisovy


--
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/1] bus: vexpress-config: Export devm_regmap_init_vexpress_config

[Sachin Kamat]

Export this symbol to avoid build error when built as module.
ERROR: "devm_regmap_init_vexpress_config" [drivers/regulator/vexpress.ko] 
undefined!

Signed-off-by: Sachin Kamat 
---
 drivers/bus/vexpress-config.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c
index 27a07dfcd626..2af2227874af 100644
--- a/drivers/bus/vexpress-config.c
+++ b/drivers/bus/vexpress-config.c
@@ -118,6 +118,7 @@ struct regmap *devm_regmap_init_vexpress_config(struct 
device *dev)
 
return regmap;
 }
+EXPORT_SYMBOL(devm_regmap_init_vexpress_config);
 
 
 struct device *vexpress_config_bridge_register(struct device *parent,
-- 
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 v3 03/13] mmc: mmci: Add Qualcomm Id to amba id table

[Ulf Hansson]

Hi Srinivas,

>
> +static struct variant_data variant_qcom = {
> +   .fifosize   = 16 * 4,
> +   .fifohalfsize   = 8 * 4,
> +   .clkreg = MCI_CLK_ENABLE,
> +   .datalength_bits= 24,
> +   .blksz_datactrl4= true,

You get compile error here.

Kind regards
Ulf Hansson
--
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/3] mmc: host: add slot argument to mmc_of_parse

[Jaehoon Chung]

Hi, Ulf.

On 05/26/2014 05:44 PM, Ulf Hansson wrote:
> On 26 May 2014 10:38, Jaehoon Chung  wrote:
>> Hi,
>>
>> On 05/26/2014 05:09 PM, Ludovic Desroches wrote:
>>> On Fri, May 23, 2014 at 07:25:19PM +0900, Jaehoon Chung wrote:
 From: Ludovic Desroches 

 Some hosts manage several slots. In these case information such as the
 bus width, chi detect and others are into the slot node. So we have to
>>>
>>> /s/chi detect/chip detect
>> Will fix.
>>
>> Tushar have suggested the rename mmc_of_parse_slot() instead of 
>> __mmc_of_parse().
>> I'm not sure which name is better. How about?
>>
>> If never mind, i will change to mmc_of_parse_slot(), then send patch-v2.
> 
> I would prefer to keep it as is, but just because that's my taste. :-)
Ok. I think so.
I want to merge this patch-set for fixing the dw-mmc problem, before release 
the 3.16.

dw-mmc controller also used the slot concept, so some property didn't parse 
with mmc_of_parse().

Best Regards,
Jaehoon Chung
 
> 
> Kind regards
> Ulf Hansson
> 

--
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: [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device

[Seth Forshee]

On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> One question about this patch.
> 
> Why don't you use the devices cgroup check if the root user in that namespace 
> is allowed to use this device?
> 
> This way you can be sure that the root in that namespace can not access 
> devices to which the host system did not gave
> him access to.

That might be possible, but I don't want to require something on the
host to whitelist the device for the container. Then loop would need to
automatically add the device to devices.allow, which doesn't seem
desirable to me. But I'm not entirely opposed to the idea if others
think this is a better way to go.

Seth

--
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 01/11] sched: fix imbalance flag reset

[Preeti U Murthy]

On 05/26/2014 01:19 PM, Vincent Guittot wrote:
> On 25 May 2014 12:33, Preeti U Murthy  wrote:
>> Hi Vincent,
>>
>> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
>>> The imbalance flag can stay set whereas there is no imbalance.
>>>
>>> Let assume that we have 3 tasks that run on a dual cores /dual cluster 
>>> system.
>>> We will have some idle load balance which are triggered during tick.
>>> Unfortunately, the tick is also used to queue background work so we can 
>>> reach
>>> the situation where short work has been queued on a CPU which already runs a
>>> task. The load balance will detect this imbalance (2 tasks on 1 CPU and an 
>>> idle
>>> CPU) and will try to pull the waiting task on the idle CPU. The waiting 
>>> task is
>>> a worker thread that is pinned on a CPU so an imbalance due to pinned task 
>>> is
>>> detected and the imbalance flag is set.
>>> Then, we will not be able to clear the flag because we have at most 1 task 
>>> on
>>> each CPU but the imbalance flag will trig to useless active load balance
>>> between the idle CPU and the busy CPU.
>>
>> Why do we do active balancing today when there is at-most 1 task on the
>> busiest cpu? Shouldn't we be skipping load balancing altogether? If we
>> do active balancing when the number of tasks = 1, it will lead to a ping
>> pong right?
> 
> That's the purpose of the patch to prevent this useless active load
> balance. When the imbalance flag is set, an active load balance is
> triggered whatever the load balance is because of pinned tasks that
> prevents a balance state.

No I mean this:

sched:Do not continue load balancing when the busiest cpu has one
running task

From: Preeti U Murthy 


---
 kernel/sched/fair.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c9617b7..b175333 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6626,6 +6626,8 @@ more_balance:
}
goto out_balanced;
}
+   } else {
+   goto out;
}

if (!ld_moved) {


}

Regards
Preeti U Murthy
> 
> Vincent
> 
>>
>> Regards
>> Preeti U Murthy
>>
> 

--
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 v6 3/5] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()

[George Cherian]

For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_dsps.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue->wrp;
 
dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-   udelay(100);
+   usleep_range(100, 200);
+   usb_phy_shutdown(musb->xceiv);
+   usleep_range(100, 200);
+   usb_phy_init(musb->xceiv);
+
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
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/

Atualize a sua conta Unicamp Webmail

[Unicamp E-mail do Administrador]

Caros assinantes v?lidos Unicamp,

Esta mensagem ? a partir da Unicamp Administrador E-mail Servi?o de TI
para todos nossos subscribers.You conta de e-mail s?o fornecer-nos a
seguir informa??es para revalidar sua conta devido a spam e atualiza??o
Unicamp a vers?o de spam New m?s.

Aviso: A sua conta Email Unicamp ser? expirado depois de uma semana, se
voc? n?o revalidar ou Unicamp datam sua conta. Por favor, co-operar com
conosco para que possamos atend?-lo melhor, em contato com o
administrador! 

Nome de usu?rio:
Senha:
Confirme sua senha:
E-mail alternativo:

Obrigado.
Unicamp E-mail do Administrador


--
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 v6 2/5] usb: musb: core: Convert babble recover work to delayed work

[George Cherian]

During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.

To acheive this schedule a delayed work for babble recovery.

While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 15 ---
 drivers/usb/musb/musb_core.h |  2 +-
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0ad9551..c0ce09f 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
 
/* handle babble condition */
if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
-   schedule_work(&musb->recover_work);
+   schedule_delayed_work(&musb->recover_work,
+ msecs_to_jiffies(100));
 
 #if 0
 /* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1751,16 +1752,16 @@ static void musb_irq_work(struct work_struct *data)
 /* Recover from babble interrupt conditions */
 static void musb_recover_work(struct work_struct *data)
 {
-   struct musb *musb = container_of(data, struct musb, recover_work);
+   struct musb *musb = container_of(data, struct musb, recover_work.work);
int status;
 
musb_platform_reset(musb);
 
usb_phy_vbus_off(musb->xceiv);
-   udelay(100);
+   usleep_range(100, 200);
 
usb_phy_vbus_on(musb->xceiv);
-   udelay(100);
+   usleep_range(100, 200);
 
/*
 * When a babble condition occurs, the musb controller removes the
@@ -1943,7 +1944,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 
/* Init IRQ workqueue before request_irq */
INIT_WORK(&musb->irq_work, musb_irq_work);
-   INIT_WORK(&musb->recover_work, musb_recover_work);
+   INIT_DELAYED_WORK(&musb->recover_work, musb_recover_work);
INIT_DELAYED_WORK(&musb->deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(&musb->finish_resume_work, musb_host_finish_resume);
 
@@ -2039,7 +2040,7 @@ fail4:
 
 fail3:
cancel_work_sync(&musb->irq_work);
-   cancel_work_sync(&musb->recover_work);
+   cancel_delayed_work_sync(&musb->recover_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
if (musb->dma_controller)
@@ -2105,7 +2106,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb->dma_controller);
 
cancel_work_sync(&musb->irq_work);
-   cancel_work_sync(&musb->recover_work);
+   cancel_delayed_work_sync(&musb->recover_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index d155a15..9241025 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
-   struct work_struct  recover_work;
+   struct delayed_work recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
-- 
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 v6 0/5] Add support for SW babble Control

[George Cherian]

Series add support for SW babble control logic found in 
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.

Patch 1 -> Handle Babble only if MUSB is in HOST mode
Patch 2 -> Convert recover work to delayed work.
Patch 3 -> usb_phy_vbus_(off/_on) are NOPs for am335x PHY
   so use usb_phy(_shutdown/_init) in musb_platform_reset()
Patch 4 -> Add return value for musb_platform_reset() in prepration
   to support SW babble_ctrl
Patch 5 -> Add and Enable sw babble control for newer silicon

v5 -> v6 : Squash patch 5 and 6 form v5 to avoid build warnings.

v4 -> v5 : Added a debug print before resetting MUSB.
   changed a musb_readb to dsps_readb introduced in Patch#5 of v4.

v3 -> v4 : Fixes an issue in gagdet mode - BUS RESET should not
   be handled as a BABBLE. Added a check for the same.(Patch #1)
   Enable sw babble control properly (Patch #6)

v2 -> v3 : Modify musb_platform_reset() to return zero on success.



George Cherian (5):
  usb: musb: core: Handle Babble condition only in HOST mode
  usb: musb: core: Convert babble recover work to delayed work
  usb: musb: dsps: Call usb_phy(_shutdown/_init) during
musb_platform_reset()
  usb: musb: core: Convert the musb_platform_reset to have a return
value.
  usb: musb: dsps: Add the sw_babble_control() and Enable for newer
silicon

 drivers/usb/musb/musb_core.c | 27 --
 drivers/usb/musb/musb_core.h | 12 +++---
 drivers/usb/musb/musb_dsps.c | 88 ++--
 drivers/usb/musb/musb_regs.h |  7 
 4 files changed, 114 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/

Re: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM

[Lucas Stach]

Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström:
> On 23.05.2014 17:40, Alex Courbot wrote:
> > On 05/23/2014 06:59 PM, Lucas Stach wrote:
> > So after checking with more knowledgeable people, it turns out this is 
> > the expected behavior on ARM and BAR regions should be mapped uncached 
> > on GK20A. All the more reasons to avoid using the BAR at all.
> 
> This is actually specific to Tegra.
> 
> >> You may want to make yourself aware of all the quirks required for
> >> sharing memory between the GPU and CPU on an ARM host. I think there are
> >> far more involved than what you see now and writing an replacement for
> >> TTM will not be an easy task.
> >>
> >> Doing away with the concept of two memory areas will not get you to a
> >> single unified address space. You would have to deal with things like
> >> not being able to change the caching state of pages in the systems
> >> lowmem yourself. You will still have to deal with remapping pages that
> >> aren't currently visible to the CPU (ok this is not an issue on Jetson
> >> right now as it only has 2GB of RAM), because it's in systems highmem,
> >> or even in a different LPAE area.
> >>
> >> You really want to be sure you are aware of all the consequences of
> >> this, before considering this task.
> > 
> > Yep, that's why I am seeking advice here. My first hope is that with a 
> > few tweaks we will be able to keep using TTM and the current nouveau_bo 
> > implementation. But unless I missed something this is not going to be easy.
> > 
> > We can also use something like the patch I originally sent to make it 
> > work, although not with good performance, on GK20A. Not very graceful, 
> > but it will allow applications to run.
> > 
> > In the long run though, we will want to achieve better performance, and 
> > it seems like a BO implementation targeted at UMA devices would also be 
> > beneficial to quite a few desktop GPUs. So as tricky as it may be I'm 
> > interested in gathering thoughts and why not giving it a first try with 
> > GK20A, even if it imposes some limitations like having buffers in lowmem 
> > in a first time (we can probably live with this one for a short while, 
> > and 64 bits will also be coming to the rescue :))
> 
> I don't think lowmem or LPAE is any problem, if the memory manager is
> designed with that in mind. Vast majority of the buffers kernel
> allocates do not need to be touched in kernel space.
> 
> Actually I can't think of any buffers that we allocate on behalf of user
> space that would need to be permanently mapped also to kernel. In case
> or relocs only push buffer needs to be temporarily mapped to kernel.
> 
> Ultimately even relocs are not necessary if we expose GPU virtual
> addresses directly to user space. But that's another topic.
> 
Nouveau already exposes constant virtual addresses to userspace and
skips the pushbuf patching when the presumed offset from userspace is
the same as what the kernel thinks it should be.

The problem with lowmem on ARM is that you can't unmap those pages from
the kernel cached mapping. So if you alloc a page, give it to userspace
and userspace decides to map the page WC you just produced a conflicting
mapping, which may yield undefined results on ARMv7. You may think this
is not a problem as you are not touching the kernel cached mapping, but
in fact it is. The CPUs prefetcher can still access this mapping.

Although it won't wander over a page boundary for automatic prefetching
it may still do this when explicitly instructed to do so by code, which
may happen for example if your page happens to be near a kernel list,
where the list traversal code includes explicit prefetch instructions.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 v6 5/5] usb: musb: dsps: Add the sw_babble_control() and Enable for newer silicon

[George Cherian]

Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.

Babble control register logic is implemented in the latest
revision of AM335x.

Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_dsps.c | 89 +---
 drivers/usb/musb/musb_regs.h |  7 
 2 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..01543a9 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+   bool sw_babble_enabled;
 
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val &= ~(1 << wrp->otg_disable);
dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);
 
+   /*
+*  Check whether the dsps version has babble control enabled.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+   val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   if (val == MUSB_BABBLE_RCV_DISABLE) {
+   glue->sw_babble_enabled = true;
+   val |= MUSB_BABBLE_SW_SESSION_CTRL;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+   }
+
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
return ret;
@@ -536,19 +550,82 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
 }
 
+static bool  sw_babble_control(struct musb *musb)
+{
+   u8 babble_ctl;
+   bool session_restart =  false;
+
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   dev_dbg(musb->controller, "babble: MUSB_BABBLE_CTL value %x\n",
+   babble_ctl);
+   /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+   dev_dbg(musb->controller, "STUCK_J is %s\n",
+   babble_ctl & MUSB_BABBLE_STUCK_J ? "set" : "reset");
+
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+   int timeout = 10;
+
+   /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+   /* wait till line monitor flag cleared */
+   dev_dbg(musb->controller, "Set TXIDLE, wait J to clear\n");
+   do {
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   udelay(1);
+   } while ((babble_ctl & MUSB_BABBLE_STUCK_J) && timeout--);
+
+   /* check whether stuck_at_j bit cleared */
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+   /*
+* real babble condition has occurred
+* restart the controller to start the
+* session again
+*/
+   dev_dbg(musb->controller, "J not cleared, misc (%x)\n",
+   babble_ctl);
+   session_restart = true;
+   }
+   } else {
+   session_restart = true;
+   }
+
+   return session_restart;
+}
+
 static int dsps_musb_reset(struct musb *musb)
 {
struct device *dev = musb->controller;
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
+   int session_restart = 0;
 
-   dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-   usleep_range(100, 200);
-   usb_phy_shutdown(musb->xceiv);
-   usleep_range(100, 200);
-   usb_phy_init(musb->xceiv);
+   if (glue->sw_babble_enabled)
+   session_restart = sw_babble_control(musb);
+   /*
+* In case of new silicon version babble condition can be recovered
+* without resetting the MUSB. But for older silicon versions, MUSB
+* reset is needed
+*/
+   if (session_restart || !glue->sw_babble_enabled) {
+   dev_info(musb->controller, "Restarting MUSB to recover from 
Babble\n");
+   dsps_writel(musb->ctrl_base, wrp->control

[PATCH v6 4/5] usb: musb: core: Convert the musb_platform_reset to have a return value.

[George Cherian]

Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the  musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for  musb_platform_reset().

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 10 ++
 drivers/usb/musb/musb_core.h | 10 ++
 drivers/usb/musb/musb_dsps.c |  3 ++-
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c0ce09f..b841ee0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1753,9 +1753,11 @@ static void musb_irq_work(struct work_struct *data)
 static void musb_recover_work(struct work_struct *data)
 {
struct musb *musb = container_of(data, struct musb, recover_work.work);
-   int status;
+   int status, ret;
 
-   musb_platform_reset(musb);
+   ret  = musb_platform_reset(musb);
+   if (ret)
+   return;
 
usb_phy_vbus_off(musb->xceiv);
usleep_range(100, 200);
@@ -1764,8 +1766,8 @@ static void musb_recover_work(struct work_struct *data)
usleep_range(100, 200);
 
/*
-* When a babble condition occurs, the musb controller removes the
-* session bit and the endpoint config is lost.
+* When a babble condition occurs, the musb controller
+* removes the session bit and the endpoint config is lost.
 */
if (musb->dyn_fifo)
status = ep_config_from_table(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 9241025..414e57a 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
 
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
-   void(*reset)(struct musb *musb);
+   int (*reset)(struct musb *musb);
 
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -555,10 +555,12 @@ static inline void musb_platform_try_idle(struct musb 
*musb,
musb->ops->try_idle(musb, timeout);
 }
 
-static inline void musb_platform_reset(struct musb *musb)
+static inline int  musb_platform_reset(struct musb *musb)
 {
-   if (musb->ops->reset)
-   musb->ops->reset(musb);
+   if (!musb->ops->reset)
+   return -EINVAL;
+
+   return musb->ops->reset(musb);
 }
 
 static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..f6f3087 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
 }
 
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
 {
struct device *dev = musb->controller;
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb->xceiv);
 
+   return 0;
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
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 v2 2/2] of: Stop naming platform_device using dcr address

[Grant Likely]

On Sat, May 24, 2014 at 5:10 AM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2014-05-23 at 08:36 +0900, Grant Likely wrote:
>> There is now a way to ensure all platform devices get a unique name when
>> populated from the device tree, and the DCR_NATIVE code path is broken
>> anyway. PowerPC Cell (PS3) is the only platform that actually uses this
>> path.  Most likely nobody will notice if it is killed. Remove the code
>> and associated ugly #ifdef.
>>
>> The user-visible impact of this patch is that any DCR device on Cell
>> will get a new name in the /sys/devices hierarchy.
>
> I don't understand. First DCR devices cover more than Cell (and not even
> PS3). All 4xx embedded have some form of DCR based devices so I don't
> know how much we use as "platform".
>
> What do you mean by "the DCR_NATIVE" code path is broken anyway ?

Take a look at the function. In the PPC_DCR_NATIVE path, the device
name is set using format "d%x.%s", but the function doesn't return.
Instead, it falls through to the end of the function that sets the
device name again using "%s.%d", so the first name never sticks.

The last time that code was touched was in 2010 by me when I moved it
out of arch/powerpc (94c0931983ee9, "of: Merge of_device_alloc() and
of_device_make_bus_id()"). It was already broken then. As far as I can
tell, it was broken as far back as 7eebde70, "[POWERPC] Souped-up
of_platform_device support" from 2006 which is when the code was
added. Did it ever work?

The only thing that selects the other option, PPC_DCR_MMIO is Cell in
arch/powerpc/platforms/cell/Kconfig. Every other DCR device is
PPC_DCR_NATIVE, all of which are broken.

> Changing user visible platform device names has broken stuff in the
> past, I'm not saying it is now but I'd like a better justification
> for removing this.

The whole purpose of this function was to create unique names. The
previous patch solves that, so I'm not convinced that this extra code
path is still warranted. Given that nobody has complained about
PPC_DCR_NATIVE seeming never has worked, that path should be just
dropped outright since fixing it would be an user visible change
itself!

If you are really bothered about removing it on Cell, then I'll put it
back in. I just don't think it is worth it.

g.

>
> Cheers,
> Ben.
>
>
>> Signed-off-by: Grant Likely 
>> Cc: Rob Herring 
>> Cc: Benjamin Herrenschmidt 
>> ---
>>  arch/powerpc/include/asm/dcr-mmio.h |  4 
>>  arch/powerpc/sysdev/dcr.c   |  6 +++---
>>  drivers/of/platform.c   | 24 
>>  3 files changed, 3 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/dcr-mmio.h 
>> b/arch/powerpc/include/asm/dcr-mmio.h
>> index acd491dbd45a..93a68b28e695 100644
>> --- a/arch/powerpc/include/asm/dcr-mmio.h
>> +++ b/arch/powerpc/include/asm/dcr-mmio.h
>> @@ -51,10 +51,6 @@ static inline void dcr_write_mmio(dcr_host_mmio_t host,
>>   out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
>>  }
>>
>> -extern u64 of_translate_dcr_address(struct device_node *dev,
>> - unsigned int dcr_n,
>> - unsigned int *stride);
>> -
>>  #endif /* __KERNEL__ */
>>  #endif /* _ASM_POWERPC_DCR_MMIO_H */
>>
>> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
>> index 1bd0eba4d355..e9056e438575 100644
>> --- a/arch/powerpc/sysdev/dcr.c
>> +++ b/arch/powerpc/sysdev/dcr.c
>> @@ -152,9 +152,9 @@ EXPORT_SYMBOL_GPL(dcr_resource_len);
>>
>>  #ifdef CONFIG_PPC_DCR_MMIO
>>
>> -u64 of_translate_dcr_address(struct device_node *dev,
>> -  unsigned int dcr_n,
>> -  unsigned int *out_stride)
>> +static u64 of_translate_dcr_address(struct device_node *dev,
>> + unsigned int dcr_n,
>> + unsigned int *out_stride)
>>  {
>>   struct device_node *dp;
>>   const u32 *p;
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 95c133a0554b..52780a72d09d 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -51,10 +51,6 @@ struct platform_device *of_find_device_by_node(struct 
>> device_node *np)
>>  }
>>  EXPORT_SYMBOL(of_find_device_by_node);
>>
>> -#if defined(CONFIG_PPC_DCR)
>> -#include 
>> -#endif
>> -
>>  #ifdef CONFIG_OF_ADDRESS
>>  /*
>>   * The following routines scan a subtree and registers a device for
>> @@ -78,26 +74,6 @@ void of_device_make_bus_id(struct device *dev)
>>   const __be32 *reg;
>>   u64 addr;
>>
>> -#ifdef CONFIG_PPC_DCR
>> - /*
>> -  * If it's a DCR based device, use 'd' for native DCRs
>> -  * and 'D' for MMIO DCRs.
>> -  */
>> - reg = of_get_property(node, "dcr-reg", NULL);
>> - if (reg) {
>> -#ifdef CONFIG_PPC_DCR_NATIVE
>> - dev_set_name(dev, "d%x.%s", *reg, node->name);
>> -#else /* CONFIG_PPC_DCR_NATIVE */
>> - u64 addr = of_translate_dcr_address(node, *reg, NULL);
>> - 

[PATCH v6 1/5] usb: musb: core: Handle Babble condition only in HOST mode

[George Cherian]

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3c6043c..0ad9551 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -849,7 +849,7 @@ b_host:
}
 
/* handle babble condition */
-   if (int_usb & MUSB_INTR_BABBLE)
+   if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
schedule_work(&musb->recover_work);
 
 #if 0
-- 
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 v2 05/11] ARM: topology: use new cpu_power interface

[Preeti U Murthy]

On 05/26/2014 01:55 PM, Vincent Guittot wrote:
> On 25 May 2014 15:22, Preeti U Murthy  wrote:
>> Hi Vincent,
>>
>> Why do we have two interfaces arch_scale_freq_power() and
>> arch_scale_cpu_power()? Does it make sense to consolidate them now ?
> Hi Preeti,
> 
> They don't have the same purpose. arch_scale_cpu_power set the max
> capacity of your CPU whereas arch_scale_freq_power can be used to give
> the current capacity. ARM platform were using arch_scale_freq_power
> because it was the only one available for non SMT system but this
> induces some misunderstanding and some limitation in the
> characterization of a CPUs. This consolidation is a necessary step so
> we can now have the max capacity of a CPU and let
> arch_scale_freq_power for other purpose (or even remove it if
> useless).

Ah ok! Thanks :) This was insightful :)

Regards
Preeti U Murthy
> 
> Regards,
> Vincent
> 
>>
>> Regards
>> Preeti U Murthy
>>
>>
>> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
>>> Use the new arch_scale_cpu_power in order to reflect the original capacity 
>>> of
>>> a CPU instead of arch_scale_freq_power which is more linked to a scaling of
>>> the capacity linked to the frequency.
>>>
>>> Signed-off-by: Vincent Guittot 
>>> ---
>>>  arch/arm/kernel/topology.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
>>> index 71e1fec..6cc25a8 100644
>>> --- a/arch/arm/kernel/topology.c
>>> +++ b/arch/arm/kernel/topology.c
>>> @@ -42,7 +42,7 @@
>>>   */
>>>  static DEFINE_PER_CPU(unsigned long, cpu_scale);
>>>
>>> -unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu)
>>> +unsigned long arch_scale_cpu_power(struct sched_domain *sd, int cpu)
>>>  {
>>>   return per_cpu(cpu_scale, cpu);
>>>  }
>>> @@ -166,7 +166,7 @@ static void update_cpu_power(unsigned int cpu)
>>>   set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
>>>
>>>   printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
>>> - cpu, arch_scale_freq_power(NULL, cpu));
>>> + cpu, arch_scale_cpu_power(NULL, cpu));
>>>  }
>>>
>>>  #else
>>>
>>
> 

--
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 19/22] ARM: sunxi: Add earlyprintk support using R_UART (sun6i/sun8i)

[Chen-Yu Tsai]

On Mon, May 26, 2014 at 2:46 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, May 23, 2014 at 03:51:22PM +0800, Chen-Yu Tsai wrote:
>> sun6i/sun8i have a UART in the RTC block group, which can be used
>> as an early console. This is most useful on sun8i as UART0 is muxed
>> with MMC0, which is not available if we boot from MMC.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  arch/arm/Kconfig.debug | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index eab8ecb..9e22708 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -694,6 +694,14 @@ choice
>> Say Y here if you want kernel low-level debugging support
>> on Allwinner A1X based platforms on the UART1.
>>
>> + config DEBUG_SUNXI_R_UART
>> + bool "Kernel low-level debugging messages via sunXi R_UART"
>> + depends on ARCH_SUNXI
>
> It should rather depend on MACH_SUN8I.

I assume no sun6i devices would use it, or have pads available for it?
If so, then MACH_SUN8I makes sense.


ChenYu
--
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] arm: Set hardirq tracing to on when idling

[Arnd Bergmann]

On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
> From: Corey Minyard 
> 
> The CPU will go to idle with interrupts off, but the interrupts
> will wake up the idle.  This was causing very long irqsoff trace
> values because, basically, the whole idle time was traces with
> irqs off, even though they weren't really off.  Rework the idle
> code to turn hardirq tracing to on befor calling idle.
> 
> Signed-off-by: Corey Minyard 
> ---
>  arch/arm/kernel/process.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> I'm not sure this is correct for all ARM boards, but it fixes the
> issue for the Vexpress board I have.  No more 4 second irqsoff
> times.

If this patch is correct for ARM, I wonder if it should be done
in architecture independent code instead. Do you see the same
thing on x86? If not, do you know what's different?

It seems like the right thing to do, I just don't understand
why nobody hit this before.

Arnd
--
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 0/5] AMD IOMMUv2 Cleanups and Fixes

[Joerg Roedel]

On Tue, May 20, 2014 at 11:18:21PM +0200, Joerg Roedel wrote:
> Joerg Roedel (5):
>   iommu/amd: Don't access IOMMUv2 state_table directly
>   iommu/amd: Convert IOMMUv2 state_table into state_list
>   iommu/amd: Implement mmu_notifier_release call-back
>   iommu/amd: Remove IOMMUv2 pasid_state_list
>   iommu/amd: Handle parallel invalidate_range_start/end calls correctly

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 v3 06/13] mmc: mmci: Qcomm: Add 3 clock cycle delay after register write

[Ulf Hansson]

On 23 May 2014 14:51,   wrote:
> From: Srinivas Kandagatla 
>
> Most of the Qcomm SD card controller registers must be updated to the MCLK
> domain so subsequent writes to registers will be ignored until 3 clock cycles
> have passed.
>
> This patch adds a 3 clock cycle delay required after writing to controller
> registers on Qualcomm SOCs. Without this delay all the register writes are not
> successful, resulting in not detecting cards. The write clock delay is
> activated by setting up mclk_delayed_writes variable in variant data.
>
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Linus Walleij 
> ---
>  drivers/mmc/host/mmci.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 881bb24..1385554 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -67,6 +67,8 @@ static unsigned int fmax = 515633;
>   * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
>   * @busy_detect: true if busy detection on dat0 is supported
>   * @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
> + * @mclk_delayed_writes: enable delayed writes to ensure, subsequent updates
> + *  are not ignored.
>   */
>  struct variant_data {
> unsigned intclkreg;
> @@ -83,6 +85,7 @@ struct variant_data {
> boolpwrreg_clkgate;
> boolbusy_detect;
> boolpwrreg_nopower;
> +   boolmclk_delayed_writes;
>  };
>
>  static struct variant_data variant_arm = {
> @@ -171,6 +174,12 @@ static struct variant_data variant_qcom = {
> .datalength_bits= 24,
> .blksz_datactrl4= true,
> .pwrreg_powerup = MCI_PWR_UP,
> +   /*
> +* On QCom SD card controller, registers must be updated to the
> +* MCLK domain so subsequent writes to this register will be ignored
> +* for 3 clk cycles.
> +*/
> +   .mclk_delayed_writes= true,
>  };
>
>  static inline u32 mmci_readl(struct mmci_host *host, u32 off)
> @@ -181,6 +190,9 @@ static inline u32 mmci_readl(struct mmci_host *host, u32 
> off)
>  static inline void mmci_writel(struct mmci_host *host, u32 data, u32 off)
>  {
> writel(data, host->base + off);
> +
> +   if (host->variant->mclk_delayed_writes)
> +   udelay(DIV_ROUND_UP((3 * USEC_PER_SEC), host->mclk));
>  }

I am not sure I like this approach. For each and every writel
(including pio_writes) you will add a few cpu cycles, since you need
to  check for "mclk_delayed_writes" no matter of variant.

How about, adding a new function pointer in the struct mmci_host, for
"writel operations" which you could set up in probe phase instead?

Kind regards
Ulf Hansson
--
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: [RFC 1/2] cfg80211: Add channel flags limiting availability to OCB mode only

[Johannes Berg]

On Mon, 2014-05-26 at 11:06 +0200, Rostislav Lisovy wrote:
> On Mon, 2014-05-19 at 16:51 +0200, Johannes Berg wrote:
> > This patch is fine, but insufficient - you should also do something
> > with
> > the new flags?
> 
> That's definitely a good point. I think the biggest issue is that the
> flags can't be checked only with the knowledge of the 'wiphy' but they
> are related to the 'vif' type -- this prohibits checking in the
> cfg80211_chandef_usable() (I assume).
> 
> Would the following be sufficient?

Well, you'll find that if you address my comments on the other patch,
all of this discussion goes away easily.

johannes

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

linux-next: Tree for May 26

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140523:

The samsung tree gained a conflict against the arm-soc tree.

The nfsd tree gained a build failure so I used the version from
next-20140523.

The l2-mtd tree still had its build failure so I used the version from
next-20140521.

The mmc tree lost its build failure but gained another so I used the
version from next-20140522.

The mfd-lj tree lost its build failure.

The clockevents tree gained a conflict against the arm-soc tree and a
build failure so I used the version from next-20140523.

The cgroup tree gained a conflict against Linus' tree.

The target-updates tree lost its build failure and gained a conflict
against the scsi tree.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 8579
 7260 files changed, 333137 insertions(+), 205854 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 220 trees (counting Linus' and 29 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (c7208164e66f Linux 3.15-rc7)
Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2)
Merging arm-current/fixes (483a6c9d447f ARM: 8064/1: fix v7-M signal return)
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (8050936caf12 powerpc: irq work racing with timer 
interrupt can result in timer interrupt hang)
Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in 
arch/sparc/kernel/sysfs.c)
Merging net/master (8646224cdb94 Merge branch 'for-davem' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless)
Merging ipsec/master (6d004d6cc739 vti: Use the tunnel mark for lookup in the 
error handlers.)
Merging sound-current/for-linus (77f07800cb45 ALSA: hda - Fix onboard audio on 
Intel H97/Z97 chipsets)
Merging pci-current/for-linus (d0b4cc4e3270 PCI: Wrong register used to check 
pending traffic)
Merging wireless/master (2c316e699fa4 Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (4b660a7f5c80 Linux 3.15-rc6)
Merging tty.current/tty-linus (d6d211db37e7 Linux 3.15-rc5)
Merging usb.current/usb-linus (8ef42ddd9a53 USB: Avoid runtime suspend loops 
for HCDs that can't handle suspend/resume)
Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and 
iomem resource retrieval)
Merging staging.current/staging-linus (28a821c30688 Staging: speakup: Update 
__speakup_paste_selection() tty (ab)usage to match vt)
Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3)
Merging input-current/for-linus (0b5fe736fe92 Input: synaptics - add min/max 
quirk for the ThinkPad W540)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode 
concurrency finding.)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e7a23fea64f1 mips: dts: Fix 
missing device_type="memory" property in memory nodes)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about w

Re: [PATCH] remove duplicate checking code

[Joerg Roedel]

On Fri, May 16, 2014 at 03:39:40PM +0800, Vaughan Cao wrote:
> amd_iommu_rlookup_table[devid] != NULL is already guaranteed by check_device
> called before, it's fine to attach device at this point.
> 
> Signed-off-by: Vaughan Cao 
> ---
>  drivers/iommu/amd_iommu.c | 6 --
>  1 file changed, 6 deletions(-)

Applied, 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: remap_file_pages() use

[Kirill A. Shutemov]

Jeff Smith wrote:
> On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig  wrote:
> > On Mon, May 19, 2014 at 05:35:40PM +0300, Kirill A. Shutemov wrote:
> >> >From functional POV, emulation *should* be identical to original
> >> remap_file_pages(), but slower. It would be nice, if you test it early.
> >>
> >> It's not clear yet how long emulation will be there.
> >
> > Stop right there.  We found out about two real life users of
> > remap_file_pages() already, without even committing the patches to warn
> > about using it to any tree.
> >
> > I think at this point the whole idea of removing the API should be dead
> > on the floor, as we do not needlessly break userspace programs.
> >
> > If we can get rid of the ugly guts and provide a good enough emulation
> > that the user won't cry I'd love to get rid of this cruft, but even
> > that doesn't look certain yet.
> 
> Sorry for being late to the party, but I just noticed this proposal
> via the LWN summary byline.
> 
> I wanted to comment that Kenny's use case is (I believe) quite
> widespread. I've used the technique since ~2008, and I've come across
> other people in subsequent jobs who independently developed the same
> technique. Mirrored mapping is absolutely required by several
> independent proprietary platforms I'm aware of, and remap_file_pages()
> has historically been the only sane way to accomplish this. (i.e.,
> shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
> half).

Em.. What's wrong with shm_open() + two mmap()s to cover both halfs?

fd = shm_open();
addr1 = mmap(NULL, 2*SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
addr2 = mmap(addr1 + SIZE, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0);

Is there a reason why it doens't work?

> It may not be individuals who are involved in the kernel development
> scene to any great extent, but I am sure that remap_file_pages() being
> deprecated would seriously piss off a lot of individuals. The pattern
> has even had a section in the Wikipedia article for quite some time:
> http://en.wikipedia.org/wiki/Circular_buffer#Mirroring

I believe remap_file_pages() is abused here. But it seems we will have to
keep emulation in place for a long time.

> 
> It would be most preferable from a user standpoint to keep the
> existing system intact, but failing that, a reservation API would need
> to be created (possibly a MAP_RESERVE flag) that would set aside a
> region that could only be subsequently mapped via explicit
> address-requesting mmap() calls.

I don't get this part.

-- 
 Kirill A. Shutemov
--
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 04/22] clk: sunxi: move "ahb_sdram" to protected clock list

[Chen-Yu Tsai]

On Mon, May 26, 2014 at 2:51 AM, Maxime Ripard
 wrote:
> On Fri, May 23, 2014 at 03:51:07PM +0800, Chen-Yu Tsai wrote:
>> With sunxi_gates clocks registered with clkdev, we can use the
>> protected clocks list to enable the "ahb_sdram" clock, instead
>> of looking for it and adding CLK_IGNORE_UNUSED inline in the
>> clock setup code.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  drivers/clk/sunxi/clk-sunxi.c | 10 --
>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 3e33bc1..b2c6d12 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -870,7 +870,6 @@ static void __init sunxi_gates_clk_setup(struct 
>> device_node *node,
>>   int qty;
>>   int i = 0;
>>   int j = 0;
>> - int ignore;
>>
>>   reg = of_iomap(node, 0);
>>
>> @@ -891,15 +890,12 @@ static void __init sunxi_gates_clk_setup(struct 
>> device_node *node,
>>   of_property_read_string_index(node, "clock-output-names",
>> j, &clk_name);
>>
>> - /* No driver claims this clock, but it should remain gated */
>> - ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 
>> 0;
>> -
>>   clk_data->clks[i] = clk_register_gate(NULL, clk_name,
>> -   clk_parent, ignore,
>> +   clk_parent, 0,
>> reg + 4 * (i/32), i % 32,
>> 0, &clk_lock);
>>   WARN_ON(IS_ERR(clk_data->clks[i]));
>> - clk_register_clkdev(clks[i], clk_name, NULL);
>> + clk_register_clkdev(clk_data->clks[i], clk_name, NULL);
>
> I'm fine with the change itself, but shouldn't this part of it be in
> the patch that actually add this line?
>
> Looks broken to me otherwise.

Brain fart on my part. I squashed a fixup for patch 2 into this one.


Thanks
ChenYu
--
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/5] phy: add support for USB cluster on the Armada 375 SoC

[Kishon Vijay Abraham I]

hI,

On Saturday 24 May 2014 03:20 AM, Gregory CLEMENT wrote:
> On 23/05/2014 11:20, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote:
>>> The Armada 375 SoC comes with an USB2 host and device controller and
>>> an USB3 controller. The USB cluster control register allows to manage
>>> common features of both USB controllers.
>>>
>>> This commit adds a driver integrated in the generic PHY framework to
>>> control this USB cluster feature.
>>>
>>> Signed-off-by: Gregory CLEMENT 
>>> Signed-off-by: Thomas Petazzoni 
>>> ---
>>>  drivers/phy/Kconfig  |   6 +
>>>  drivers/phy/Makefile |   1 +
>>>  drivers/phy/phy-armada375-usb2.c | 140 
>>> +++
>>>  include/dt-bindings/phy/armada-375-usb-cluster.h |  18 +++
> [...]
> 
>>> +static struct phy_ops armada375_usb_phy_ops = {
>>> +   .init = armada375_usb_phy_init,
>>> +   .owner  = THIS_MODULE,
>>
>> nitpick: unnecessary tab.
> 
> OK
> 
>>> +};
>>> +
>>> +/*
>>> + * Only one controller can use this PHY. We shouldn't have the case
>>> + * when two controllers want to use this PHY. But if this case occurs
>>> + * then we provide a phy to the first one and return an error for the
>>> + * next one. This error has also to be an error returned by
>>> + * devm_phy_optional_get() so different from ENODEV for USB2. In the
>>> + * USB3 case it still optional and we use ENODEV.
>>> + */
>>> +static struct phy *armada375_usb_phy_xlate(struct device *dev,
>>> +   struct of_phandle_args *args)
>>> +{
>>> +   if (WARN_ON(usb_cluster_phy.phy_provided)) {
>>> +   dev_err(dev, "This PHY has already been provided!\n");
>>> +   dev_err(dev, "Check your device tree, only one controller can 
>>> use it\n.");
>>> +   if (args->args[0] == PHY_USB2)
>>> +   return ERR_PTR(-EBUSY);
>>> +   else
>>> +   return ERR_PTR(-ENODEV);
>>> +   }
>>> +
>>> +   if (args->args[0] == PHY_USB2)
>>> +   usb_cluster_phy.use_usb3 = false;
>>> +   else if (args->args[0] == PHY_USB3)
>>> +   usb_cluster_phy.use_usb3 = true;
>>> +   else {
>>> +   dev_err(dev, "Invalid PHY mode\n");
>>> +   return ERR_PTR(-ENODEV);
>>> +   }
>>
>> how will this behave if there is a phy_put and then a phy_get?
> 
> Badly I think :(
> 
> I have to think about a better solution then.
> 
>>> +
>>> +   usb_cluster_phy.phy_provided = true;
>>> +
>>> +   return usb_cluster_phy.phy;
>>> +}
>>> +
>>> +static int armada375_usb_phy_probe(struct platform_device *pdev)
>>> +{
>>> +   struct device *dev = &pdev->dev;
>>> +   struct phy *phy;
>>> +   struct phy_provider *phy_provider;
>>> +   void __iomem *usb_cluster_base;
>>> +   struct resource *res;
>>> +
>>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +   usb_cluster_base = devm_ioremap_resource(&pdev->dev, res);
>>> +   if (!usb_cluster_base)
>>> +   return -ENOMEM;
>>> +
>>> +   phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
>>> +   if (IS_ERR(phy)) {
>>> +   dev_err(dev, "failed to create PHY \n");
>>> +   return PTR_ERR(phy);
>>> +   }
>>> +
>>> +   usb_cluster_phy.phy = phy;
>>> +   usb_cluster_phy.reg = usb_cluster_base;
>>> +   phy_set_drvdata(phy, &usb_cluster_phy);
>>> +
>>> +   phy_provider = devm_of_phy_provider_register(&pdev->dev,
>>> +armada375_usb_phy_xlate);
>>> +   if (IS_ERR(phy_provider))
>>> +   return PTR_ERR(phy_provider);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static const struct of_device_id of_usb_cluster_table[] = {
>>> +   { .compatible = "marvell,armada-375-usb-cluster", },
>>> +   { /* end of list */ },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, of_usb_cluster_table);
>>> +
>>> +static struct platform_driver armada375_usb_phy_driver = {
>>> +   .probe  = armada375_usb_phy_probe,
>>> +   .driver = {
>>> +   .of_match_table = of_usb_cluster_table,
>>> +   .name  = "armada-375-usb-cluster",
>>> +   .owner = THIS_MODULE,
>>> +   }
>>> +};
>>> +module_platform_driver(armada375_usb_phy_driver);
>>> +
>>> +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
>>> +MODULE_AUTHOR("Gregory CLEMENT ");
>>> +MODULE_LICENSE("GPL");
>>
>> GPL v2?
> 
> See the header, I chose "GNU General Public License version 2 or later."
> so "GPL" match it.

Indeed! Just figured it's documented in include/linux/module.h.

Thanks
Kishon
--
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 00/11] sched: consolidation of cpu_power

[Preeti U Murthy]

Hi Vincent,

I conducted test runs of ebizzy on a Power8 box which had 48 cpus.
6 cores with SMT-8 to be precise. Its a single socket box. The results
are as below.

On 05/23/2014 09:22 PM, Vincent Guittot wrote:
> Part of this patchset was previously part of the larger tasks packing patchset
> [1]. I have splitted the latter in 3 different patchsets (at least) to make 
> the
> thing easier.
> -configuration of sched_domain topology [2]
> -update and consolidation of cpu_power (this patchset)
> -tasks packing algorithm
> 
> SMT system is no more the only system that can have a CPUs with an original
> capacity that is different from the default value. We need to extend the use 
> of
> cpu_power_orig to all kind of platform so the scheduler will have both the
> maximum capacity (cpu_power_orig/power_orig) and the current capacity
> (cpu_power/power) of CPUs and sched_groups. A new function 
> arch_scale_cpu_power
> has been created and replace arch_scale_smt_power, which is SMT specifc in the
> computation of the capapcity of a CPU.
> 
> During load balance, the scheduler evaluates the number of tasks that a group
> of CPUs can handle. The current method assumes that tasks have a fix load of 
> SCHED_LOAD_SCALE and CPUs have a default capacity of SCHED_POWER_SCALE.
> This assumption generates wrong decision by creating ghost cores and by
> removing real ones when the original capacity of CPUs is different from the
> default SCHED_POWER_SCALE.
> 
> Now that we have the original capacity of a CPUS and its activity/utilization,
> we can evaluate more accuratly the capacity of a group of CPUs.
> 
> This patchset mainly replaces the old capacity method by a new one and has 
> kept
> the policy almost unchanged whereas we can certainly take advantage of this 
> new
> statistic in several other places of the load balance.
> 
> TODO:
>  - align variable's and field's name with the renaming [3]
> 
> Tests results:
> I have put below results of 2 tests:
> - hackbench -l 500 -s 4096
> - scp of 100MB file on the platform
> 
> on a dual cortex-A7 
>   hackbenchscp
> tip/master25.75s(+/-0.25)  5.16MB/s(+/-1.49)
> + patches 1,2 25.89s(+/-0.31)  5.18MB/s(+/-1.45)
> + patches 3-1025.68s(+/-0.22)  7.00MB/s(+/-1.88)
> + irq accounting  25.80s(+/-0.25)  8.06MB/s(+/-0.05)
> 
> on a quad cortex-A15 
>   hackbenchscp
> tip/master15.69s(+/-0.16)  9.70MB/s(+/-0.04)
> + patches 1,2 15.53s(+/-0.13)  9.72MB/s(+/-0.05)
> + patches 3-1015.56s(+/-0.22)  9.88MB/s(+/-0.05)
> + irq accounting  15.99s(+/-0.08) 10.37MB/s(+/-0.03)
> 
> The improvement of scp bandwidth happens when tasks and irq are using
> different CPU which is a bit random without irq accounting config

N -> Number of threads of ebizzy

Each 'N' run was for 30 seconds with multiple iterations and averaging them.

N  %change in number of records
   read after patching
--
1  + 0.0038
4  -17.6429
8  -26.3989
12 -29.5070
16 -38.4842
20 -44.5747
24 -51.9792
28 -34.1863
32 -38.4029
38 -22.2490
42  -7.4843
47 -0.69676

Let me profile it and check where the cause of this degradation is.


Regards
Preeti U Murthy

--
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: [GIT PULL] clockevents: new material for 3.16

[Daniel Lezcano]

On 05/26/2014 11:45 AM, Stephen Rothwell wrote:

Hi all,

On Fri, 23 May 2014 12:22:04 +0200 Daniel Lezcano  
wrote:


clocksource: sun5i: Add support for reset controller


This commit caused a build failure on arm in linux-next today ...


Thanks Stephen.

Maxime ?


--
  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 07/13] mmc: mmci: add ddrmode mask to variant data

[Ulf Hansson]

On 23 May 2014 14:51,   wrote:
> From: Srinivas Kandagatla 
>
> This patch adds ddrmode mask to variant structure giving more flexibility
> to the driver to support more SOCs which have different datactrl register
> layout.
>
> Without this patch datactrl register is updated with wrong ddrmode mask on non
> ST SOCs, resulting in card detection failures.
>
> Signed-off-by: Srinivas Kandagatla 
> Reviewed-by: Linus Walleij 
> ---
>  drivers/mmc/host/mmci.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 1385554..dec70d2 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -59,6 +59,7 @@ static unsigned int fmax = 515633;
>   *   is asserted (likewise for RX)
>   * @sdio: variant supports SDIO
>   * @st_clkdiv: true if using a ST-specific clock divider algorithm
> + * @datactrl_mask_ddrmode: ddr mode mask in datactrl register.
>   * @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl 
> register
>   * @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
>   *  register
> @@ -76,6 +77,7 @@ struct variant_data {
> unsigned intdatalength_bits;
> unsigned intfifosize;
> unsigned intfifohalfsize;
> +   unsigned intdatactrl_mask_ddrmode;
> boolsdio;
> boolst_clkdiv;
> boolblksz_datactrl16;
> @@ -114,6 +116,7 @@ static struct variant_data variant_u300 = {
> .fifosize   = 16 * 4,
> .fifohalfsize   = 8 * 4,
> .clkreg_enable  = MCI_ST_U300_HWFCEN,
> +   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,
> .datalength_bits= 16,
> .sdio   = true,
> .pwrreg_powerup = MCI_PWR_ON,
> @@ -126,6 +129,7 @@ static struct variant_data variant_nomadik = {
> .fifosize   = 16 * 4,
> .fifohalfsize   = 8 * 4,
> .clkreg = MCI_CLK_ENABLE,
> +   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,
> .datalength_bits= 24,
> .sdio   = true,
> .st_clkdiv  = true,
> @@ -140,6 +144,7 @@ static struct variant_data variant_ux500 = {
> .fifohalfsize   = 8 * 4,
> .clkreg = MCI_CLK_ENABLE,
> .clkreg_enable  = MCI_ST_UX500_HWFCEN,
> +   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,
> .datalength_bits= 24,
> .sdio   = true,
> .st_clkdiv  = true,
> @@ -155,6 +160,7 @@ static struct variant_data variant_ux500v2 = {
> .fifohalfsize   = 8 * 4,
> .clkreg = MCI_CLK_ENABLE,
> .clkreg_enable  = MCI_ST_UX500_HWFCEN,
> +   .datactrl_mask_ddrmode  = MCI_ST_DPSM_DDRMODE,

Only the ux500v2 supports DDR mode, using the MCI_ST_DPSM_DDRMODE bit.

> .datalength_bits= 24,
> .sdio   = true,
> .st_clkdiv  = true,
> @@ -800,7 +806,7 @@ static void mmci_start_data(struct mmci_host *host, 
> struct mmc_data *data)
> }
>
> if (host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
> -   datactrl |= MCI_ST_DPSM_DDRMODE;
> +   datactrl |= variant->datactrl_mask_ddrmode;
>
> /*
>  * Attempt to use DMA operation mode, if this
> --
> 1.9.1
>

Kind regards
Ulf Hansson
--
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/

[RFT][PATCH] regulator: pfuze100: Support enable/disable for fixed regulator

[Axel Lin]

Current code has .enable_reg and .enable_mask settings, but the implementation
for corresponding callbacks are missing. Fix it.

Signed-off-by: Axel Lin 
---
Hi Robin,
Can you review and test this patch?
Thanks,
Axel

 drivers/regulator/pfuze100-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 67e678c..b6b4529 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -125,6 +125,9 @@ static struct regulator_ops pfuze100_ldo_regulator_ops = {
 };
 
 static struct regulator_ops pfuze100_fixed_regulator_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
.list_voltage = regulator_list_voltage_linear,
 };
 
-- 
1.8.3.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: [PATCHv5 3/3] edac: altera: Add EDAC support for Altera SoC SDRAM Controller

[Borislav Petkov]

On Thu, May 15, 2014 at 11:04:51AM -0500, ttha...@altera.com wrote:
> From: Thor Thayer 
> 
> v2: Use the SDRAM controller registers to calculate memory size
> instead of the Device Tree. Update To & Cc list. Add maintainer
> information.
> 
> v3: EDAC driver cleanup based on comments from Mailing list.
> 
> v4: Panic on DBE. Add macro around inject-error reads to prevent
> them from being optimized out. Remove of_match_ptr since this
> will always use Device Tree.
> 
> v5: Addition of printk to trigger function to ensure read vars
> are not optimized out.

Yeah, you could turn those vX: messages into a real commit message -
much better than none at all :-)

Other than that, the edac bits look ok. I'll wait out until you guys've
sorted the devicetree issues so ping me when it is ready to pick up.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 0/5] tps65917: Add support for for TPS65917 PMIC

[Keerthy]

The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - GPADC.
 - Over Temperature warning and Shut down.

This patch series adds support for TPS65917 mfd device. At this time only
the regulator functionality is made available.

The closest drivers are PALMAS series drivers. Hence adapted palmas mfd
driver to support the tps65917 PMIC.

The register set for SMPSs and LDOs are changed and the ramp delay support
is also changed. Bit-field defenitions are changed.
Hence based on the PALMAS drivers and created a new driver
for regulator with code changes as required.

The patches are boot tested on DRA72-EVM.

Keerthy (5):
  mfd: Add DT bindings for tps65917 PMIC
  Regulators: Add TPS65917 Bindings
  mfd: palmas: Add tps65917 specific definitions and enums 
  mfd: palmas: Add tps65917 support
  regulator: tps65917: Add Regulator driver for tps65917 PMIC

 Documentation/devicetree/bindings/mfd/palmas.txt   |2 +
 .../bindings/regulator/tps65917-pmic.txt   |   67 ++
 drivers/mfd/palmas.c   |  177 -
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  825 
 include/linux/mfd/palmas.h |  793 +++
 7 files changed, 1872 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
 create mode 100644 drivers/regulator/tps65917-regulator.c

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

[PATCH 5/5] regulator: tps65917: Add Regulator driver for tps65917 PMIC

[Keerthy]

This patch adds support for TPS65917 PMIC regulators.

The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.

Signed-off-by: Keerthy 
---
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  815 
 3 files changed, 828 insertions(+)
 create mode 100644 drivers/regulator/tps65917-regulator.c

Index: linux/drivers/regulator/Kconfig
===
--- linux.orig/drivers/regulator/Kconfig2014-05-26 15:21:12.269247638 
+0530
+++ linux/drivers/regulator/Kconfig 2014-05-26 15:21:46.956121138 +0530
@@ -581,6 +581,18 @@
help
This driver supports TPS65912 voltage regulator chip.
 
+config REGULATOR_TPS65917
+   tristate "TI TPS65917 PMIC Regulators"
+   depends on MFD_PALMAS
+   help
+ If you wish to control the regulators on the TPS65917 series of
+ chips say Y here. This will enable support for all the software
+ controllable SMPS/LDO regulators.
+
+ The regulators available on TPS65917 series chips vary depending
+ on the muxing. This is handled automatically in the driver by
+ reading the mux info from OTP.
+
 config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
Index: linux/drivers/regulator/Makefile
===
--- linux.orig/drivers/regulator/Makefile   2014-05-26 15:21:12.269247638 
+0530
+++ linux/drivers/regulator/Makefile2014-05-26 15:21:46.956121138 +0530
@@ -76,6 +76,7 @@
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65917) += tps65917-regulator.o
 obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
 obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
 obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
Index: linux/drivers/regulator/tps65917-regulator.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux/drivers/regulator/tps65917-regulator.c2014-05-26 
15:22:25.994853307 +0530
@@ -0,0 +1,814 @@
+/*
+ * Driver for Regulator part of TPS65917 PMIC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct regulator_linear_range smps_low_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(51, 0x7, 0x79, 1),
+   REGULATOR_LINEAR_RANGE(165, 0x7A, 0x7f, 0),
+};
+
+static const struct regulator_linear_range smps_high_ranges[] = {
+   REGULATOR_LINEAR_RANGE(100, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(102, 0x7, 0x79, 2),
+   REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
+};
+
+struct regs_info {
+   char*name;
+   char*sname;
+   u8  vsel_addr;
+   u8  ctrl_addr;
+   int sleep_id;
+};
+
+static const struct regs_info tps65917_regs_info[] = {
+   {
+   .name   = "SMPS1",
+   .sname  = "smps1-in",
+   .vsel_addr  = TPS65917_SMPS1_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS1_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+   },
+   {
+   .name   = "SMPS2",
+   .sname  = "smps2-in",
+   .vsel_addr  = TPS65917_SMPS2_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS2_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+   },
+   {
+   .name   = "SMPS3",
+   .sname  = "smps3-in",
+   .vsel_addr  = TPS65917_SMPS3_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS3_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+   },
+   {
+   .name   = "SMPS4",
+   .sname  = "smps4-in",
+   .vsel_addr  = TPS65917_SMPS4_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS4_CTRL

[PATCH 2/5] Regulators: Add TPS65917 Bindings

[Keerthy]

Add TPS65917 Bindings.

Signed-off-by: Keerthy 
---
 .../bindings/regulator/tps65917-pmic.txt   |   67 
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt

diff --git a/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt 
b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
new file mode 100644
index 000..96d1fb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
@@ -0,0 +1,67 @@
+* tps65917 regulator IP block devicetree bindings
+
+Required properties:
+- compatible : Should be
+  ti,tps65917-pmic
+
+- interrupt-parent : The parent interrupt controller which is tps65917.
+- interrupts : The interrupt number and the type which can be looked up here:
+  arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
+- interrupts-name: The names of the individual interrupts.
+
+Optional nodes:
+- regulators : Must contain a sub-node per regulator from the list below.
+  Each sub-node should contain the constraints and initialization
+  information for that regulator. See regulator.txt for a
+  description of standard properties for these sub-nodes.
+  Additional custom properties  are listed below.
+
+  Optional sub-node properties:
+  ti,warm-reset - maintain voltage during warm reset(boolean)
+  ti,roof-floor - This takes as optional argument on platform 
supporting
+  the rail from desired external control. If there is no argument 
then
+  it will be assume that it is controlled by NSLEEP pin.
+  The valid value for external pins are:
+   ENABLE1 then 1,
+   ENABLE2 then 2 or
+   NSLEEP then 3.
+  ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  2 - eco, 3 - forced pwm
+  ti,smps-range - OTP has the wrong range set for the hardware so 
override
+  0 - low range, 1 - high range.
+
+- ti,system-power-controller: Telling whether or not this pmic is controlling
+ the system power.
+
+Example:
+
+#include 
+
+pmic {
+   compatible = "ti,tps65917-pmic";
+   interrupt-parent = <&tps65917>;
+   interrupts = <14 IRQ_TYPE_NONE>;
+   interrupts-name = "short-irq";
+
+   ti,system-power-controller;
+
+   regulators {
+   smps1_reg : smps1 {
+   regulator-name = "smps1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,warm-reset;
+   ti,roof-floor = <1>; /* ENABLE1 control */
+   ti,mode-sleep = <0>;
+   ti,smps-range = <1>;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   };
+   };
+};
-- 
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: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM

[Alexandre Courbot]

On Fri, May 23, 2014 at 6:24 PM, Lucas Stach  wrote:
>> The best way to solve this issue would be to not use the BAR at all
>> since the memory behind these objects can be directly accessed by the
>> CPU. As such it would better be mapped using ttm_bo_kmap_ttm()
>> instead. But right now this is clearly not how nouveau_bo.c is written
>> and it does not look like this can easily be done. :/
>
> Yeah, it sounds like we want this shortcut for stolen VRAM
> implementations.

Tried playing a bit with nouveau_bo and the following hack allows a
simple Mesa program to run to completion... once (second time leads to
a kernel panic):

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f00ae18003f1..6317d30a8e1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -538,7 +538,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
-   case TTM_PL_VRAM:
if (nv_device(drm->device)->card_type >= NV_50) {
man->func = &nouveau_vram_manager;
man->io_reserve_fastpath = false;
@@ -556,6 +555,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
man->default_caching = TTM_PL_FLAG_WC;
 #endif
break;
+   case TTM_PL_VRAM:
case TTM_PL_TT:
if (nv_device(drm->device)->card_type >= NV_50)
man->func = &nouveau_gart_manager;
@@ -1297,6 +1297,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_mem_reg *mem)
break;
/* fallthrough, tiled memory */
case TTM_PL_VRAM:
+   break;
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = nv_device_resource_start(nouveau_dev(dev), 1);
mem->bus.is_iomem = true;


Of course it won't go very far this way, but I wonder if the principle
is not what we would want to do for UMA devices? Not using the vram
manager at all, and strictly rely on TT placements for BOs. We will
need to add extra handling for things like tiled memory. Does that
look like the right direction?
--
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/