Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Oscar Salvador
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add latency by 60%. Modify external
> providers of online callback to align with the change.

Hi Arun, out of curiosity:

could you please explain how exactly did you mesure the speed
improvement?

Thanks
-- 
Oscar Salvador
SUSE L3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/2] media: v4l: Add definitions for the HEVC slice format and controls

2018-10-10 Thread Tomasz Figa
Hi Paul,

On Tue, Aug 28, 2018 at 5:02 PM Paul Kocialkowski
 wrote:
>
> This introduces the required definitions for HEVC decoding support with
> stateless VPUs. The controls associated to the HEVC slice format provide
> the required meta-data for decoding slices extracted from the bitstream.
>

Sorry for being late to the party. Please see my comments inline. Only
high level, because I don't know too much about HEVC.

[snip]
> +``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)``
> +Specifies the Sequence Parameter Set fields (as extracted from the
> +bitstream) for the associated HEVC slice data.
> +The bitstream parameters are defined according to the ISO/IEC 23008-2 and
> +ITU-T Rec. H.265 specifications.
> +
> +.. c:type:: v4l2_ctrl_hevc_sps
> +
> +.. cssclass:: longtable
> +
> +.. flat-table:: struct v4l2_ctrl_hevc_sps
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - __u8
> +  - ``chroma_format_idc``
> +  - Syntax description inherited from the specification.

I wonder if it wouldn't make sense to instead document this in C code
using kernel-doc and then have the kernel-doc included in the sphinx
doc. It seems to be possible, according to
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html .

Such approach would have the advantage of the person looking through C
cross reference being able to actually see the documentation of the
struct in question and also making it easier to ensure the relevant C
code and documentation are in sync. (Although this is UAPI so it would
be unlikely to change too often or at all.)

[snip]
> +``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS (struct)``
> +Specifies various slice-specific parameters, especially from the NAL unit
> +header, general slice segment header and weighted prediction parameter
> +parts of the bitstream.
> +The bitstream parameters are defined according to the ISO/IEC 23008-2 and
> +ITU-T Rec. H.265 specifications.

In the Chromium H.264 controls, we define this as an array control, so
that we can include multiple slices in one buffer and each entry of
the array has an offset field pointing to the part of the buffer that
contains corresponding slice data. I've mentioned this in the
discussion on Alex's stateless decoder interface documentation, so
let's keep the discussion there, though.

[snip]
> @@ -1696,6 +1708,11 @@ static int std_validate(const struct v4l2_ctrl *ctrl, 
> u32 idx,
> case V4L2_CTRL_TYPE_H264_DECODE_PARAMS:
> return 0;
>
> +   case V4L2_CTRL_TYPE_HEVC_SPS:
> +   case V4L2_CTRL_TYPE_HEVC_PPS:
> +   case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> +   return 0;
> +

I wonder to what extent we should be validating this. I can see 3 options:
1) Defer validation to drivers completely. - Potentially error prone
and leading to a lot of code duplication?
2) Validate completely. - Might need solving some interesting
problems, e.g. validating reference frame indices in DPB against
current state of respective VB2 queue...
3) Validate only what we can easily do, defer more complicated
validation to the drivers. - Potentially a good middle ground?

Best regards,
Tomasz
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Arun KS

On 2018-10-10 13:37, Oscar Salvador wrote:

On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:

When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of online callback to align with the change.


Hi Arun, out of curiosity:

could you please explain how exactly did you mesure the speed
improvement?


diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e379e85..2416136 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -690,9 +690,13 @@ static int online_pages_range(unsigned long 
start_pfn, unsigned long nr_pages,

void *arg)
 {
unsigned long onlined_pages = *(unsigned long *)arg;
+   u64 t1, t2;

+   t1 = local_clock();
if (PageReserved(pfn_to_page(start_pfn)))
onlined_pages = online_pages_blocks(start_pfn, 
nr_pages);

+   t2 = local_clock();
+   trace_printk("time spend = %llu us\n", (t2-t1)/(1000));

online_mem_sections(start_pfn, start_pfn + nr_pages);


Regards,
Arun



Thanks

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Oscar Salvador
On Wed, Oct 10, 2018 at 04:21:16PM +0530, Arun KS wrote:
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e379e85..2416136 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -690,9 +690,13 @@ static int online_pages_range(unsigned long start_pfn,
> unsigned long nr_pages,
> void *arg)
>  {
> unsigned long onlined_pages = *(unsigned long *)arg;
> +   u64 t1, t2;
> 
> +   t1 = local_clock();
> if (PageReserved(pfn_to_page(start_pfn)))
> onlined_pages = online_pages_blocks(start_pfn, nr_pages);
> +   t2 = local_clock();
> +   trace_printk("time spend = %llu us\n", (t2-t1)/(1000));
> 
> online_mem_sections(start_pfn, start_pfn + nr_pages);

Thanks ;-)
 

-- 
Oscar Salvador
SUSE L3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gasket: Fix sparse "incorrect type in assignment" warnings.

2018-10-10 Thread Laurence Rochfort
On Tue, Oct 09, 2018 at 03:13:03PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Oct 04, 2018 at 06:52:25PM +0100, Laurence Rochfort wrote:
> > Silence the below sparse warnings by casting betwen u8 __iomem *, and
> > void *.
> > 
> > warning: incorrect type in assignment (different address spaces)
> >expected unsigned char [noderef] [usertype] *virt_base
> >got void *[assigned] mem
> > warning: incorrect type in argument 3 (different address spaces)
> >expected void *cpu_addr
> >got unsigned char [noderef] [usertype] *virt_base
> > 
> > Signed-off-by: Laurence Rochfort 
> > ---
> >  drivers/staging/gasket/gasket_page_table.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/staging/gasket/gasket_page_table.c 
> > b/drivers/staging/gasket/gasket_page_table.c
> > index d4c5f8a..7f5e5b3 100644
> > --- a/drivers/staging/gasket/gasket_page_table.c
> > +++ b/drivers/staging/gasket/gasket_page_table.c
> > @@ -1278,7 +1278,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > *gasket_dev, u64 size,
> >  dma_addr_t *dma_address, u64 index)
> >  {
> > dma_addr_t handle;
> > -   void *mem;
> > +   u8 __iomem *mem;
> > int j;
> > unsigned int num_pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> > const struct gasket_driver_desc *driver_desc =
> > @@ -1290,7 +1290,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > *gasket_dev, u64 size,
> > if (num_pages == 0)
> > return -EINVAL;
> >  
> > -   mem = dma_alloc_coherent(gasket_get_device(gasket_dev),
> > +   mem = (u8 __iomem *)dma_alloc_coherent(gasket_get_device(gasket_dev),
> >  num_pages * PAGE_SIZE, &handle, 0);
> > if (!mem)
> > goto nomem;
> > @@ -1325,7 +1325,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > *gasket_dev, u64 size,
> >  nomem:
> > if (mem) {
> > dma_free_coherent(gasket_get_device(gasket_dev),
> > - num_pages * PAGE_SIZE, mem, handle);
> > + num_pages * PAGE_SIZE, (void __force *)mem, 
> > handle);
> > }
> >  
> > if (gasket_dev->page_table[index]->coherent_pages) {
> > @@ -1353,7 +1353,7 @@ int gasket_free_coherent_memory(struct gasket_dev 
> > *gasket_dev, u64 size,
> > if (gasket_dev->coherent_buffer.length_bytes) {
> > dma_free_coherent(gasket_get_device(gasket_dev),
> >   gasket_dev->coherent_buffer.length_bytes,
> > - gasket_dev->coherent_buffer.virt_base,
> > + (void __force 
> > *)gasket_dev->coherent_buffer.virt_base,
> 
> We should not have to "force" anything here.  Something feels wrong in
> the definition of these variable types...
>From bde80ff6bdab740d838210aa3e664c8901b2142a Mon Sep 17 00:00:00 2001
From: Laurence Rochfort 
Date: Thu, 4 Oct 2018 18:42:26 +0100
Subject: [PATCH v2] staging: gasket: Fix sparse "incorrect type in assignment"
 warnings.

Correct the coherent buffer data type and memory space cookie.

sparse errors were being generated when passing virt_base to
dma_alloc_coherent().

warning: incorrect type in assignment (different address spaces)
   expected unsigned char [noderef] [usertype] *virt_base
   got void *[assigned] mem
warning: incorrect type in argument 3 (different address spaces)
   expected void *cpu_addr
   got unsigned char [noderef] [usertype] *virt_base

Signed-off-by: Laurence Rochfort 
---
Changes in v2:
- Correct data type rather than forcing type coersion, as per gkh

 drivers/staging/gasket/gasket_core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gasket/gasket_core.h 
b/drivers/staging/gasket/gasket_core.h
index 275fd0b..9d09678 100644
--- a/drivers/staging/gasket/gasket_core.h
+++ b/drivers/staging/gasket/gasket_core.h
@@ -231,7 +231,7 @@ struct gasket_coherent_buffer_desc {
 /* Coherent buffer structure. */
 struct gasket_coherent_buffer {
/* Virtual base address. */
-   u8 __iomem *virt_base;
+   void *virt_base;
 
/* Physical base address. */
ulong phys_base;
-- 
2.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: gasket: Fix sparse "incorrect type in assignment" warnings.

2018-10-10 Thread Greg Kroah-Hartman
On Wed, Oct 10, 2018 at 03:03:05PM +0100, Laurence Rochfort wrote:
> On Tue, Oct 09, 2018 at 03:13:03PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Oct 04, 2018 at 06:52:25PM +0100, Laurence Rochfort wrote:
> > > Silence the below sparse warnings by casting betwen u8 __iomem *, and
> > > void *.
> > > 
> > > warning: incorrect type in assignment (different address spaces)
> > >expected unsigned char [noderef] [usertype] *virt_base
> > >got void *[assigned] mem
> > > warning: incorrect type in argument 3 (different address spaces)
> > >expected void *cpu_addr
> > >got unsigned char [noderef] [usertype] *virt_base
> > > 
> > > Signed-off-by: Laurence Rochfort 
> > > ---
> > >  drivers/staging/gasket/gasket_page_table.c | 10 +-
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/staging/gasket/gasket_page_table.c 
> > > b/drivers/staging/gasket/gasket_page_table.c
> > > index d4c5f8a..7f5e5b3 100644
> > > --- a/drivers/staging/gasket/gasket_page_table.c
> > > +++ b/drivers/staging/gasket/gasket_page_table.c
> > > @@ -1278,7 +1278,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > > *gasket_dev, u64 size,
> > >dma_addr_t *dma_address, u64 index)
> > >  {
> > >   dma_addr_t handle;
> > > - void *mem;
> > > + u8 __iomem *mem;
> > >   int j;
> > >   unsigned int num_pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> > >   const struct gasket_driver_desc *driver_desc =
> > > @@ -1290,7 +1290,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > > *gasket_dev, u64 size,
> > >   if (num_pages == 0)
> > >   return -EINVAL;
> > >  
> > > - mem = dma_alloc_coherent(gasket_get_device(gasket_dev),
> > > + mem = (u8 __iomem *)dma_alloc_coherent(gasket_get_device(gasket_dev),
> > >num_pages * PAGE_SIZE, &handle, 0);
> > >   if (!mem)
> > >   goto nomem;
> > > @@ -1325,7 +1325,7 @@ int gasket_alloc_coherent_memory(struct gasket_dev 
> > > *gasket_dev, u64 size,
> > >  nomem:
> > >   if (mem) {
> > >   dma_free_coherent(gasket_get_device(gasket_dev),
> > > -   num_pages * PAGE_SIZE, mem, handle);
> > > +   num_pages * PAGE_SIZE, (void __force *)mem, 
> > > handle);
> > >   }
> > >  
> > >   if (gasket_dev->page_table[index]->coherent_pages) {
> > > @@ -1353,7 +1353,7 @@ int gasket_free_coherent_memory(struct gasket_dev 
> > > *gasket_dev, u64 size,
> > >   if (gasket_dev->coherent_buffer.length_bytes) {
> > >   dma_free_coherent(gasket_get_device(gasket_dev),
> > > gasket_dev->coherent_buffer.length_bytes,
> > > -   gasket_dev->coherent_buffer.virt_base,
> > > +   (void __force 
> > > *)gasket_dev->coherent_buffer.virt_base,
> > 
> > We should not have to "force" anything here.  Something feels wrong in
> > the definition of these variable types...

> >From bde80ff6bdab740d838210aa3e664c8901b2142a Mon Sep 17 00:00:00 2001
> From: Laurence Rochfort 
> Date: Thu, 4 Oct 2018 18:42:26 +0100
> Subject: [PATCH v2] staging: gasket: Fix sparse "incorrect type in assignment"
>  warnings.
> 
> Correct the coherent buffer data type and memory space cookie.

Why have you attached a patch?  I can't do anything with that.

And it seems wrong as well, are you sure about this change?

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Vlastimil Babka
On 10/5/18 10:10 AM, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add latency by 60%. Modify external
> providers of online callback to align with the change.
> 
> Signed-off-by: Arun KS 

[...]

> @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
>  }
>  EXPORT_SYMBOL_GPL(__online_page_free);
>  
> -static void generic_online_page(struct page *page)
> +static int generic_online_page(struct page *page, unsigned int order)
>  {
> - __online_page_set_limits(page);

This is now not called anymore, although the xen/hv variants still do
it. The function seems empty these days, maybe remove it as a followup
cleanup?

> - __online_page_increment_counters(page);
> - __online_page_free(page);
> + __free_pages_core(page, order);
> + totalram_pages += (1UL << order);
> +#ifdef CONFIG_HIGHMEM
> + if (PageHighMem(page))
> + totalhigh_pages += (1UL << order);
> +#endif

__online_page_increment_counters() would have used
adjust_managed_page_count() which would do the changes under
managed_page_count_lock. Are we safe without the lock? If yes, there
should perhaps be a comment explaining why.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 2/2] mm/page_alloc: remove software prefetching in __free_pages_core

2018-10-10 Thread Vlastimil Babka
On 10/5/18 10:10 AM, Arun KS wrote:
> They not only increase the code footprint, they actually make things
> slower rather than faster. Remove them as contemporary hardware doesn't
> need any hint.
> 
> Suggested-by: Dan Williams 
> Signed-off-by: Arun KS 

Yeah, a tight loop with fixed stride is a trivial case for hw prefetcher.

Acked-by: Vlastimil Babka 

> ---
>  mm/page_alloc.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7ab5274..90db431 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1258,14 +1258,10 @@ void __free_pages_core(struct page *page, unsigned 
> int order)
>   struct page *p = page;
>   unsigned int loop;
>  
> - prefetchw(p);
> - for (loop = 0; loop < (nr_pages - 1); loop++, p++) {
> - prefetchw(p + 1);
> + for (loop = 0; loop < nr_pages ; loop++, p++) {
>   __ClearPageReserved(p);
>   set_page_count(p, 0);
>   }
> - __ClearPageReserved(p);
> - set_page_count(p, 0);
>  
>   page_zone(page)->managed_pages += nr_pages;
>   set_page_refcounted(page);
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Arun KS

On 2018-10-10 21:00, Vlastimil Babka wrote:

On 10/5/18 10:10 AM, Arun KS wrote:

When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of online callback to align with the change.

Signed-off-by: Arun KS 


[...]


@@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
 }
 EXPORT_SYMBOL_GPL(__online_page_free);

-static void generic_online_page(struct page *page)
+static int generic_online_page(struct page *page, unsigned int order)
 {
-   __online_page_set_limits(page);


This is now not called anymore, although the xen/hv variants still do
it. The function seems empty these days, maybe remove it as a followup
cleanup?


-   __online_page_increment_counters(page);
-   __online_page_free(page);
+   __free_pages_core(page, order);
+   totalram_pages += (1UL << order);
+#ifdef CONFIG_HIGHMEM
+   if (PageHighMem(page))
+   totalhigh_pages += (1UL << order);
+#endif


__online_page_increment_counters() would have used
adjust_managed_page_count() which would do the changes under
managed_page_count_lock. Are we safe without the lock? If yes, there
should perhaps be a comment explaining why.


Looks unsafe without managed_page_count_lock. I think better have a 
similar implementation of free_boot_core() in memory_hotplug.c like we 
had in version 1 of patch. And use adjust_managed_page_count() instead 
of page_zone(page)->managed_pages += nr_pages;


https://lore.kernel.org/patchwork/patch/989445/

-static void generic_online_page(struct page *page)
+static int generic_online_page(struct page *page, unsigned int order)
 {
-   __online_page_set_limits(page);
-   __online_page_increment_counters(page);
-   __online_page_free(page);
+   unsigned long nr_pages = 1 << order;
+   struct page *p = page;
+
+   for (loop = 0 ; loop < nr_pages ; loop++, p++) {
+   __ClearPageReserved(p);
+   set_page_count(p, 0);
+   }
+
+   adjust_managed_page_count(page, nr_pages);
+   set_page_refcounted(page);
+   __free_pages(page, order);
+
+   return 0;
+}


Regards,
Arun

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 02/15] Revert "platform/olpc: Make ec explicitly non-modular"

2018-10-10 Thread Lubomir Rintel
It doesn't make sense to always have this built-in, e.g. on ARM
multiplatform kernels. A better way to address the problem the original
commit aimed to solve is to fix Kconfig.

This reverts commit f48d1496b8537d75776478c6942dd87f34d7f270.

Signed-off-by: Lubomir Rintel 
---
 drivers/platform/olpc/olpc-ec.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 374a8028fec7..f99b183d5296 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -1,8 +1,6 @@
 /*
  * Generic driver for the OLPC Embedded Controller.
  *
- * Author: Andres Salomon 
- *
  * Copyright (C) 2011-2012 One Laptop per Child Foundation.
  *
  * Licensed under the GPL v2 or later.
@@ -14,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -328,4 +326,8 @@ static int __init olpc_ec_init_module(void)
 {
return platform_driver_register(&olpc_ec_plat_driver);
 }
+
 arch_initcall(olpc_ec_init_module);
+
+MODULE_AUTHOR("Andres Salomon ");
+MODULE_LICENSE("GPL");
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 0/15] Add support for OLPC XO 1.75 Embedded Controller

2018-10-10 Thread Lubomir Rintel
Hi.

This patchset adds support for the Embedded Controller on an OLPC XO
1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
the existing OLPC platform infrastructure, currently used by the x86
based models.

The EC operates in SPI master mode, meaning the SOC is the SPI slave. It
uses extra handshake signal to signal readiness of SOC to accept data
from EC and to initiate a transaction if SOC wishes to submit data.

The SPI slave support for MMP2 was submitted separately:
https://lore.kernel.org/lkml/20181010170936.316862-1-lkund...@v3.sk/T/#t

THe "power: supply: olpc_battery: correct the temperature" patch was
already sent out separately, but I'm including it because the last
commit of the set depends on it.

Tested to work on an OLPC XO 1.75 and also tested not to break x86
support with an OLPC XO 1 machine. I don't have a XO 1.5, but it's
unlikely this breaks it when XO 1 works.

Thanks in advance for reviews and feedback of any kind.

Lubo

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 03/15] dt-bindings: olpc, xo1.75-ec: Add OLPC XO-1.75 EC bindings

2018-10-10 Thread Lubomir Rintel
The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra
signals for handshaking. It needs to know when is the slave (Linux)
side's TX FIFO ready for transfer (the ready-gpio signal on the SPI
controller node) and when does it wish to respond with a command (the
cmd-gpio property).

Signed-off-by: Lubomir Rintel 
---
 .../bindings/misc/olpc,xo1.75-ec.txt  | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt

diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt 
b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt
new file mode 100644
index ..14385fee65d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt
@@ -0,0 +1,24 @@
+OLPC XO-1.75 Embedded Controller
+
+Required properties:
+- compatible: Should be "olpc,xo1.75-ec".
+- cmd-gpio: gpio specifier of the CMD pin
+
+The embedded controller requires the SPI controller driver to signal readiness
+to receive a transfer (that is, when TX FIFO contains the response data) by
+strobing the ACK pin with the ready signal. See the "ready-gpio" property of 
the
+SSP binding as documented in:
+.
+
+Example:
+   &ssp3 {
+   spi-slave;
+   status = "okay";
+   ready-gpio = <&gpio 125 GPIO_ACTIVE_HIGH>;
+
+   slave {
+   compatible = "olpc,xo1.75-ec";
+   spi-cpha;
+   cmd-gpio = <&gpio 155 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 04/15] Platform: OLPC: Remove an unused include

2018-10-10 Thread Lubomir Rintel
Also, the header is x86 specific, while there are non-x86 OLPC machines.

Signed-off-by: Lubomir Rintel 
---
 drivers/platform/olpc/olpc-ec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index f99b183d5296..35a21c66cd0d 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 
 struct ec_cmd_desc {
u8 cmd;
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 10/15] dt-bindings: olpc_battery: Add XO-1.5 battery

2018-10-10 Thread Lubomir Rintel
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature.

Signed-off-by: Lubomir Rintel 
---
 Documentation/devicetree/bindings/power/supply/olpc_battery.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/power/supply/olpc_battery.txt 
b/Documentation/devicetree/bindings/power/supply/olpc_battery.txt
index c8901b3992d9..8d87d6b35a98 100644
--- a/Documentation/devicetree/bindings/power/supply/olpc_battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/olpc_battery.txt
@@ -2,4 +2,4 @@ OLPC battery
 
 
 Required properties:
-  - compatible : "olpc,xo1-battery"
+  - compatible : "olpc,xo1-battery" or "olpc,xo1.5-battery"
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 01/15] power: supply: olpc_battery: correct the temperature units

2018-10-10 Thread Lubomir Rintel
According to [1] and [2], the temperature values are in tenths of degree
Celsius. Exposing the Celsius value makes the battery appear on fire:

  $ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery
  ...
  temperature: 236.9 degrees C

Tested on OLPC XO-1 and OLPC XO-1.75 laptops.

[1] include/linux/power_supply.h
[2] Documentation/power/power_supply_class.txt

Cc: sta...@vger.kernel.org
Signed-off-by: Lubomir Rintel 
---
 drivers/power/supply/olpc_battery.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/supply/olpc_battery.c 
b/drivers/power/supply/olpc_battery.c
index 6da79ae14860..5a97e42a3547 100644
--- a/drivers/power/supply/olpc_battery.c
+++ b/drivers/power/supply/olpc_battery.c
@@ -428,14 +428,14 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
 
-   val->intval = (s16)be16_to_cpu(ec_word) * 100 / 256;
+   val->intval = (s16)be16_to_cpu(ec_word) * 10 / 256;
break;
case POWER_SUPPLY_PROP_TEMP_AMBIENT:
ret = olpc_ec_cmd(EC_AMB_TEMP, NULL, 0, (void *)&ec_word, 2);
if (ret)
return ret;
 
-   val->intval = (int)be16_to_cpu(ec_word) * 100 / 256;
+   val->intval = (int)be16_to_cpu(ec_word) * 10 / 256;
break;
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
ret = olpc_ec_cmd(EC_BAT_ACR, NULL, 0, (void *)&ec_word, 2);
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 05/15] Platform: OLPC: Move OLPC config symbol out of x86 tree

2018-10-10 Thread Lubomir Rintel
There are ARM OLPC machines that use mostly the same drivers, including
EC infrastructure, DCON and Battery.

While at that, fix Kconfig to allow building this as a module.

Signed-off-by: Lubomir Rintel 
---
 arch/x86/Kconfig  | 11 ---
 drivers/input/mouse/Kconfig   |  2 +-
 drivers/platform/Kconfig  |  2 ++
 drivers/platform/olpc/Kconfig | 11 +++
 drivers/staging/olpc_dcon/Kconfig |  2 +-
 5 files changed, 15 insertions(+), 13 deletions(-)
 create mode 100644 drivers/platform/olpc/Kconfig

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1a0be022f91d..be6af341a718 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2729,17 +2729,6 @@ config SCx200HR_TIMER
  processor goes idle (as is done by the scheduler).  The
  other workaround is idle=poll boot option.
 
-config OLPC
-   bool "One Laptop Per Child support"
-   depends on !X86_PAE
-   select GPIOLIB
-   select OF
-   select OF_PROMTREE
-   select IRQ_DOMAIN
-   ---help---
- Add support for detecting the unique features of the OLPC
- XO hardware.
-
 config OLPC_XO1_PM
bool "OLPC XO-1 Power Management"
depends on OLPC && MFD_CS5535 && PM_SLEEP
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 566a1e3aa504..58034892a4df 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -165,7 +165,7 @@ config MOUSE_PS2_TOUCHKIT
 
 config MOUSE_PS2_OLPC
bool "OLPC PS/2 mouse protocol extension"
-   depends on MOUSE_PS2 && OLPC
+   depends on MOUSE_PS2 && X86 && OLPC
help
  Say Y here if you have an OLPC XO-1 laptop (with built-in
  PS/2 touchpad/tablet device).  The manufacturer calls the
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index d4c2e424a700..4313d73d3618 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -10,3 +10,5 @@ source "drivers/platform/goldfish/Kconfig"
 source "drivers/platform/chrome/Kconfig"
 
 source "drivers/platform/mellanox/Kconfig"
+
+source "drivers/platform/olpc/Kconfig"
diff --git a/drivers/platform/olpc/Kconfig b/drivers/platform/olpc/Kconfig
new file mode 100644
index ..7b736c9e67ac
--- /dev/null
+++ b/drivers/platform/olpc/Kconfig
@@ -0,0 +1,11 @@
+config OLPC
+   tristate "One Laptop Per Child support"
+   depends on X86 || ARM || COMPILE_TEST
+   depends on !X86_PAE
+   select GPIOLIB
+   select OF
+   select OF_PROMTREE if X86
+   select IRQ_DOMAIN
+   help
+ Add support for detecting the unique features of the OLPC
+ XO hardware.
diff --git a/drivers/staging/olpc_dcon/Kconfig 
b/drivers/staging/olpc_dcon/Kconfig
index c91a56f77bcb..07f9f1de8667 100644
--- a/drivers/staging/olpc_dcon/Kconfig
+++ b/drivers/staging/olpc_dcon/Kconfig
@@ -1,6 +1,6 @@
 config FB_OLPC_DCON
tristate "One Laptop Per Child Display CONtroller support"
-   depends on OLPC && FB
+   depends on X86 && OLPC && FB
depends on I2C
depends on (GPIO_CS5535 || GPIO_CS5535=n)
select BACKLIGHT_CLASS_DEVICE
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 12/15] power: supply: olpc_battery: Use DT to get battery version

2018-10-10 Thread Lubomir Rintel
Avoid using the x86 OLPC platform specific call to get the board
version. It won't work on FDT-based ARM MMP2 platform.

Signed-off-by: Lubomir Rintel 
---
 drivers/power/supply/olpc_battery.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/olpc_battery.c 
b/drivers/power/supply/olpc_battery.c
index 5a97e42a3547..540d44bf536f 100644
--- a/drivers/power/supply/olpc_battery.c
+++ b/drivers/power/supply/olpc_battery.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -622,11 +623,13 @@ static int olpc_battery_probe(struct platform_device 
*pdev)
olpc_ac = power_supply_register(&pdev->dev, &olpc_ac_desc, NULL);
if (IS_ERR(olpc_ac))
return PTR_ERR(olpc_ac);
-
-   if (olpc_board_at_least(olpc_board_pre(0xd0))) { /* XO-1.5 */
+   if (of_property_match_string(pdev->dev.of_node, "compatible",
+   "olpc,xo1.5-battery") >= 0) {
+   /* XO-1.5 */
olpc_bat_desc.properties = olpc_xo15_bat_props;
olpc_bat_desc.num_properties = ARRAY_SIZE(olpc_xo15_bat_props);
-   } else { /* XO-1 */
+   } else {
+   /* XO-1 */
olpc_bat_desc.properties = olpc_xo1_bat_props;
olpc_bat_desc.num_properties = ARRAY_SIZE(olpc_xo1_bat_props);
}
@@ -672,6 +675,7 @@ static int olpc_battery_remove(struct platform_device *pdev)
 
 static const struct of_device_id olpc_battery_ids[] = {
{ .compatible = "olpc,xo1-battery" },
+   { .compatible = "olpc,xo1.5-battery" },
{}
 };
 MODULE_DEVICE_TABLE(of, olpc_battery_ids);
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 14/15] power: supply: olpc_battery: Avoid using platform_info

2018-10-10 Thread Lubomir Rintel
This wouldn't work on the DT-based ARM platform. Let's read the EC version
directly from the EC driver instead.

This makes the driver no longer x86 specific.

Signed-off-by: Lubomir Rintel 
---
 drivers/power/supply/Kconfig|  2 +-
 drivers/power/supply/olpc_battery.c | 35 +
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index ff6dab0bf0dd..f0361e4dd457 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -151,7 +151,7 @@ config BATTERY_PMU
 
 config BATTERY_OLPC
tristate "One Laptop Per Child battery"
-   depends on X86_32 && OLPC
+   depends on OLPC
help
  Say Y to enable support for the battery on the OLPC laptop.
 
diff --git a/drivers/power/supply/olpc_battery.c 
b/drivers/power/supply/olpc_battery.c
index 2a2d7cc995f0..dde9863e5c4a 100644
--- a/drivers/power/supply/olpc_battery.c
+++ b/drivers/power/supply/olpc_battery.c
@@ -20,8 +20,6 @@
 #include 
 #include 
 #include 
-#include 
-
 
 #define EC_BAT_VOLTAGE 0x10/* uint16_t,*9.76/32,mV   */
 #define EC_BAT_CURRENT 0x11/* int16_t, *15.625/120, mA   */
@@ -57,6 +55,7 @@ struct olpc_battery_data {
struct power_supply *olpc_ac;
struct power_supply *olpc_bat;
char bat_serial[17];
+   int new_proto;
 };
 
 /*
@@ -100,7 +99,7 @@ static const struct power_supply_desc olpc_ac_desc = {
 static int olpc_bat_get_status(struct olpc_battery_data *data,
union power_supply_propval *val, uint8_t ec_byte)
 {
-   if (olpc_platform_info.ecver > 0x44) {
+   if (data->new_proto) {
if (ec_byte & (BAT_STAT_CHARGING | BAT_STAT_TRICKLE))
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (ec_byte & BAT_STAT_DISCHARGING)
@@ -608,14 +607,32 @@ static int olpc_battery_probe(struct platform_device 
*pdev)
struct power_supply_config psy_cfg = {};
struct olpc_battery_data *data;
uint8_t status;
+   unsigned char ecver[1];
+   int ret;
+
+   data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+   platform_set_drvdata(pdev, data);
+
+   /* See if the EC is already there and get the EC revision */
+   ret = olpc_ec_cmd(EC_FIRMWARE_REV, NULL, 0, ecver, ARRAY_SIZE(ecver));
+   if (ret) {
+   if (ret == -ENODEV)
+   return -EPROBE_DEFER;
+   return ret;
+   }
 
-   /*
-* We've seen a number of EC protocol changes; this driver requires
-* the latest EC protocol, supported by 0x44 and above.
-*/
-   if (olpc_platform_info.ecver < 0x44) {
+   if (ecver[0] > 0x44) {
+   /* XO 1 or 1.5 with a new EC firmware. */
+   data->new_proto = 1;
+   } else if (ecver[0] < 0x44) {
+   /*
+* We've seen a number of EC protocol changes; this driver
+* requires the latest EC protocol, supported by 0x44 and above.
+*/
printk(KERN_NOTICE "OLPC EC version 0x%02x too old for "
-   "battery driver.\n", olpc_platform_info.ecver);
+   "battery driver.\n", ecver[0]);
return -ENXIO;
}
 
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 07/15] Platform: OLPC: Avoid a warning if the EC didn't register yet

2018-10-10 Thread Lubomir Rintel
Just return ENODEV, so that whoever attempted to use the EC call can
defer their work.

Signed-off-by: Lubomir Rintel 
---
 drivers/platform/olpc/olpc-ec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 35a21c66cd0d..342f5bb7f7a8 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -116,8 +116,11 @@ int olpc_ec_cmd(u8 cmd, u8 *inbuf, size_t inlen, u8 
*outbuf, size_t outlen)
struct olpc_ec_priv *ec = ec_priv;
struct ec_cmd_desc desc;
 
-   /* Ensure a driver and ec hook have been registered */
-   if (WARN_ON(!ec_driver || !ec_driver->ec_cmd))
+   /* Driver not yet registered. */
+   if (!ec_driver)
+   return -ENODEV;
+
+   if (WARN_ON(!ec_driver->ec_cmd))
return -ENODEV;
 
if (!ec)
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 09/15] Platform: OLPC: add a regulator for the DCON

2018-10-10 Thread Lubomir Rintel
All OLPC ECs are able to turn the power to the DCON on an off. Use the
regulator framework to expose the functionality.

Signed-off-by: Lubomir Rintel 
---
 drivers/platform/olpc/Kconfig   |  1 +
 drivers/platform/olpc/olpc-ec.c | 65 +
 2 files changed, 66 insertions(+)

diff --git a/drivers/platform/olpc/Kconfig b/drivers/platform/olpc/Kconfig
index 7c643d24ad0f..c5a872fb286f 100644
--- a/drivers/platform/olpc/Kconfig
+++ b/drivers/platform/olpc/Kconfig
@@ -6,6 +6,7 @@ config OLPC
select OF
select OF_PROMTREE if X86
select IRQ_DOMAIN
+   select REGULATOR
help
  Add support for detecting the unique features of the OLPC
  XO hardware.
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index b9d9a9897dd5..8f82922631a9 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct ec_cmd_desc {
@@ -34,6 +35,10 @@ struct olpc_ec_priv {
struct work_struct worker;
struct mutex cmd_lock;
 
+   /* DCON regulator */
+   struct regulator_dev *dcon_rdev;
+   bool dcon_enabled;
+
/* Pending EC commands */
struct list_head cmd_q;
spinlock_t cmd_q_lock;
@@ -347,9 +352,60 @@ static struct dentry *olpc_ec_setup_debugfs(void)
 
 #endif /* CONFIG_DEBUG_FS */
 
+static int olpc_ec_set_dcon_power(struct olpc_ec_priv *ec, bool state)
+{
+   unsigned char ec_byte = state;
+   int ret;
+
+   if (ec->dcon_enabled == state)
+   return 0;
+
+   ret = olpc_ec_cmd(EC_DCON_POWER_MODE, &ec_byte, 1, NULL, 0);
+   if (ret == 0)
+   ec->dcon_enabled = state;
+
+   return ret;
+}
+
+static int dcon_regulator_enable(struct regulator_dev *rdev)
+{
+   struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
+
+   return olpc_ec_set_dcon_power(ec, 1);
+}
+
+static int dcon_regulator_disable(struct regulator_dev *rdev)
+{
+   struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
+
+   return olpc_ec_set_dcon_power(ec, 0);
+}
+
+static int dcon_regulator_is_enabled(struct regulator_dev *rdev)
+{
+   struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
+
+   return ec->dcon_enabled;
+}
+
+static struct regulator_ops dcon_regulator_ops = {
+   .enable = dcon_regulator_enable,
+   .disable= dcon_regulator_disable,
+   .is_enabled = dcon_regulator_is_enabled,
+};
+
+static const struct regulator_desc dcon_desc = {
+   .name   = "dcon",
+   .id = 0,
+   .ops= &dcon_regulator_ops,
+   .type   = REGULATOR_VOLTAGE,
+   .owner  = THIS_MODULE,
+};
+
 static int olpc_ec_probe(struct platform_device *pdev)
 {
struct olpc_ec_priv *ec;
+   struct regulator_config config = { };
int err;
 
if (!ec_driver)
@@ -378,6 +434,15 @@ static int olpc_ec_probe(struct platform_device *pdev)
return err;
}
 
+   config.dev = pdev->dev.parent;
+   config.driver_data = ec;
+   ec->dcon_enabled = true;
+   ec->dcon_rdev = devm_regulator_register(&pdev->dev, &dcon_desc, 
&config);
+   if (IS_ERR(ec->dcon_rdev)) {
+   dev_err(&pdev->dev, "failed to register DCON regulator\n");
+   return PTR_ERR(ec->dcon_rdev);
+   }
+
ec->dbgfs_dir = olpc_ec_setup_debugfs();
 
return err;
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 11/15] x86, olpc: Use a correct version when making up a battery node

2018-10-10 Thread Lubomir Rintel
The XO-1 and XO-1.5 batteries apparently differ in an ability to report
ambient temperature. Add a different compatible string to the 1.5
battery.

Signed-off-by: Lubomir Rintel 
---
 arch/x86/platform/olpc/olpc_dt.c | 59 +++-
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index d6ee92986920..6e54e116b0c5 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -218,10 +218,28 @@ static u32 __init olpc_dt_get_board_revision(void)
return be32_to_cpu(rev);
 }
 
-void __init olpc_dt_fixup(void)
+int olpc_dt_compatible_match(phandle node, const char *compat)
 {
-   int r;
char buf[64];
+   int plen;
+   char *p;
+   int len;
+
+   plen = olpc_dt_getproperty(node, "compatible", buf, sizeof(buf));
+   if (plen <= 0)
+   return 0;
+
+   len = strlen(compat);
+   for (p = buf; p < buf + plen; p += strlen(p) + 1) {
+   if (strcmp(p, compat) == 0)
+   return 1;
+   }
+
+   return 0;
+}
+
+void __init olpc_dt_fixup(void)
+{
phandle node;
u32 board_rev;
 
@@ -229,32 +247,33 @@ void __init olpc_dt_fixup(void)
if (!node)
return;
 
-   /*
-* If the battery node has a compatible property, we are running a new
-* enough firmware and don't have fixups to make.
-*/
-   r = olpc_dt_getproperty(node, "compatible", buf, sizeof(buf));
-   if (r > 0)
-   return;
-
-   pr_info("PROM DT: Old firmware detected, applying fixes\n");
-
-   /* Add olpc,xo1-battery compatible marker to battery node */
-   olpc_dt_interpret("\" /battery@0\" find-device"
-   " \" olpc,xo1-battery\" +compatible"
-   " device-end");
-
board_rev = olpc_dt_get_board_revision();
if (!board_rev)
return;
 
if (board_rev >= olpc_board_pre(0xd0)) {
+   if (olpc_dt_compatible_match(node, "olpc,xo1.5-battery"))
+   return;
+
+   /* Add olpc,xo1.5-battery compatible marker to battery node */
+   olpc_dt_interpret("\" /battery@0\" find-device"
+   " \" olpc,xo1.5-battery\" +compatible"
+   " device-end");
+
+   /* We're running a very old firmware if this is missing. */
+   if (olpc_dt_compatible_match(node, "olpc,xo1-battery"))
+   return;
+
/* XO-1.5: add dcon device */
olpc_dt_interpret("\" /pci/display@1\" find-device"
" new-device"
" \" dcon\" device-name \" olpc,xo1-dcon\" +compatible"
" finish-device device-end");
} else {
+   /* We're running a very old firmware if this is missing. */
+   if (olpc_dt_compatible_match(node, "olpc,xo1-battery"))
+   return;
+
/* XO-1: add dcon device, mark RTC as olpc,xo1-rtc */
olpc_dt_interpret("\" /pci/display@1,1\" find-device"
" new-device"
@@ -264,6 +283,11 @@ void __init olpc_dt_fixup(void)
" \" olpc,xo1-rtc\" +compatible"
" device-end");
}
+
+   /* Add olpc,xo1-battery compatible marker to battery node */
+   olpc_dt_interpret("\" /battery@0\" find-device"
+   " \" olpc,xo1-battery\" +compatible"
+   " device-end");
 }
 
 void __init olpc_dt_build_devicetree(void)
@@ -289,6 +313,7 @@ void __init olpc_dt_build_devicetree(void)
 /* A list of DT node/bus matches that we want to expose as platform devices */
 static struct of_device_id __initdata of_ids[] = {
{ .compatible = "olpc,xo1-battery" },
+   { .compatible = "olpc,xo1.5-battery" },
{ .compatible = "olpc,xo1-dcon" },
{ .compatible = "olpc,xo1-rtc" },
{},
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 13/15] power: supply: olpc_battery: Move priv data to a struct

2018-10-10 Thread Lubomir Rintel
The global variables for private data are not too nice. I'd like some
more, and that would clutter the global name space even further.

Signed-off-by: Lubomir Rintel 
---
 drivers/power/supply/olpc_battery.c | 73 +++--
 1 file changed, 38 insertions(+), 35 deletions(-)

diff --git a/drivers/power/supply/olpc_battery.c 
b/drivers/power/supply/olpc_battery.c
index 540d44bf536f..2a2d7cc995f0 100644
--- a/drivers/power/supply/olpc_battery.c
+++ b/drivers/power/supply/olpc_battery.c
@@ -53,6 +53,12 @@
 
 #define BAT_ADDR_MFR_TYPE  0x5F
 
+struct olpc_battery_data {
+   struct power_supply *olpc_ac;
+   struct power_supply *olpc_bat;
+   char bat_serial[17];
+};
+
 /*
  * Power
  */
@@ -91,11 +97,8 @@ static const struct power_supply_desc olpc_ac_desc = {
.get_property = olpc_ac_get_prop,
 };
 
-static struct power_supply *olpc_ac;
-
-static char bat_serial[17]; /* Ick */
-
-static int olpc_bat_get_status(union power_supply_propval *val, uint8_t 
ec_byte)
+static int olpc_bat_get_status(struct olpc_battery_data *data,
+   union power_supply_propval *val, uint8_t ec_byte)
 {
if (olpc_platform_info.ecver > 0x44) {
if (ec_byte & (BAT_STAT_CHARGING | BAT_STAT_TRICKLE))
@@ -326,6 +329,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
 enum power_supply_property psp,
 union power_supply_propval *val)
 {
+   struct olpc_battery_data *data = power_supply_get_drvdata(psy);
int ret = 0;
__be16 ec_word;
uint8_t ec_byte;
@@ -347,7 +351,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
 
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
-   ret = olpc_bat_get_status(val, ec_byte);
+   ret = olpc_bat_get_status(data, val, ec_byte);
if (ret)
return ret;
break;
@@ -450,8 +454,8 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
 
-   sprintf(bat_serial, "%016llx", (long long)be64_to_cpu(ser_buf));
-   val->strval = bat_serial;
+   sprintf(data->bat_serial, "%016llx", (long 
long)be64_to_cpu(ser_buf));
+   val->strval = data->bat_serial;
break;
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
ret = olpc_bat_get_voltage_max_design(val);
@@ -579,17 +583,17 @@ static struct power_supply_desc olpc_bat_desc = {
.use_for_apm = 1,
 };
 
-static struct power_supply *olpc_bat;
-
 static int olpc_battery_suspend(struct platform_device *pdev,
pm_message_t state)
 {
-   if (device_may_wakeup(&olpc_ac->dev))
+   struct olpc_battery_data *data = platform_get_drvdata(pdev);
+
+   if (device_may_wakeup(&data->olpc_ac->dev))
olpc_ec_wakeup_set(EC_SCI_SRC_ACPWR);
else
olpc_ec_wakeup_clear(EC_SCI_SRC_ACPWR);
 
-   if (device_may_wakeup(&olpc_bat->dev))
+   if (device_may_wakeup(&data->olpc_bat->dev))
olpc_ec_wakeup_set(EC_SCI_SRC_BATTERY | EC_SCI_SRC_BATSOC
   | EC_SCI_SRC_BATERR);
else
@@ -601,7 +605,8 @@ static int olpc_battery_suspend(struct platform_device 
*pdev,
 
 static int olpc_battery_probe(struct platform_device *pdev)
 {
-   int ret;
+   struct power_supply_config psy_cfg = {};
+   struct olpc_battery_data *data;
uint8_t status;
 
/*
@@ -620,9 +625,13 @@ static int olpc_battery_probe(struct platform_device *pdev)
 
/* Ignore the status. It doesn't actually matter */
 
-   olpc_ac = power_supply_register(&pdev->dev, &olpc_ac_desc, NULL);
-   if (IS_ERR(olpc_ac))
-   return PTR_ERR(olpc_ac);
+   psy_cfg.of_node = pdev->dev.of_node;
+   psy_cfg.drv_data = data;
+
+   data->olpc_ac = devm_power_supply_register(&pdev->dev, &olpc_ac_desc, 
&psy_cfg);
+   if (IS_ERR(data->olpc_ac))
+   return PTR_ERR(data->olpc_ac);
+
if (of_property_match_string(pdev->dev.of_node, "compatible",
"olpc,xo1.5-battery") >= 0) {
/* XO-1.5 */
@@ -634,42 +643,36 @@ static int olpc_battery_probe(struct platform_device 
*pdev)
olpc_bat_desc.num_properties = ARRAY_SIZE(olpc_xo1_bat_props);
}
 
-   olpc_bat = power_supply_register(&pdev->dev, &olpc_bat_desc, NULL);
-   if (IS_ERR(olpc_bat)) {
-   ret = PTR_ERR(olpc_bat);
-   goto battery_failed;
-   }
+   data->olpc_bat = devm_power_supply_register(&pdev->dev, &olpc_bat_desc, 
&psy_cfg);
+   if (IS_ERR(data->olpc_bat))
+   return PTR_ERR(data->olpc_bat);
 

[PATCH 06/15] Platform: OLPC: Add XO-1.75 EC driver

2018-10-10 Thread Lubomir Rintel
It's based off the driver from the OLPC kernel sources. Somewhat
modernized and cleaned up, for better or worse.

Modified to plug into the olpc-ec driver infrastructure (so that battery
interface and debugfs could be reused) and the SPI slave framework.

Signed-off-by: Lubomir Rintel 
---
 drivers/platform/olpc/Kconfig |  15 +
 drivers/platform/olpc/Makefile|   1 +
 drivers/platform/olpc/olpc-xo175-ec.c | 755 ++
 3 files changed, 771 insertions(+)
 create mode 100644 drivers/platform/olpc/olpc-xo175-ec.c

diff --git a/drivers/platform/olpc/Kconfig b/drivers/platform/olpc/Kconfig
index 7b736c9e67ac..7c643d24ad0f 100644
--- a/drivers/platform/olpc/Kconfig
+++ b/drivers/platform/olpc/Kconfig
@@ -9,3 +9,18 @@ config OLPC
help
  Add support for detecting the unique features of the OLPC
  XO hardware.
+
+if OLPC
+
+config OLPC_XO175_EC
+   tristate "OLPC XO 1.75 Embedded Controller"
+   depends on ARCH_MMP || COMPILE_TEST
+   select SPI_SLAVE
+   help
+ Include support for the OLPC XO Embedded Controller (EC). The EC
+ provides various platform services, including support for the power,
+ button, restart, shutdown and battery charging status.
+
+ Unless you have an OLPC XO laptop, you will want to say N.
+
+endif
diff --git a/drivers/platform/olpc/Makefile b/drivers/platform/olpc/Makefile
index dc8b26bc7209..5b43f383289e 100644
--- a/drivers/platform/olpc/Makefile
+++ b/drivers/platform/olpc/Makefile
@@ -2,3 +2,4 @@
 # OLPC XO platform-specific drivers
 #
 obj-$(CONFIG_OLPC) += olpc-ec.o
+obj-$(CONFIG_OLPC_XO175_EC)+= olpc-xo175-ec.o
diff --git a/drivers/platform/olpc/olpc-xo175-ec.c 
b/drivers/platform/olpc/olpc-xo175-ec.c
new file mode 100644
index ..6333a1366730
--- /dev/null
+++ b/drivers/platform/olpc/olpc-xo175-ec.c
@@ -0,0 +1,755 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for the OLPC XO-1.75 Embedded Controller.
+ *
+ * The EC protocol is documented at:
+ * http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol
+ *
+ * Copyright (C) 2010 One Laptop per Child Foundation.
+ * Copyright (C) 2018 Lubomir Rintel 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct ec_cmd_t {
+   u8 cmd;
+   u8 bytes_returned;
+};
+
+enum ec_chan_t {
+   CHAN_NONE = 0,
+   CHAN_SWITCH,
+   CHAN_CMD_RESP,
+   CHAN_KEYBOARD,
+   CHAN_TOUCHPAD,
+   CHAN_EVENT,
+   CHAN_DEBUG,
+   CHAN_CMD_ERROR,
+};
+
+/*
+ * EC events
+ */
+#define EVENT_AC_CHANGE1  /* AC plugged/unplugged */
+#define EVENT_BATTERY_STATUS   2  /* Battery low/full/error/gone */
+#define EVENT_BATTERY_CRITICAL 3  /* Battery critical voltage */
+#define EVENT_BATTERY_SOC_CHANGE   4  /* 1% SOC Change */
+#define EVENT_BATTERY_ERROR5  /* Abnormal error, query for cause */
+#define EVENT_POWER_PRESSED6  /* Power button was pressed */
+#define EVENT_POWER_PRESS_WAKE 7  /* Woken up with a power button */
+#define EVENT_TIMED_HOST_WAKE  8  /* Host wake timer */
+#define EVENT_OLS_HIGH_LIMIT   9  /* OLS crossed dark threshold */
+#define EVENT_OLS_LOW_LIMIT10 /* OLS crossed light threshold */
+
+/*
+ * EC commands
+ * (from http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/ec_cmd.h)
+ */
+#define CMD_GET_API_VERSION0x08 /* out: u8 */
+#define CMD_READ_VOLTAGE   0x10 /* out: u16, *9.76/32, mV */
+#define CMD_READ_CURRENT   0x11 /* out: s16, *15.625/120, mA */
+#define CMD_READ_ACR   0x12 /* out: s16, *6250/15, uAh */
+#define CMD_READ_BATT_TEMPERATURE  0x13 /* out: u16, *100/256, deg C */
+#define CMD_READ_AMBIENT_TEMPERATURE   0x14 /* unimplemented, no hardware */
+#define CMD_READ_BATTERY_STATUS0x15 /* out: u8, bitmask */
+#define CMD_READ_SOC   0x16 /* out: u8, percentage */
+#define CMD_READ_GAUGE_ID  0x17 /* out: u8 * 8 */
+#define CMD_READ_GAUGE_DATA0x18 /* in: u8 addr, out: u8 data */
+#define CMD_READ_BOARD_ID  0x19 /* out: u16 (platform id) */
+#define CMD_READ_BATT_ERR_CODE 0x1f /* out: u8, error bitmask */
+#define CMD_SET_DCON_POWER 0x26 /* in: u8 */
+#define CMD_RESET_EC   0x28 /* none */
+#define CMD_READ_BATTERY_TYPE  0x2c /* out: u8 */
+#define CMD_SET_AUTOWAK0x33 /* out: u8 */
+#define CMD_SET_EC_WAKEUP_TIMER0x36 /* in: u32, out: ? */
+#define CMD_READ_EXT_SCI_MASK  0x37 /* ? */
+#define CMD_WRITE_EXT_SCI_MASK 0x38 /* ? */
+#define CMD_CLEAR_EC_WAKEUP_TIMER  0x39 /* none */
+#define CMD_ENABLE_RUNIN_DISCHARGE 0x3B /* none */
+#define CMD_DISABLE_RUNIN_DISCHARGE0x3C /* none */
+#define CMD_READ_MPPT_ACTIV

[PATCH 15/15] power: supply: olpc_battery: Add OLPC XO 1.75 support

2018-10-10 Thread Lubomir Rintel
The battery and the protocol are essentially the same as OLPC XO 1.5,
but the responses from the EC are LSB first.

Signed-off-by: Lubomir Rintel 
---
 drivers/power/supply/olpc_battery.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/power/supply/olpc_battery.c 
b/drivers/power/supply/olpc_battery.c
index dde9863e5c4a..2adf33b9f641 100644
--- a/drivers/power/supply/olpc_battery.c
+++ b/drivers/power/supply/olpc_battery.c
@@ -56,6 +56,7 @@ struct olpc_battery_data {
struct power_supply *olpc_bat;
char bat_serial[17];
int new_proto;
+   int little_endian;
 };
 
 /*
@@ -321,6 +322,14 @@ static int olpc_bat_get_voltage_max_design(union 
power_supply_propval *val)
return ret;
 }
 
+static s16 ecword_to_cpu(struct olpc_battery_data *data, u16 ec_byte)
+{
+   if (data->little_endian)
+   return le16_to_cpu(ec_byte);
+   else
+   return be16_to_cpu(ec_byte);
+}
+
 /*
  * Battery properties
  */
@@ -393,7 +402,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
 
-   val->intval = (s16)be16_to_cpu(ec_word) * 9760L / 32;
+   val->intval = ecword_to_cpu(data, ec_word) * 9760L / 32;
break;
case POWER_SUPPLY_PROP_CURRENT_AVG:
case POWER_SUPPLY_PROP_CURRENT_NOW:
@@ -401,7 +410,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
 
-   val->intval = (s16)be16_to_cpu(ec_word) * 15625L / 120;
+   val->intval = ecword_to_cpu(data, ec_word) * 15625L / 120;
break;
case POWER_SUPPLY_PROP_CAPACITY:
ret = olpc_ec_cmd(EC_BAT_SOC, NULL, 0, &ec_byte, 1);
@@ -432,21 +441,21 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
 
-   val->intval = (s16)be16_to_cpu(ec_word) * 10 / 256;
+   val->intval = ecword_to_cpu(data, ec_word) * 10 / 256;
break;
case POWER_SUPPLY_PROP_TEMP_AMBIENT:
ret = olpc_ec_cmd(EC_AMB_TEMP, NULL, 0, (void *)&ec_word, 2);
if (ret)
return ret;
 
-   val->intval = (int)be16_to_cpu(ec_word) * 10 / 256;
+   val->intval = (int)ecword_to_cpu(data, ec_word) * 10 / 256;
break;
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
ret = olpc_ec_cmd(EC_BAT_ACR, NULL, 0, (void *)&ec_word, 2);
if (ret)
return ret;
 
-   val->intval = (s16)be16_to_cpu(ec_word) * 6250 / 15;
+   val->intval = ecword_to_cpu(data, ec_word) * 6250 / 15;
break;
case POWER_SUPPLY_PROP_SERIAL_NUMBER:
ret = olpc_ec_cmd(EC_BAT_SERIAL, NULL, 0, (void *)&ser_buf, 8);
@@ -626,6 +635,10 @@ static int olpc_battery_probe(struct platform_device *pdev)
if (ecver[0] > 0x44) {
/* XO 1 or 1.5 with a new EC firmware. */
data->new_proto = 1;
+   } else if (of_find_compatible_node(NULL, NULL, "olpc,xo1.75-ec")) {
+   /* XO 1.75 */
+   data->new_proto = 1;
+   data->little_endian = 1;
} else if (ecver[0] < 0x44) {
/*
 * We've seen a number of EC protocol changes; this driver
-- 
2.19.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 08/15] Platform: OLPC: Move EC-specific functionality out from x86

2018-10-10 Thread Lubomir Rintel
It is actually plaform independent. Move it to the olpc-ec driver from
the X86 OLPC platform, so that it could be used by the ARM based laptops
too.

Signed-off-by: Lubomir Rintel 
---
 arch/x86/include/asm/olpc.h |  17 -
 arch/x86/platform/olpc/olpc.c   | 119 +---
 drivers/platform/olpc/olpc-ec.c | 103 ++-
 include/linux/olpc-ec.h |  32 -
 4 files changed, 149 insertions(+), 122 deletions(-)

diff --git a/arch/x86/include/asm/olpc.h b/arch/x86/include/asm/olpc.h
index c2bf1de5d901..cf13d1254550 100644
--- a/arch/x86/include/asm/olpc.h
+++ b/arch/x86/include/asm/olpc.h
@@ -9,12 +9,10 @@
 struct olpc_platform_t {
int flags;
uint32_t boardrev;
-   int ecver;
 };
 
 #define OLPC_F_PRESENT 0x01
 #define OLPC_F_DCON0x02
-#define OLPC_F_EC_WIDE_SCI 0x04
 
 #ifdef CONFIG_OLPC
 
@@ -64,13 +62,6 @@ static inline int olpc_board_at_least(uint32_t rev)
return olpc_platform_info.boardrev >= rev;
 }
 
-extern void olpc_ec_wakeup_set(u16 value);
-extern void olpc_ec_wakeup_clear(u16 value);
-extern bool olpc_ec_wakeup_available(void);
-
-extern int olpc_ec_mask_write(u16 bits);
-extern int olpc_ec_sci_query(u16 *sci_value);
-
 #else
 
 static inline int machine_is_olpc(void)
@@ -83,14 +74,6 @@ static inline int olpc_has_dcon(void)
return 0;
 }
 
-static inline void olpc_ec_wakeup_set(u16 value) { }
-static inline void olpc_ec_wakeup_clear(u16 value) { }
-
-static inline bool olpc_ec_wakeup_available(void)
-{
-   return false;
-}
-
 #endif
 
 #ifdef CONFIG_OLPC_XO1_PM
diff --git a/arch/x86/platform/olpc/olpc.c b/arch/x86/platform/olpc/olpc.c
index f0e920fb98ad..c6c62b4f251f 100644
--- a/arch/x86/platform/olpc/olpc.c
+++ b/arch/x86/platform/olpc/olpc.c
@@ -30,9 +30,6 @@
 struct olpc_platform_t olpc_platform_info;
 EXPORT_SYMBOL_GPL(olpc_platform_info);
 
-/* EC event mask to be applied during suspend (defining wakeup sources). */
-static u16 ec_wakeup_mask;
-
 /* what the timeout *should* be (in ms) */
 #define EC_BASE_TIMEOUT 20
 
@@ -186,83 +183,6 @@ static int olpc_xo1_ec_cmd(u8 cmd, u8 *inbuf, size_t 
inlen, u8 *outbuf,
return ret;
 }
 
-void olpc_ec_wakeup_set(u16 value)
-{
-   ec_wakeup_mask |= value;
-}
-EXPORT_SYMBOL_GPL(olpc_ec_wakeup_set);
-
-void olpc_ec_wakeup_clear(u16 value)
-{
-   ec_wakeup_mask &= ~value;
-}
-EXPORT_SYMBOL_GPL(olpc_ec_wakeup_clear);
-
-/*
- * Returns true if the compile and runtime configurations allow for EC events
- * to wake the system.
- */
-bool olpc_ec_wakeup_available(void)
-{
-   if (!machine_is_olpc())
-   return false;
-
-   /*
-* XO-1 EC wakeups are available when olpc-xo1-sci driver is
-* compiled in
-*/
-#ifdef CONFIG_OLPC_XO1_SCI
-   if (olpc_platform_info.boardrev < olpc_board_pre(0xd0)) /* XO-1 */
-   return true;
-#endif
-
-   /*
-* XO-1.5 EC wakeups are available when olpc-xo15-sci driver is
-* compiled in
-*/
-#ifdef CONFIG_OLPC_XO15_SCI
-   if (olpc_platform_info.boardrev >= olpc_board_pre(0xd0)) /* XO-1.5 */
-   return true;
-#endif
-
-   return false;
-}
-EXPORT_SYMBOL_GPL(olpc_ec_wakeup_available);
-
-int olpc_ec_mask_write(u16 bits)
-{
-   if (olpc_platform_info.flags & OLPC_F_EC_WIDE_SCI) {
-   __be16 ec_word = cpu_to_be16(bits);
-   return olpc_ec_cmd(EC_WRITE_EXT_SCI_MASK, (void *) &ec_word, 2,
-  NULL, 0);
-   } else {
-   unsigned char ec_byte = bits & 0xff;
-   return olpc_ec_cmd(EC_WRITE_SCI_MASK, &ec_byte, 1, NULL, 0);
-   }
-}
-EXPORT_SYMBOL_GPL(olpc_ec_mask_write);
-
-int olpc_ec_sci_query(u16 *sci_value)
-{
-   int ret;
-
-   if (olpc_platform_info.flags & OLPC_F_EC_WIDE_SCI) {
-   __be16 ec_word;
-   ret = olpc_ec_cmd(EC_EXT_SCI_QUERY,
-   NULL, 0, (void *) &ec_word, 2);
-   if (ret == 0)
-   *sci_value = be16_to_cpu(ec_word);
-   } else {
-   unsigned char ec_byte;
-   ret = olpc_ec_cmd(EC_SCI_QUERY, NULL, 0, &ec_byte, 1);
-   if (ret == 0)
-   *sci_value = ec_byte;
-   }
-
-   return ret;
-}
-EXPORT_SYMBOL_GPL(olpc_ec_sci_query);
-
 static bool __init check_ofw_architecture(struct device_node *root)
 {
const char *olpc_arch;
@@ -296,6 +216,10 @@ static bool __init platform_detect(void)
if (success) {
olpc_platform_info.boardrev = get_board_revision(root);
olpc_platform_info.flags |= OLPC_F_PRESENT;
+
+   pr_info("OLPC board revision %s%X\n",
+   ((olpc_platform_info.boardrev & 0xf) < 8) ? "pre" : "",
+   olpc_platform_info.boardrev >> 4);
}
 
of_node_put(root);
@@ -315,27 +239,8 @@ static int __init add_xo1_platform_devices(void)
ret

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Michal Hocko
On Wed 10-10-18 22:26:41, Arun KS wrote:
> On 2018-10-10 21:00, Vlastimil Babka wrote:
> > On 10/5/18 10:10 AM, Arun KS wrote:
> > > When free pages are done with higher order, time spend on
> > > coalescing pages by buddy allocator can be reduced. With
> > > section size of 256MB, hot add latency of a single section
> > > shows improvement from 50-60 ms to less than 1 ms, hence
> > > improving the hot add latency by 60%. Modify external
> > > providers of online callback to align with the change.
> > > 
> > > Signed-off-by: Arun KS 
> > 
> > [...]
> > 
> > > @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
> > >  }
> > >  EXPORT_SYMBOL_GPL(__online_page_free);
> > > 
> > > -static void generic_online_page(struct page *page)
> > > +static int generic_online_page(struct page *page, unsigned int order)
> > >  {
> > > - __online_page_set_limits(page);
> > 
> > This is now not called anymore, although the xen/hv variants still do
> > it. The function seems empty these days, maybe remove it as a followup
> > cleanup?
> > 
> > > - __online_page_increment_counters(page);
> > > - __online_page_free(page);
> > > + __free_pages_core(page, order);
> > > + totalram_pages += (1UL << order);
> > > +#ifdef CONFIG_HIGHMEM
> > > + if (PageHighMem(page))
> > > + totalhigh_pages += (1UL << order);
> > > +#endif
> > 
> > __online_page_increment_counters() would have used
> > adjust_managed_page_count() which would do the changes under
> > managed_page_count_lock. Are we safe without the lock? If yes, there
> > should perhaps be a comment explaining why.
> 
> Looks unsafe without managed_page_count_lock.

Why does it matter actually? We cannot online/offline memory in
parallel. This is not the case for the boot where we initialize memory
in parallel on multiple nodes. So this seems to be safe currently unless
I am missing something. A comment explaining that would be helpful
though.
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 0/15] Add support for OLPC XO 1.75 Embedded Controller

2018-10-10 Thread Rob Herring
On Wed, Oct 10, 2018 at 12:23 PM Lubomir Rintel  wrote:
>
> Hi.
>
> This patchset adds support for the Embedded Controller on an OLPC XO
> 1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
> the existing OLPC platform infrastructure, currently used by the x86
> based models.
>
> The EC operates in SPI master mode, meaning the SOC is the SPI slave. It
> uses extra handshake signal to signal readiness of SOC to accept data
> from EC and to initiate a transaction if SOC wishes to submit data.
>
> The SPI slave support for MMP2 was submitted separately:
> https://lore.kernel.org/lkml/20181010170936.316862-1-lkund...@v3.sk/T/#t
>
> THe "power: supply: olpc_battery: correct the temperature" patch was
> already sent out separately, but I'm including it because the last
> commit of the set depends on it.
>
> Tested to work on an OLPC XO 1.75 and also tested not to break x86
> support with an OLPC XO 1 machine. I don't have a XO 1.5, but it's
> unlikely this breaks it when XO 1 works.

I asked this on the OLPC devel list recently, but I don't think my
message ever got past the moderator. Could you generate a DT dump from
/proc/device-tree of an XO 1 and send to me? I have some DT changes
planned and need to see if they'd be okay for x86 OLPC.

Rob
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: vboxvideo: make a couple of funcs static

2018-10-10 Thread Craig Kewley
Fix Sparse warnings:
drivers/staging/vboxvideo/vbox_mode.c:309:6: warning:
symbol 'vbox_primary_atomic_disable' was not declared. Should it be static?

drivers/staging/vboxvideo/vbox_mode.c:452:6: warning:
symbol 'vbox_cursor_atomic_disable' was not declared. Should it be static?

Signed-off-by: Craig Kewley 
---
 drivers/staging/vboxvideo/vbox_mode.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
b/drivers/staging/vboxvideo/vbox_mode.c
index 042e4f384df9..deed28c7a1db 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -306,8 +306,8 @@ static void vbox_primary_atomic_update(struct drm_plane 
*plane,
plane->state->src_y >> 16);
 }
 
-void vbox_primary_atomic_disable(struct drm_plane *plane,
-struct drm_plane_state *old_state)
+static void vbox_primary_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
 {
struct drm_crtc *crtc = old_state->crtc;
 
@@ -449,8 +449,8 @@ static void vbox_cursor_atomic_update(struct drm_plane 
*plane,
mutex_unlock(&vbox->hw_mutex);
 }
 
-void vbox_cursor_atomic_disable(struct drm_plane *plane,
-   struct drm_plane_state *old_state)
+static void vbox_cursor_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
 {
struct vbox_private *vbox =
container_of(plane->dev, struct vbox_private, ddev);
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v3] staging: gasket: Fix sparse "incorrect type in assignment" warnings.

2018-10-10 Thread Laurence Rochfort
Remove the coherent buffer __iomem cookie because the buffer is
allocated from dma_alloc_coherent().

warning: incorrect type in assignment (different address spaces)
   expected unsigned char [noderef] [usertype] *virt_base
   got void *[assigned] mem
warning: incorrect type in argument 3 (different address spaces)
   expected void *cpu_addr
   got unsigned char [noderef] [usertype] *virt_base

Signed-off-by: Laurence Rochfort 
---
Changes in v3:
 - Just remove the __iommem cookie, don't alter type.

 drivers/staging/gasket/gasket_core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gasket/gasket_core.h 
b/drivers/staging/gasket/gasket_core.h
index 275fd0b..e62adcd 100644
--- a/drivers/staging/gasket/gasket_core.h
+++ b/drivers/staging/gasket/gasket_core.h
@@ -231,7 +231,7 @@ struct gasket_coherent_buffer_desc {
 /* Coherent buffer structure. */
 struct gasket_coherent_buffer {
/* Virtual base address. */
-   u8 __iomem *virt_base;
+   u8 *virt_base;
 
/* Physical base address. */
ulong phys_base;
-- 
2.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/3] staging: greybus: loopback.c: do insertion in O(n) instead of O(n lg n)

2018-10-10 Thread Bryan O'Donoghue

On 05/10/2018 15:28, Rasmus Villemoes wrote:

Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.


What's the problem you're fixing here ?

Is it tested ?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 1/3] staging: greybus: loopback.c: remove unused gb_loopback::lbid

2018-10-10 Thread Bryan O'Donoghue

On 05/10/2018 15:28, Rasmus Villemoes wrote:

Since lbid isn't mentioned anywhere else in greybus/, it's hard to
figure out how it was meant to be used. It does seem like entirely
dead (write-only) code.



yep, dead code

Reviewed-by: Bryan O'Donoghue 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-10 Thread Arun KS

On 2018-10-10 23:03, Michal Hocko wrote:

On Wed 10-10-18 22:26:41, Arun KS wrote:

On 2018-10-10 21:00, Vlastimil Babka wrote:
> On 10/5/18 10:10 AM, Arun KS wrote:
> > When free pages are done with higher order, time spend on
> > coalescing pages by buddy allocator can be reduced. With
> > section size of 256MB, hot add latency of a single section
> > shows improvement from 50-60 ms to less than 1 ms, hence
> > improving the hot add latency by 60%. Modify external
> > providers of online callback to align with the change.
> >
> > Signed-off-by: Arun KS 
>
> [...]
>
> > @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
> >  }
> >  EXPORT_SYMBOL_GPL(__online_page_free);
> >
> > -static void generic_online_page(struct page *page)
> > +static int generic_online_page(struct page *page, unsigned int order)
> >  {
> > - __online_page_set_limits(page);
>
> This is now not called anymore, although the xen/hv variants still do
> it. The function seems empty these days, maybe remove it as a followup
> cleanup?
>
> > - __online_page_increment_counters(page);
> > - __online_page_free(page);
> > + __free_pages_core(page, order);
> > + totalram_pages += (1UL << order);
> > +#ifdef CONFIG_HIGHMEM
> > + if (PageHighMem(page))
> > + totalhigh_pages += (1UL << order);
> > +#endif
>
> __online_page_increment_counters() would have used
> adjust_managed_page_count() which would do the changes under
> managed_page_count_lock. Are we safe without the lock? If yes, there
> should perhaps be a comment explaining why.

Looks unsafe without managed_page_count_lock.


Why does it matter actually? We cannot online/offline memory in
parallel. This is not the case for the boot where we initialize memory
in parallel on multiple nodes. So this seems to be safe currently 
unless

I am missing something. A comment explaining that would be helpful
though.


Other main callers of adjust_manage_page_count(),

static inline void free_reserved_page(struct page *page)
{
__free_reserved_page(page);
adjust_managed_page_count(page, 1);
}

static inline void mark_page_reserved(struct page *page)
{
SetPageReserved(page);
adjust_managed_page_count(page, -1);
}

Won't they race with memory hotplug?

Few more,
./drivers/xen/balloon.c:519:adjust_managed_page_count(page, 
-1);
./drivers/virtio/virtio_balloon.c:175:  adjust_managed_page_count(page, 
-1);
./drivers/virtio/virtio_balloon.c:196:  adjust_managed_page_count(page, 
1);
./mm/hugetlb.c:2158:adjust_managed_page_count(page, 
1 << h->order);


Regards,
Arun
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Direct io failed with ion

2018-10-10 Thread Rock Lee
Hi
I tested direct io with a ion allocated buffer, got a -EFAULT
error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
check_vma_flags() (do_direct_IO() calls it) doesn't allow that VMA has
these flags set. Could you give me any hit that could solve this
issue?

-- 
Cheers,
Rock
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel